x86-64 distros needn't cripple themselves to support 32-bit.

Posted Jun 14, 2004 9:09 UTC (Mon) by joib (guest, #8541) [Link]

I read somewhere that on average, apps compiled as 64-bit tend to use 20 % more memory than when compiled as a 32-bit app.

Don't forget that today, people are squeezing hard to get their apps to barely fit in the 32-bit address space, so there are a lot of people right up near the boundary (particularly in chip design).

Yes, but as you certainly are aware, with 64-bit addressing we don't have to worry about the boundary (for the foreseeable future, at least).

Using a large part of the address space is a nightmare anyway. With Linux, to use more than 1 GB you have to enable highmem support, with a small performance penalty. That gets you 3 GB for apps, if you want the full 4 GB you can use the 4g/4g patch, with an even greater performance penalty (especially if the app uses lots of syscalls). And the closer to the limit you get, the more you have to worry about stuff like suitable library offsets etc.

With 64-bit addressing all those problems disappear. While you may hit the limit where you need to buy an extra stick of memory sooner with 64 bits than with 32, if you can afford the license for one of those commercial EDA packages as well as the engineer to use it, I'm pretty sure you can afford a couple of extra GB as well.

Speaking of performance, the 8 % advantage mentioned above for 64 bit vs. 32 bit, seems to be for a lowmem 32 bit configuration. Comparing 64-bit with 4g/4g could give a significanly bigger advantage to the 64-bit version.

There are various tricks to reduce the memory penalty for 64-bit, like trying to replace pointers with integer offsets where possible (to be able to address 2**32 words on a 64-bit machine).

Uh oh, and I thought that the world has enought problems writing reliable and portable software as it is... ;-)