This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]