[lsb-discuss] Multi-lib standards

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


Regards

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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 mailing list