[lsb-discuss] Multi-lib standards
dennis at ausil.us
Mon Nov 23 20:08:31 PST 2009
On Monday 23 November 2009 11:27:01 am Bruce Dubbs wrote:
> Dennis Gilmore wrote:
> > It really depends on the architecture. ppc64 sparc64 and most risc based
> > 64 bit arches the only thing you gain by running 64 bit software is
> > access to greater than 4GiB of ram. unlike x86_64 where you gain extra
> > registers and functionality that is only available via 64 bit mode. you
> > actually lose by running a pure 64 bit system. you end up with bigger
> > binaries that take longer to load and use more memory. that is why they
> > generally run 64 bit kernels and 32 bit userland.
> That is in general agreement with my previous post. Do you have any
> data about how much bigger the binaries are in non-x86/x86-64
> architectures? Except for some limited embedded applications, I
> wouldn't think that the 10% size penalty for x86_64 that I saw would be
> considered significant.
> >> Because maintaining two sets of libraries where one will do is
> >> non-trivial and expensive. At a minimum, all changes have to tested
> >> twice.
> > it is trivial and still needed. people are still making 32 bit cpus in
> > mass quantities today. at least how Fedora builds its packages, we use
> > the 32 bit rpms for multilib on 64 bit arches. we build one set of 32 bit
> > and one set of 64 bit rpms. I also tend to run my kvm virtual machines
> > 32 bit even though the host is 64 bit. all the early atom cpus were 32
> > bit the amd geode is 32 bit, via ships 32 bit x86 cpus. other arches
> > like arm are currently only 32 bit. You really can not make a general
> > assumption on this based solely on x86/x86_64
> I see your point.
> >> I'm not sure you are using the term deprecate in the same way I am. To
> >> me it means that it is discouraged and at some indefinite point in the
> >> future it will be removed. Using that definition, I see no reason not
> >> to declare a mixed 32-bit and 64-bit system as deprecated right now.
> > on non x86/x86_64 arches its desirable. I suggest that we don't do that.
> > If that statement is mad it should be made clear that its for particular
> > arches only.
> Since I don't have any recent non-x86/x86_64 experience, I can't dispute
> your point, but I would like to see some data to demonstrate what is
> gained and lost by running on these other architectures.
> The fundamental question here is whether the additional performance
> warrants the additional complexity.
32 bit sparc
-rwxr-xr-x 1 root root 869K 2009-08-11 00:45 /bin/bash
-rwxr-xr-x 1 root root 318K 2009-08-12 00:19 /usr/lib/libcurl.so.4.1.1
-rwxr-xr-x 1 root root 184K 2009-08-17 00:57 /lib/libpcre.so.0.0.1
64 bit sparc
-rwxr-xr-x 1 root root 905K 2009-08-11 00:45 /bin/bash
-rwxr-xr-x 1 root root 350K 2009-08-12 00:21 /usr/lib64/libcurl.so.4.1.1
-rwxr-xr-x 1 root root 192K 2009-08-17 00:56 /lib64/libpcre.so.0.0.1
the binaries are a little bigger but not a huge amount.
32 bit bash running output from ps axv
2611 pts/0 S+ 0:01 1 931 4612 2128 0.0 /bin/bash -i
64 bit bash running output from ps axv
2626 pts/1 S+ 0:00 0 1927 88392 2376 0.0 /bin/bash -i
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20091123/1e1716cc/attachment-0001.pgp
More information about the lsb-discuss