Re: future libc6-sparcv9 and libc6-sparcv9b support
From: GOTO Masanori <gotom@debian.or.jp>
Date: Thu, 18 Aug 2005 14:07:28 +0900
> 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.
> 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.
Reply to: