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/18/2012 10:58 AM, James Johnston wrote:
OK, OK. Tack on "for most applications" to my statement (I thought it
64-bit does not make things go any faster than 32-bit.
Not true for some applications. For one of our applications that uses very large in-memory trees and is therefore heavy on the recursion, simply switching the compiler to 64-bit provided a 10% performance boost. Other commonly used compilers and configurations provided an even bigger boost - e.g. 15% to 20%. Seems like I recall reading somewhere that x64 has more registers available for parameter passing, so recursive algorithms get a boost like this.
Other applications aren't affected so much by the change. For example, I would expect a simple math intensive app that doesn't use much memory or recursion to run at about the same speed. And other applications are detrimentally affected. For example, the 2x larger pointer size can negatively affect algorithms that store many pointers, which means that not as much data can be stored in the fast CPU cache.
How can 1000 machine instructions of 32 bit be larger than 1000 machine
instructions twice that size! Unless vastly different code generation
happens with 64 bit compilers the number of instructions emitted should
be just about the same yet with 64 bit instructions are obviously twice
as big as 32 bit instructions.
Not true. Some programs grow slightly and some might not grow so severely. Example: - comparing an otherwise identically-compiled program, it is 583 KB for 64-bit and 613 KB for 32-bit. So the 64-bit version is actually smaller. Another example program is 1364 KB for 32-bit and 1956 KB for 64-bit. In that case the 64-bit version is larger, but not even close to 2x larger.
64-bit is wasteful as
programs grow to double in size.
Besides, who cares that much about the image size these days? We don't, within reason.
I, for one, do. These larger binary images need to fit in memory and
reserve swap space and virtual memory. I see virtual memory foot prints
in the hundreds of megs if not gigs. Chrome on my Ubuntu box regularly
takes 1-2 gig of virtual memory and hundreds of megs of real memory. If
you run many things like I do you quickly get to the point where your
swapping and thrashing and waiting for the OS to manage many, many more
fragments of memory. All my systems have 4 gig (XP at work, a couple of
Ubuntu boxes at home) and they all come under memory pressure at times.
Small is beautiful.
That's totally unfair as I didn't say that nor did I imply it at all. As
such that was a stupid thing to say IMHO.
And 640 KB of RAM will be enough for anybody.
64-bit is only required/useful/etc if you
have memory requirements> 4 gig. I don't think any Cygwin executable has
You say you get 4 GB but for many applications that is only a dream:
I didn't say anything of the sort. Re-read it.
* Most applications are not compiled to be large address aware, which means that they only get 2 GB of address space - not 4 GB. Windows gets the rest. In order to be large address aware, you have to be 100% sure that no code is storing pointers in signed integers and then doing math/comparisons with it. If you are large address aware, you still only get a limited amount of memory on 32-bit operating systems - not the full 4 GB.
I didn't say that either. I said that 64 bit allows you to address more
than 4 gig.
* You could use Address Windowing Extensions to access more than 4 GB in 32-bit, but the application has to be specially coded for it because you are swapping the pages in and out of the 32-bit address space and there are other limitations (e.g. is not pagefile backed).All of this is irrelevant to the request to make say /bin/ls 64 bit.
* So, assuming you only have 2 GB of user-mode address space. Windows DLLs will gobble up a few hundred megabytes at the upper end of the space to map its DLL images.
* Your program and dependencies also have to be mapped into memory. If you're smart, you take the time to rebase them and/or turn on ASLR so that they occupy a contiguous block of memory. Otherwise, you could badly fragment the address space further.
* Your program will fragment the address space as it runs. How badly will depend on the memory allocator and the pattern of memory allocations you make.
* An external program outside of your control might load/inject a hook DLL into your process, and load it smack in the middle of your address space, fragmenting it. Or maybe it's a 3rd-party DLL/driver that you load, but it's beyond your control.
When it's all said and done, for many applications if you properly rebase, you might get 1.5 GB contiguous space on a clean install of Windows. But it's too easy for that to fragment. Realistically, you can't allocate blocks more than maybe a couple hundred MBs to be safe. And you should try to allocate much more than 1 GB total. Fire up VMMap and point it at the average process on your computer - especially a more complicated one that's been running for a while. You might be surprised how small the largest free space block there is for some programs.
Sure there's an argument that you should split your data into smaller allocations, but big allocations are awfully convenient for some pieces of data. In our case, we use a 3rd-party library that requires us to store our large data sets in contiguous memory, so fragmentation is a big problem.
For us, supporting the limited 4 GB 32-bit address space has turned into a big annoyance in some of our applications. It's not a theoretical discussion.
I don't understand why 64 bit Cygwin is an issue for you. Are you trying
to build Cygwin executables? If not then isn't your question about
building your 64 bit app better posed to Microsoft Visual Studio guys?
To the OP: there has been lots of discussion about 64-bit on the Cygwin developer list; you may want to read up on the conversations there...
Andrew DeFaria <http://defaria.com>
An error? Impossible! My modem is error correcting.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple