This is the mail archive of the
mailing list for the Cygwin project.
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/21/2012 11:34 AM, Andrew DeFaria wrote:
IMHO it's the thinking of "Well hell we have tons of
memory/disk/whatever. Why don't we waste it?"
I assure you, the move to 64-bit executables is not the reason Chrome
and your 3 JVMs are running you out of RAM.
Consider a 32-bit executable that is 4 GB in size. It can't even run
under an operating system, or do anything with data; it takes the entire
32-bit address space just to load. JonY has already correctly shown
that the average bloat due to a 64-bit recompile is in the 20%
neighborhood. That means you swamp this worst-case 64-bit bloat with
4.8 GB of RAM in the machine.
I've had 6-16 GB in all my desktop machines for years now.
There are reasons not to move to 64-bit. Executable size is not one of
those reasons. Inertia is a much better reason.
I remain unconvinced that a 64 bit Cygwin is required or
necessary or even worth it at this time.
I would say that the vast majority of the packages in the Cygwin
distribution could not reasonably make use of 64-bit data spaces.
However, one of your arguments in this thread cuts both ways: the fact
that there are a few packages that reasonably can do so means you cannot
say "we don't need it".
The easiest place to see the need for 64-bitness is in the programming
language compilers and interpreters.
With the dynamic language interpreters (Perl, Python, etc.) the bitness
of the interpreter affects the address space available for program data.
Big Data is a Big Thing right now, and one of the things driving it is
commodity 64-bit CPUs and cheap RAM. One of the biggest languages in
this space is R, and one of its historical limitations is that it has to
load all data entirely in RAM to operate on them. Moving to 64-bit
directly affects the data set size you can analyze.
You see some pressure here in the static language compilers, too. (C,
C++, etc.) A few months ago there was a furor in the blogosphere over
the fact that Firefox can't even build any more with full optimization
under a 32-bit OS. Even when making 32-bit builds, they have to do it
on a 64-bit system just so the optimizer can keep all the balls in the
air. (See http://goo.gl/oYvhE for the story.)
There are sketchier examples to be found in the Cygwin package repo,
like Apache and MySQL. I'd argue that you should move to the native
versions before you send the Cygwin ports up against a big enough load
that they can start making use of more than 4 GB of RAM, though, since
the I/O overhead would probably be a bigger problem than RAM before that
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple