I remember hearing that for performance a development machine should be 32 bit, while servers should be 64 bit. I think it was Richard Campell on Dot Net Rocks! that mentioned this.
Why would 32-bit be faster than the 64-bit for a development box and vice versa for servers?
I run 64-bit 2008 Server and see not performance issues whatsoever. In fact, it's much better than 32-bit XP. It performs generally faster. In a funny way, file operations are quicker on my laptop 5400rpm drive running 64-bit 2008 Server than on a office PC with a 7200rpm drive running 32-bit XP.
I can think of only one thing why you would want to run a 32-bit OS (XP being the latest): you get there IE6 to debug your sites.
The other thing is that a 32-bit OS is incapable of addressing RAM capacity over ~3,4 Gb. If your PC has 4+ Gb of RAM you only loose with a 32-bit OS. Recollecting that even consumer laptops are sold these days with 4, 6 and 8 Gb of RAM, one can safely say goodbye to a 32-bit OS.
If you are talking about non-Windows OS then my experience may not apply.
It depends in part on your tools - for example, Visual Studio is still a 32 bit app (but usable from x64 - just no huge gain).
However, if you are using your main OS to host VMs, then you can probably benefit from a ton of memory for your various virtuals - and then you can choose 32-bit and 64-bit VMs to suit your needs (it is harder to have a 64-bit guest VM in a 32-bit host).
Personally, I'm still on 32-bit for development. For most of what I do, it is fine.
One major reason is the fact that 32-bit OSs can't address 4GB of RAM. 4-8GB can be crucial in a lot of development environments where virtual machines are involved, or even heavy lifting in general. This is why I always stick with 64-bit where possible, and all modern CPUs support it.
I have a 64-bit Ubuntu installed in my laptop. I use it for development and I have no performance issues at all. I have the feeling that computer resources are better used this way.
The only reason I can think of to choose 32-bit OS is that you know that what you develop will work on 32-bit and 64-bit machines. But VS let you choose your target machines...
His point was if you develop for 32bit you will have less than 4GB of ram to work with. And on a 64bit server you may have much more than 4GB of RAM. Basically tricking you into being more frugal with your memory requirements. It had more to do with memory usage than raw number crunching on the CPU.
I don't think that 32 bit machines are faster then 64 machines for developers. It is true that your development environment on a 64 bit OS is running in an emulated 32 bit environment and that creates a slight overhead. On the other hand you will find that the 64 bit OS is slightly faster as the internal data paths are 64 bit enabling the OS to move twice as much data in a single operation. This makes the 64 bit OS slightly faster than a 32 bit OS. The downside of a 64 bit OS is that pointers are twice as big.
What really matters is that 64 bit OS'es are very stable, have access to much more physical memory, and can run both 64 bit and 32 bit applications and virtual machines without sacrificing performance. The 32 bit OS belongs to the past.
Although I can't quantify it in numbers, I have noticed the same thing as 'new in town'. I used to run XP x86, and later vista x86 on my notebook. After I upgraded to Vista X64 it is a lot snappier. Don't know if it is a driver issue, the fact that I run SQL Server x64 etc, that it can use twice the amount of cpu registers, optimizations in 'internal' stuff in windows or what, but I can notice the difference...
Having a lot of memory changes the way you work, sometimes dramatically. I run 8 virtual screens with 4 different development environments (1 trunk, 2 branches and a fourth environment for external projects). Just with 12GB mem and a 30" screen.
I'd think the obvious suggestion would be to use whatever OS your code is going to be deployed on. If your development environment is as close as possible to the deployment environment, there's less chance of bugs showing up only in the deployment environment.