glibc source rpm and nptl
Rakesh Patel
rapatel at optonline.net
Sun Nov 30 22:52:49 UTC 2003
Jakub Jelinek wrote:
>On Sun, Nov 30, 2003 at 03:41:39PM -0500, Rakesh Patel wrote:
>
>
>>So the Fedora Core 1 Kernel for x86 uses NPTL but the glibc for x86 does
>>not?
>>
>>
>
>If you install glibc-2.3.2*.i386.rpm, then it does not use NPTL.
>This is the library which should be installed on all < i686 CPUs
>(where i686 in this context means i686 CPUs with CMOV instructions).
>
>
>
>But, on almost all current x86 boxes you want glibc-2.3.2*.i686.rpm
>installed (FC1 installer or up2date will certainly prefer this package if the
>hardware supports it) and that has NPTL support in it.
>Similarly it supports NPTL if you build a .athlon.rpm package (not included
>in the distribution, because the gains are not even measurable).
>
>
Yes, my install was certainly the i686 version after checking.
Obviously I misunderstood what was installed
on my machine.
>>make any difference [using athlon-mp and -O4]. Just seems odd not to
>>
>>
>
>Why specifically -O4? -O3 or -O2147483647 do exactly the same.
>
>
>
You can ignore that one - I know -O3 was the highest level supported by
gcc a few years ago. I just used -O4 since I saw
references to it recently and assumed there may have been additional
optimizations supported by gcc since
2.x.
>Also, it would surprise me if you see a significant difference with
>-march=athlon-mp vs. -march=i686 compiled glibc. Athlon's reorder the
>instructions themselves a lot and so are much less sensitive to instruction
>scheduling. Using -mfpmath=sse for glibc is a bad idea, since it could
>make the math library less accurate (given the assumptions some routines
>do). The most important instructions which actually matter for performance
>(CMOV*; worth on average something like 1%-2%) are already used by
>glibc-*.i686.rpm. And there are no Athlon optimized assembly string
>operations in glibc. This is something which would actually be worth
>doing, so if somebody is looking for a project he can try to do something
>and benchmark it.
>
>
>
Well since I was mistaken on what levels of optmization were provided by
default, I obviously was wasting effort
assuming it functioned similarly to previous Redhat releases.
> Jakub
>
>
>--
>fedora-list mailing list
>fedora-list at redhat.com
>To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
>
>
More information about the fedora-list
mailing list