Should we build i386 or i686 rpms?

James Wilkinson james at westexe.demon.co.uk
Tue Mar 22 17:51:39 UTC 2005


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




More information about the fedora-list mailing list