Re: glibc source rpm and nptl

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@xxxxxxxxxx
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list