Should we build i386 or i686 rpms?

[Aleksandar Milivojevic]

Jonathan Berry wrote:
> No, sizeof(int) == 4 still on x86_64.  sizeof(long) == 8 ==
> sizeof(void *).

Thanks for this info.  From all the talks about increased code size I 
was affraid ints were 8 bytes long.  Huh, happy to hear assumption I 
made was wrong.

> James is correct about the large portion of the
> performance improvement is from having twice as many registers as the
> x86 line.  This means you use the stack less, which reduces the number
> of (relatively) slow memory transfers.  All of the AMD64 CPUs, though
> have fairly substantial caches.  Recently AMD has reduced cache size
> (L2) to 0.5 MB, but most earlier models (like my clawhammer core) have
> 1 MB.  Granted, this does seem a little small now that Intel seems to
> have made 2 MB L2 caches the norm (at least on their P4s and Pentium
> Ms).

Yes, more registers and more cache, and things get much faster.  Digital 
went that route many years before.  Anybody remember Alpha processors 
with 8MB of cache a while back?  Those were fast beasts.  And even the 
basic Alphas had considerably more cache than competition of that time. 
  Too bad Alpha never really cought on as mainstream processor.  And MS 
even had Windows NT ported to it (however, it didn't made use of 
undelying 64-bit architecture).  I guess it was (mostly) Digital's price 
tag that killed it.  Or maybe it was simply too much ahead of its time. 
  Or maybe it was simply Compaq (who was never really interested in 
Digital's advanced technology to start with) that totaly killed it off. 
  Too bad, it was (IMO) about the only RISC architecture that had a 
chance against Intel line of processors (mostly because it was designed 
to use off shelf PC components).  Plus it was clean 64-bit architecture, 
with no 32-bit past to worry about.

> Yes, x86_64 does do this.  The code will still be a little larger due
> to pointers, longs, immediate constants, and some longer instructions.
>  I think it's the pointers and the immediate constants that cause the
> greatest concern for code size increases.  It's been a while since I
> looked at this stuff.  I think the default data size is still 32-bits
> in a effort to keep code bloat to a minimum.  There is a little bit of
> information on this at http://www.x86-64.org/

My experience with Alpha processors and competing 32/64-bit counterparts 
of that time (UltraSparc for example) was that small increase of size 
code is mostly overrated.  In real-world, it was not much of an concern. 
  If 256 megs was enough to make 32-bit application happy on UltraSparc, 
256 megs was enough to make it happy on completely 64-bit Alpha.  On 
UltraSparc itself, running 32-bit vs 64-bit kernel has almost no 
performance penalty in real world applications.

So I wouldn't waste much time worrying about that.  Yeah, in lab tests 
you might see some slowdown.  But when you load your applications and 
start using the system in real world, you are not going to see any 
noticable performance degradation (even if number of registers and cache 
is the same).  Add addtional cache and registers that you get when 
swtiching to AMD64's 64-bit mode, and as both you and James wrote, 
things get actually much faster.  Add to that ability that all 
applications are able to handle large files without being specifically 
modified for that is big enough bonus on its own.

As for mixing 32/64-bit libraries on the system...  I was using 
32/64-bit mix of libraries under Solaris since UltraSparcs came around, 
and I always found it to be major pain in the ass (to the extent that 
you simply give up and don't use 64-bit in userland at all, unless you 
really really have to).  I've played for couple weeks with Aurora (port 
of Fedora to sparc64).  And found that it was also a pain in the ass 
there.  At the end, I simply went OpenBSD route for that machine, things 
simply worked better (Aurora is still kind of experimental project), and 
there's no mixing of 32bit and 64bit userland (hip hip huray).  At least 
not that I noticed.  Hopefully the approach in Fedora AMD64 port isn't 
the same as in Aurora sparc64 port.

> Hmm, I don't know.  Making a pointer from an int shouldn't be too bad
> (32-bit to 64-bit).  Making an int from a pointer (64 to 32) could be
> a big problem on 64-bit, though it could also work just fine if the
> pointer is below the 32-bit line in the address space.  However, since
> my kernel runs just fine, I guess this code is not a problem : ).

Well, who knows, maybe it was long and not int...  On i386, int = 4, 
long = 4, long long = 8.  As you wrote, on x86_64, int = 4, long = 8, 
long long = 8 (I guess?).  If that was the case, or if there are ifdefs 
in the code for case when you compile for 64bit, this might not be an 
issue (not an example of clean programming, but not really an issue either).

I'll pay attention next time I need to recompile kernel.  Which might 
not be anytime soon (I recompiled kernel to test patch for bug #151284, 
rather nasty NFS problem, you might not want to use NFS for anything 
important until it is fixed, or you might loose your data).

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