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@xxxxxxxxx Key ID: 64A2FF6A
Fortune:
If you can't learn to do it well, learn to enjoy doing it badly.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
