x86-64 distros needn't cripple themselves to support 32-bit. [LWN.net]

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

Posted Jun 13, 2004 17:06 UTC (Sun) by loening (subscriber, #174)
In reply to: x86-64 distros needn't cripple themselves to support 32-bit. by JoeBuck
Parent article: Debian x86_64 port ready

64 bit is a win today even for apps that don't need it, due to the extra registers that are accessible to applications compiled as x86_64 apps.

Your example of a 32 bit program fitting in physical memory, while the 64 bit version not fitting, is exceedingly unlikely. Remember, the size of data hasn't changed (which is what consumes most of memory), or even the size of instructions, only the size of pointers has doubled (correct me if I'm wrong on this).

What could more likely happen is a 32bit version of a program fits in the CPU cache, while the 64bit is larger, so in some instances, the 32 bit application would be faster. But as the above poster said, 64bit is on average a 8% gain.

(Log in to post comments)

32-bit/64-bit performance comparison

Posted Jun 13, 2004 18:15 UTC (Sun) by stevenj (subscriber, #421) [Link]

For an example performance comparison (using gcc 3.3 on a 2GHz Opteron) benchmarking 32-bit and 64-bit performance of a few dozen real-world scientific codes (FFT implementations), see:

The 32-bit and 64-bit numbers are on separate pages, since this benchmark was intended for comparing codes and not architectures, so interpretation is up to you. Some of the codes do seem to be markedly faster in 64-bit mode, although it's not clear whether this is just random gcc brokenness.

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

Posted Jun 14, 2004 4:01 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]

Actually, the case of a 32-bit app fitting in physical memory, while 64-bit doesn't, is quite common, for any app where the storage representation is dominated by pointers. 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).

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).

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

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

Actually, the case of a 32-bit app fitting in physical memory, while 64-bit doesn't, is quite common, for any app where the storage representation is dominated by pointers.

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... ;-)