I personally don't run the 64 bit version unless my 32-bit sessions get laggy. Anyone out there running all 64 bit yet?
As a programmer, there is a lot of misinformation in that article. I have never used a program where being able to access more than 4 GB of physical RAM mattered. All of the below reasons apply even if you only have 256MB of RAM: 1. Being able to access more than 4 GB of virtual RAM (e.g. with mmap), or even just allowing holes and not worrying about fragmentation, is a huge win.
2. The 64-bit instruction set is significantly different than the 32-bit instruction set. First, there are twice as many registers, so there is much less stack spilling. The default C ABI passes several arguments in registers instead of passing everything on the stack, so again less stack access. And 64-bit processors are guaranteed to include the (2x-4x faster) SIMD instructions (which, since they're not present on all 32-bit processors, will not be used even if your processor supports them).
I use several programs for audio where being able to access more than 4gb of ram is almost essential. Large audio/film sessions using digital plugins can use up 4 gigs fairly easily if you're running them all native. I totally understand that it does not affect programming , as everything is made to be very lightweight, at least as far as web programming goes, to keep load speeds down and such, but with audio and film, there is a much higher processor demand. Especially 96kHz+ sample rate sessions, they're very ram demanding.
I'm not convinced that those applications need that much RAM, or if they're just written in an extremely lazy manner since they know they can just ask you to throw more hardware at it. By far most operations should be stream-based rather than random-access-based (which still would only required virtual RAM if you trust the OS to flush the mmap'ed pages), so they should only need a small chunk in RAM at once, and the rest can be paged out by an application-aware pager. Those two phrases don't go together at all. Web programming often uses 10x as much RAM as native, and even if fully optimized for the environment is fundamentally limited to 2x or 3x. And most web programmers don't have any understanding of performance at all.made to be very lightweight ... web programming
My point was:
When running a 5GB protools session with say 150 native plugins, the 32 bit system pretty much shuts down as protools can only access up to 4 gb of ram on 32 bit. With 64 bit, I can access all 16GB of my ram and I can run the same session with 10x as many native plugins without causing any delay in the session that I cannot internally compensate for. For web design, you want the smallest files you can for load time, this is completely backwards from film or audio or photography because, generally, you want the highest resolution raw files you can get, that what I meant by lightweight. And sublime text/python launcher/idle doesn't fuck with protools/ableton/logic/cubase as far as ram/processor demand goes(also my point to lightweight). Maybe adobe's coding software is more demanding...? Most DAWs recommend a minimum of 4GB of ram, and if you run a session with a lot of vsts/plugins, 4GB does not go very far. If you think you can design better software for recording audio that would be less demanding, you should, you could make a ton of money off it. But I am assuming the past 20+ years of software development that have gone into programs like protools and cubase probably are doing about as good as they can, and the 64-bit processing addition was the next step. PT is starting to do cloud stuff so we'll see how that goes.