Should we build i386 or i686 rpms?

Aleksandar Milivojevic amilivojevic at pbl.ca
Tue Mar 22 20:18:13 UTC 2005


James Wilkinson wrote:

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

The above two paragraphs depend on sizeof(int).  I don't have any AMD64 
around to test, but my guess is sizeof(int) is 8 on it?

If the above is correct, than you are right.  The code will get larger 
when everything goes double, where it really doesn't need to.

However, if the aproach was the same as in OSF/1 (alias Digital Unix, 
alias Tru64) for Alpha processors and OpenBSD for 64-bit processors 
(well, at least those I tried) things are different.  On mentioned 
operating systems, sizeof(int) is 4, sizeof(long) is 8, and sizes of 
pointers and typedefs such as size_t, off_t and similar is bumped to 8 
(OSF/1 time_t is also 8 bytes long).  Basically, you are using double 
the memory only for storing data types that acutally benefit from being 
64-bit long.  Basically, that way you enable all programs access to 
large address space and correct handling of large files (even if the 
program itself was not written to support them by use of open64() and 
related system calls).

Of course, than you have small problems with that common programming 
error (assumption that sizeof(int) == sizeof(void *), which is plain 
wrong).  Assigning 64-bit pointer to 32-bit int doesn't really work... 
However, Alpha processors have been around for long enough for that kind 
of bugs to be corrected in most of the open source.  Speaking of that, I 
was compiling Linux kernel couple of minutes ago, and noticed bunch of 
"assigment makes pointer from int" (or the other way around?) warnings. 
  Seems that Linux kernel is not free from those kinds of (basic) 
programming mistakes ;-)

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7




More information about the fedora-list mailing list