Some Thoughts on the Current State of 64-bit Computing
Posted Feb 25, 2005 22:15 UTC (Fri) by other-iain
Parent article: Some Thoughts on the Current State of 64-bit Computing
I remember being at SGI when we introduced a 64b O/S. We also put a bunch of goodies in the CPUs in an attempt to mitigate the performance hit of moving 8 bytes instead of 4 for every pointer.
For a while, we supported two kinds of binaries, named for the compiler flags which selected the type:
-o32: this was the old 32-bit binaries
-n64: new 64-bit binaries
There was a lot of discussion internally about whether we should enable the 64b goodies (extra registers primarily, but also some extra instructions too) without forcing 64b pointers. In the end we did it:
-n32: new 32-bit binaries
The extra registers added real performance gains for numerous customers, and n32 ended up being what most programs compiled with. Eventually, the 64b model was still valuable for the killer apps that people bought the machine for (database, crash sims, supernova sims, nuke sims), but nearly everything else was compiled -n32. It was the right pragmatic balance, and the cost was having to support three binary types instead of two.
I think Linux is going to do an -n32 as well, eventually. I wish they'd just get on with it. Until Linux n32 is available, the 64b width, extra registers and extra instructions on the Athlon64 just won't make any difference to most people, which is a shame.
to post comments)