> 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. > 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. Besides, who cares that much about the image size these days? We don't, within reason. > 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. You say you get 4 GB but for many applications that is only a dream: * 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. * 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. 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. 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... -- 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
