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

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

 



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@xxxxxxxxx	Key ID: 64A2FF6A
Fortune:
Dogs just don't seem to be able to tell the difference between important people
and the rest of us.

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux