Re: future libc6-sparcv9 and libc6-sparcv9b support
At Thu, 18 Aug 2005 02:39:23 -0400 (EDT),
David S. Miller wrote:
> > I have a question about optimization package: libc6-sparcv9 and
> > libc6-sparcv9b. Both packages are prepared for optimized versions of
> > libc6. They are currently supported - but I would like to know what
> > the advantage of those packages is. Just optimization? Are those
> > packages widely used?
> Besides being compiled with the proper optimization and feature
> options, they use memcpy and memset implementations which are
> several orders of magnitude faster than plain Sparc versions.
> Every single UltraSPARC debian system I have has these special
> versions of the library installed. You can feel the difference
> these libraries make, performance wise, in many cases.
Well, we sometimes meet words "optimization makes faster", but we
merely see the actual result of performance gain.
How much is the improvement of such optimized packages? Is sparcv9b
valuable compared with sparcv9?
> > These days 2.6 kernel is getting popularity, so it's nice time to
> > support NPTL on sparc systems. But having a lot of optimized packages
> > and variants like NPTL take much longer build time + maintenance cost.
> > If we replace unpopular optimized libc6 packages with NPTL libc6 in
> > future, it's much valuable for users, I think.
> > How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled
> > libc6 in future?
> You'll only get NPTL to work on sparcv9 and later anyways.
> Pure traditional sparc 32-bit NPTL is non-functioning even
> in the current glibc tree. And I doubt there is much incentive
> to write the support.
> Only sparcv9 and later work with NPTL, and since it requires TLS this
> means current CVS binutils is necessary as well especially if you wish
> to build 64-bit NPTL enabled glibc on sparc as well.
Thanks for your precious follow up.
From your suggestion, normal libc6 package (that's also usable for
pre sparcv9 archs) does not have any NPTL support, but libc6-sparcv9
(and v9b) can have NPTL support. IIRC, you have worked for 64bit NPTL
support on sparc, so I expect libc6-sparc64 will be able to support
NPTL without hassle.
BTW, if we move to glibc 2.4 series in future, at that time we may
need to drop LT support. It means the traditional pre sparcv9 system
will be also dropped. Is that acceptable direction for sparc users?
(Note that dropping LT is not decided and I think we shouldn't do so