It seems that the current GLibC package for RHL v9 is noticably slower
than the lastest GLibC for RHL v7.3.
I have an application that consists of 2 components, a statically-linked
program and a shared library. Both components, in both versions of RHL,
are built with the same current version of the Intel C++ compiler.
The only difference between the application built on one version of RHL
over the other is the version of the GLibC package installed:
$ ldd revslot
not a dynamic executable
$ ldd paytable.so
libm.so.6 => /lib/libm.so.6 (0x40045000)
libc.so.6 => /lib/libc.so.6 (0x40067000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
This application is single-threaded and totally CPU bound. It does no
I/O.
The program takes 51 seconds to execute on RHL v9. The same code, built
with the same compiler, run on the same hardware, takes only 45 seconds
to execute.
The actual code being run can be thought of as having 3 parts: my own
code, built with the Intel compiler; the Intel run-time libraries,
statically linked into my app; and the GLibC libraries, referenced by my
shared library.
I can't think of any reason for the performance difference other than the
version of GlibC libraries used. For both versions of RHL the i686
versions of the respective GLibC RPMs are installed and running on a
Pentium4 machine. The same version of the Linux kernel is used in bother
environments.
Can anyone tell me why the newer version of GLibC is slower than the old?
Is there a way to improve performance with the newer code?
Thanks.
--
Shrike-list mailing list
Shrike-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/shrike-list
