You will get the benefit of the 64-bit extensions under linux (there is scheduled to be a release of 64bit Windows some time this year also but I am not sure exactly when). 64bit is definitely cool, but I've encountered more bugs in the SuSE linux distro for 64bit Xeon than in the regular x86 one. Still: early days... the other 64bit SuSE platforms' distributions are rock solid.
An attribute of 64bit binaries is that they use slightly more storage than the exact same code compiled for a 32-bit CPU, so your 512MB will not stretch quite as far as it could on a conventional P4 machine. When I compile my code for 64bit (sparc, PowerPC, ia_64) and 32 bit Intel x86) I reckon the PPC and Sparc images use about 10 per cent more on average, and the Xeon even a bit more. Perhaps the C compiler optimiser is not yet as efficient on Xeon, but in any case, this is mostly a side-effect of wider word sizes used to store basic types and the way the optimizer organizes alignment on word boundaries.
The memory usage figures in Process Manager (or, in Linux, in 'top') are not the whole picture. Both systems use all the extra physical memory not allocated to processes or to the kernel to pre-load open disk files. The filesystems in Windows and in Unix both implement read-ahead algorithms that use unallocated RAM to cache files under DMA control. This usage goes 'under the radar' of the Process viewer or 'top', though. The difference in practical terms depends on which applications you are running, but we have measured performance improvements roughly double for database apps when running in a 1GB machine rather than a 512MB one. Yet, according to 'top', the database process was only using about 200MB.
