On 5/18/2012 10:58 AM, James Johnston wrote:
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.
OK, OK. Tack on "for most applications" to my statement (I thought it
was assumed).
64-bit is wasteful as
programs grow to double in size.
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.
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.
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.
64-bit is only required/useful/etc if you
have memory requirements> 4 gig. I don't think any Cygwin executable has
such requirements...
And 640 KB of RAM will be enough for anybody.
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.
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).
* 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.
All of this is irrelevant to the request to make say /bin/ls 64 bit.
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
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
