I'm amazed how misinformed some people are with this 32-bit vs 64-bit issue. For what it's worth, here's my take on it:
Civ5 as it is right now is a large-address aware 32-bit application (I checked it with LaaTiDo), which is a good start. For those of us using 64-bit, that means it can address the full 32-bit virtual memory space of 4GB, regardless of the "practical" limits placed on 32-bit applications in 32-bit Windows. Still though, once it hits 4GB, it's done, even if you have plenty more physical memory to use up, never mind your total commit charge size.
Now to address the misinformation (I'm reading posts in reverse order here):
1. 64-bit as pertains to word size doesn't mean the processor can process "double" the amount of 32-bit applications. That's nonsense. 64-bit as pertains to word size (as far as XP/Vista/7 x64 is concerned) means the processor can handle 64-bit instructions as well as 32-bit instructions.
2. It's true that 64-bit uses more RAM, in both senses of that phrase. 64-bit as pertains to app memory usage, compared to 32-bit equivalents, means that a 64-bit application will use about twice as much memory as its 32-bit equivalent. This does not necessarily equate to a reduction in performance compared to 32-bit, so long as you have ample physical RAM to make up the difference. What I mean by this is, say, you have a 32-bit memory intensive application on a 64-bit OS on a system with only 2GB of RAM. Compare it to a 32-bit system with 2GB of RAM, and you'll find most 32-bit memory-intensive applications run faster on the 32-bit system, and on the 64-bit system, they run as fast as the 32-bit system would with only 1GB of RAM (I've done this). Up it to 4GB and it's back to running as fast as the 32-bit system would with 2GB. The point at which this becomes irrelevant is >6GB on 64-bit, as you generally can't get a 32-bit system to allow a large address-aware application to use more than 3GB, and normally you can't push them beyond 2GB anyways (you have to really know what you're doing to get around that insurmountable waist height fence).
3. As for 64-bit having access to more RAM, as far as x64 Vista/7 are concerned, the practical limit for 64-bit applications is not the theoretical maximum of 16 exabytes - Windows Vista x64 is limited by the OS to 128GB of RAM, and Windows 7 x64 is limited to 192GB, although as far as virtual memory is concerned, assuming the 64-bit application is flagged as large address-aware (yes, this still has to be done, it's not "assumed" for 64-bit applications), individual applications can use up to 8TB of virtual memory. Things like "memory leaks" become so much less of a problem until you start chewing through the hard drive for increasing the size of your pagefile (to accommodate a growing commit charge). I've tested this too, it's not hard, run a LZMA2 compression job in 7zip x64 using a dictionary size of 1GB and watch the system grind to a halt even if you have 12GB of RAM, when such a compression job actually needs closer to 48GB of RAM.
4. "Memory usage" in general
is not something you can accurately gauge with Task Manager alone. That's why I find
Process Explorer significantly more useful.
Yeah, I'd like to see a 64-bit binary, but I'd rather they prioritize fixing the bugs over the possibility of introducing a whole new set of them by porting to 64-bit.