Aleksandar Milivojevic wrote:
> Of course, when we move to AMD64, it is completely different story. For
> that platform, there is benefit if we want to utilize 64-bit data types,
> so we have almost all packages recompiled specifically for that
> platform. Although, I would be much happier if Linux folks took
> approach from Digital Unix for Alpha processors and/or the approach
> OpenBSD folks have for 64 bit processors, and not the one from 64-bit
> Solaris (where there's also that terrible mix of 32-bit and 64-bit
> stuff). IMO, wanna run 64-bit, do it clean, don't mix and match.
Great theory, and I understand one that Debian have followed. So don't
blame "Linux folks" in general...
Unfortunately, OpenOffice doesn't yet compile for x86_64 (as far as I
know), and a lot of the third-party media players which rely on external
codecs don't have 64 bit versions of the (usually closed) codecs.
The Debian workaround for this is to have a separate 32 bit install, and
use chroot to run 32 bit packages in the 32 bit install. It's arguable
whether this is particularly "cleaner" than Fedora's approach.
Incidentally, I understand that it isn't the 64 bit wide registers that
are the big performance enhancement in AMD64: it's the extra registers.
Most programs (at the moment) don't need 64 bits. But 64 bit mode makes
binaries larger, which means you can get less code into a fixed-size
cache, slightly slowing things down.
On AMD64, the other benefits (especially the extra registers) outweigh
this (so 64 bit mode is still faster). On RISC chips with a clean 32 bit
mode, commercial Unix has often stuck to a 32 bit userland.
James.
--
E-mail address: james | [World War II] was a time when, in face of adversity,
@westexe.demon.co.uk | romance was often in the air -- except in single seater
| aircraft, obviously.
| -- "I'm Sorry, I Haven't A Clue", BBC Radio 4
