x86-64 on i386 (was Re: Promoting i386 version over x86_64?)

[Paul Jakma]

On Mon, 14 Dec 2009, Chris Adams wrote:

> Have you actually shown any concrete benefits, or has it all just been
> hand-waving?

Well, the benefits were already known from the introduction of 64bit 
systems in the mid 90s. E.g. a rule of thumb with AXP systems was 
that they required at least 30% odd more RAM, compared to other Unix 
systems (either 32bit, or 32-userspace/64kernel systems - which is 
what most of the other Unix RISC vendors went with when they went to 
64bit CPUs).

E.g., a fresh F12 install:

32bit

              free -m: used +/- buffers/cache
at gdm:               71
logged into desktop: 123
+firefox:            183
+OO writer:          203

64bit:

at gdm:              113
logged in:           159

Unfortunately, I couldn't get the 64bit one past "logged in" and even 
then I couldn't get it to display a useful desktop (good bit of GNOME 
stuff was running, but nothing shown), so it's probably 
under-representative.

That shows a 59% increase for "at GDM", and at least a 29% increase 
for "logged into desktop". However, to be fair, that's probably 
/over/-representing the difference, as I didn't do much with any 
applications. Pure data, like the contents of webpages, your email, 
etc.. doesn't contain arch-dependent variable width data like 
pointers. That said, attendent meta-data (e.g. mail indices, data 
structures for the layout of your rendered webpage, etc..) may have 
arch-dependent variable-width data.

So I'd expect that that 60% figure would go down a bit if you really 
used the system. I would expect a memory increase, due to 64bit, of 
somewhere between 30 and 60%, depending on system - or a saving of 
between 23 to 38%.

I can't do this test as running F12 x86-64 under Qemu is just too 
damn slow, even if did finish login successfully. If someone wants to 
replicate the above with KVM on x86_64:

1. Install F12
2. After the first boot, reboot again, to eliminate the run of
    'firstboot'
3a. login via ssh
3b. login via GDM
4. start firefox
5. switch to the 2nd desktop
6. start oowriter

Use the SSH session to note the memory usage with 'free -m' after 
steps 3b, 4 and 6. You may need to run the command a few times to 
wait for the usage to stabilise (it probably will spike and decrease 
again).

For certain workloads, e.g. servers dealing in large numbers of 
instances of small amounts of data, 60% extra could be quite normal 
(or even low). It was in optimising memory usage for a BGP 
implementation where I personally noticed just how much bloody space 
those 64bit pointers can take up. ;)

> If somebody shows real benefits (with real data to back it up), and is
> willing to put forth the effort to make it work, it might be
> interesting.

All I'm saying is that it would be nice if:

a) an x86_64 kernel was made a supported option for a 32bit Fedora
    (it pretty much works already) - i.e. its an additional kernel.

b) yum grokked out of the box how to upgrade such systems (at the
    moment you have to tweak some file to make it think it's a 32bit
    system, and then kernel updates have to be done manually)

I'm saying there is at least one very reasonable and rational reason 
for 32-on-64.

I personally think the model used by many Unixes from the 90s makes a 
lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a 
select few applications that actually need the benefits of x86_64 
(memory/bit more performance), but hey..

regards,
-- 
Paul Jakma	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
If you can't learn to do it well, learn to enjoy doing it badly.