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

Paul Jakma paul at dishone.st
Sun Dec 13 22:24:29 UTC 2009


On Sun, 13 Dec 2009, Chris Adams wrote:

> As soon as you bring in even one 64 bit user-space program that is run
> much, you've pulled in at least glibc and friends.  At that point, you
> might as well run all (or as close to all as possible) 64 bit
> user-space, because the libraries are shared (code will be in the cache,
> etc.).

That's assuming that the footprint of libraries relative to distinct 
applications is large enough to cancel out the space savings. (I have 
no data either way). A 64bit kernel doesn't need any 32bit userspace. 
An X server, on my 32bit system has about 8.5MB of programme text 
(server and libs) and loads about another 1.5MB worth of modules 
itself, i.e. 10MB.

So if you ran a 32bit system with a 64bit kernel and X server, you'd 
lose out on about 10MB of shareable code. For comparison, my 32bit 
system has O(10) times that allocated to things like browsers and 
feed-readers. It's using 4.8GB in total (ex buffers/cache) 
apparently.

Space for text (programmes, code) is simply insignificant these days, 
compared to the huge amounts of data which programmes allocate - data 
which sometimes includes a lot of pointers.

You're also assuming that this cancels out the other benefits.

> The only time my systems have run 32 bit code in several years is for
> the Flash plugin (since the open-source plugins don't seem to be able to
> keep up and since the 64 bit Adobe plugin doesn't seem to get the
> security updates) and sometimes the Acrobat Reader plugin (since I've
> run into websites that assume they can embed PDFs in the page and AFAIK
> there's no plugin for Evince).

It's interesting that both you and drago have "almost always" (to 
paraphrase) run 64bit pure systems. Surely that *reinforces* my point 
about the futility of "64bit pure systems" as an achievable goal (in 
the aggregate across all reasonable uses of a distro), and i386 being 
a de-facto standard for software interfaces.

> As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it
> much in the real world.  I have one 32 bit desktop at work, and
> comparing the resident RAM usage between it and a 64 bit desktop, I
> don't see much difference in the common desktop programs.

That's the wrong comparison - compare the aggregate RAM usage, with 
each system in similar states.

> I know that for some reason PHP on 64 bit arches bloats up 
> significantly (at least older versions), but that's the only major 
> difference I've seen.

Pointer rich data structures, likely..

Anyway, as I don't intend to contribute anything, I'll try stop 
making noise.

Aside to the list: Thanks for all the hard-work on Fedora ;)

regards,
-- 
Paul Jakma	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Dogs just don't seem to be able to tell the difference between important people
and the rest of us.




More information about the fedora-devel-list mailing list