Is the Latest Release of Cygwin supported on Windows Server 8/2012

[Warren Young]

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 
point.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple