Hi,
<Long Boring Technical Post Alert>
My comments are based on findings of recently architecting a client's approach to migrating to Windows 7 for their 27,000 employees starting next year as a part of their enterprise IT strategy revision. We did a four month discovery and found over 5,000 unique applications in use, and consolidated those down to 1,250~ish approved applications. These were then tested for Win7 compliance and 64bit compatibility, using both native 64bit versions and native 32bit verions running in WoW64 thunked sessions. We found that of the 1,250 apps only 137 offered native 64bit versions, and then of those we found issues with 73 including the Office suite, which we had expected as Microsoft told us so... including the fact that 32bit Excel add-ins didn't work. Of the 64bit versions of apps including the new version of Avid Media Composer, two GIS product suites, two CAD suites and a myriad of scientific applications they found negligible performance benefit from 64bit until over the 4GB memory space usage.
(2^32 = 4GB of addressable memory space - on Windows the extra memory that is 'not addressed' is made up of RAM which is utilised for device drivers, system processes and cache and video etc. but it is still being used and has to come from somewhere regardless of the bit depth of the OS). The fact that Windows choses to hide it from Task Manager doesnt mean it is not being accessed. 32bit Windows actually supports way more than 4GB using virtual address space (up to, theoretically 128GB RAM depending OS version) but any single process will generally be restricted to accessing either 2GB RAM (user space) or 4GB RAM (system space) though there are some exceptions. We used to do this with many server workloads before 64bit OSes were available. Once accessing over 4GB I agree it is usually far easier to move to 64bit these days.
.
Extra CPU cycles were *far* more beneficial in almost every case (amazingly there were still a number of single threaded power apps which couldn't take advantage of more than one core - ArcGIS for example so they could only respond to clock speed of a single core). 32bit apps running in thunked sessions on 64bit Windows showed zero increase in any cases, and a minor decrease in a number (due to the translation/brokering of the WoW64 subsystem we presumed). The tests were all done using Liquidware Labs Stratusphere to measure, record and compare application-specific performance and responsiveness, I/O generation, memory consumption, CPU utilisation, Paged Pool, Non-Paged Pool Page Table Enties availability, etc. The end result is that we developed standards for the standard user group of 1.5GB RAM/32bit OS, a power users group of 4GB RAM/32bit OS and a super users group of 8GB RAM and 64bit OS.
</Long Boring Technical Post Alert>
.
All of which is just a puffed up chest way of saying I understand memory utilsation (on Windows) relatively well, but have seen in my experience that for the average user there could be more more potential pitfalls in 64bit than benefits unless using over 4GB RAM. I have a 64bit system for myself which I primarily use for Photoshop and Avid Media Composer, with 24GB RAM (it was going cheap through a client) and I push all the Photoshop activity into memory that I can by pushing the Memory Usage slider to 100%. So I'm not totally disagreeing with you, just suggesting that for a casual user 64bit might be fraught with danger unless you look at their system holistically.
