From: GOTO Masanori <[EMAIL PROTECTED]> Date: Thu, 18 Aug 2005 19:51:45 +0900
> 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? Yes, because the optimized memcpy/memset in the sparcv9 package is severely suboptimal for UltraSPARC-III and later chips, which is what the sparcv9b package is needed for. > 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. Right. > 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 > currently). Right, it will be necessary. To be honest, pure traditional sparc 32-bit support is a real roadblock to progress in any of these areas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
