[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Mon, 14 Dec 2009, Chris Adams wrote:

Have you actually shown any concrete benefits, or has it all just been

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:


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


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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]