I was attempting to rebuild glibc from the source rpm and noticed the spec file does not utilize nptl and does not specify it as an addon, but instead uses the linuxthreads addon. The Fedora Core 1 announcements indicate that NPTL is used (and the kernel sources do utilize NPTL). Is the the glibc spec file accurate? I used both the original glibc src rpm and the updated rpm [using the updated binary rpm] and both build without NPTL support.
Is the spec file correct?
Thanks, Rakesh Patel.
On Fri, Nov 28, 2003 at 10:30:37PM -0500, Rakesh Patel wrote:
I was attempting to rebuild glibc from the source rpm and noticed the spec file does not utilize nptl and does not specify it as an addon, but instead uses the linuxthreads addon. The Fedora Core 1 announcements indicate that NPTL is used (and the kernel sources do utilize NPTL). Is the the glibc spec file accurate? I used both the original glibc src rpm and the updated rpm [using the updated binary rpm] and both build without NPTL support.
Did you use --target i686 ? glibc*.i386.rpm certainly doesn't provide NPTL, NPTL doesn't support i386 architecture.
Jakub
So the Fedora Core 1 Kernel for x86 uses NPTL but the glibc for x86 does not?
That doesn't seem to make any sense - especially since I spent a bit of time trying to rebuild glibc for Redhat9 until I learned about SPEC files and how to utilize the GNU autoconf/aclocal/autoheader combinations to rebuild it and finding references to the fact that Redhat9 used NPTL [in the kernel and glibc]. Until I configured NPTL and used the SPEC file to properly patch/rebuild the glibc [with some other patches I needed], the resulting glibc would not work with Redhat9 x86 binaries.
I'm just surprised that the glibc SPEC file for fedora now no longer configures for NPTL threads even though the kernel utilizes them. With NPTL being linuxthreads compatible, maybe the glibc for fedora uses linuxthreads to avoid issues with some applications? Just want to be sure that the glibc SPEC files are accurate for x86. In this case, I really don't have any reasons to rebuild glibc, but was seeing if optimizations would make any difference [using athlon-mp and -O4]. Just seems odd not to have glibc not configured to use NPTL threads [maybe the source rpm is out of date/incorrect?].
Thanks, Rakesh Patel.
Jakub Jelinek wrote:
On Fri, Nov 28, 2003 at 10:30:37PM -0500, Rakesh Patel wrote:
I was attempting to rebuild glibc from the source rpm and noticed the spec file does not utilize nptl and does not specify it as an addon, but instead uses the linuxthreads addon. The Fedora Core 1 announcements indicate that NPTL is used (and the kernel sources do utilize NPTL). Is the the glibc spec file accurate? I used both the original glibc src rpm and the updated rpm [using the updated binary rpm] and both build without NPTL support.
Did you use --target i686 ? glibc*.i386.rpm certainly doesn't provide NPTL, NPTL doesn't support i386 architecture.
Jakub
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
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).
make any difference [using athlon-mp and -O4]. Just seems odd not to
Why specifically -O4? -O3 or -O2147483647 do exactly the same.
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.
Jakub
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@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list