Bug#709756: (libc6 2.17 performance slowdown)
Aurelien Jarno writes: > On Sun, Jun 02, 2013 at 04:53:35PM +0100, Andrew M. Bishop wrote: >> I have done some more investigation and the cause of the slowdown >> appears to be this bug-fix to eglibc: >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=13658 >> Other people are reporting the slowdown as well and there is an eglibc >> bug report: >> >> http://www.sourceware.org/bugzilla/show_bug.cgi?id=14412 >> >> No solution seems forthcoming and the bug is only marked as an >> "enhancement" rather than critical. > > The problem is supposed to have been fixed in version 2.18. In practice > on my machine, I see that with version 2.18 the performances are almost > back to the 2.17 level, with version 2.19 the performances are slightly > above 2.17. > > I therefore guess that the problem is fixed and that the bug could be > closed. Could you please try and confirm? I have run the same nbench benchmark as before (on the same computer) with libc6 version 2.18 (Debian package version 2.18-7 to be exact): TEST: Iterations/sec. : : : :--: NUMERIC SORT: 1049.2 : STRING SORT : 591.44 : BITFIELD: 5.3321e+08 : FP EMULATION: 200.18 : FOURIER : 36286 : ASSIGNMENT : 42.186 : IDEA: 7965.2 : HUFFMAN : 3676.4 : NEURAL NET : 54.476 : LU DECOMPOSITION: 2053.2 : ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 103.185 FLOATING-POINT INDEX: 72.690 ==LINUX DATA BELOW=== CPU : 4 CPU GenuineIntel Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz 2424MHz L2 Cache: 3072 KB OS : Linux 3.14.1-24 C compiler : gcc version 4.7.3 (Debian 4.7.3-4) libc: MEMORY INDEX: 31.925 INTEGER INDEX : 21.915 FLOATING-POINT INDEX: 40.317 The results are slightly better than the benchmarks reported in the original bug report. The FOURIER result in particular is faster with libc 2.18 than it was with either 2.13 and 2.17 and by a fairly significant margin. This clearly fixes the problem in version 2.17 and in fact improves on the earlier version as well. -- Andrew Bishop -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709756: (libc6 2.17 performance slowdown)
On Sun, Jun 02, 2013 at 04:53:35PM +0100, Andrew M. Bishop wrote: > I have done some more investigation and the cause of the slowdown > appears to be this bug-fix to eglibc: > > http://sourceware.org/bugzilla/show_bug.cgi?id=13658 > > My (possibly biased) summary of this change is that one user reported > inaccurate sincos results for very large numbers so the eglibc library > was changed so that *all* sin, cos and sincos functions now use soft > maths functions rather than the FPU. > > > Other people are reporting the slowdown as well and there is an eglibc > bug report: > > http://www.sourceware.org/bugzilla/show_bug.cgi?id=14412 > > No solution seems forthcoming and the bug is only marked as an > "enhancement" rather than critical. The problem is supposed to have been fixed in version 2.18. In practice on my machine, I see that with version 2.18 the performances are almost back to the 2.17 level, with version 2.19 the performances are slightly above 2.17. I therefore guess that the problem is fixed and that the bug could be closed. Could you please try and confirm? -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709756: (libc6 2.17 performance slowdown)
I have done some more investigation and the cause of the slowdown appears to be this bug-fix to eglibc: http://sourceware.org/bugzilla/show_bug.cgi?id=13658 My (possibly biased) summary of this change is that one user reported inaccurate sincos results for very large numbers so the eglibc library was changed so that *all* sin, cos and sincos functions now use soft maths functions rather than the FPU. Other people are reporting the slowdown as well and there is an eglibc bug report: http://www.sourceware.org/bugzilla/show_bug.cgi?id=14412 No solution seems forthcoming and the bug is only marked as an "enhancement" rather than critical. -- Andrew Bishop -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709756: libc6 2.17 performance slowdown
Package: libc6 Version: 2.17-3 Severity: important Version 2.17-3 of libc6 in testing is significantly slower than version 2.13-38 in stable. Installing only the updated libc6 and dependent packages causes a slowdown of up to 50% in parts of a benchmark test. The tests below were run on a VirtualBox client Debian Gnu/Linux i386 installation of testing before and after upgrading libc6. The exact list of changed packages is the following: -ii libc-dev-bin 2.13-38 i386 Embedded GNU C Library: Development binaries -ii libc6:i386 2.13-38 i386 Embedded GNU C Library: Shared libraries -ii libc6-dev:i386 2.13-38 i386 Embedded GNU C Library: Development Libraries and Header Files -ii libc6-i686:i386 2.13-38 i386 Embedded GNU C Library: Shared libraries [i686 optimized] -ii locales 2.13-38 all Embedded GNU C Library: National Language (locale) data [support] +ii libc-dev-bin 2.17-3 i386 Embedded GNU C Library: Development binaries +ii libc6:i386 2.17-3 i386 Embedded GNU C Library: Shared libraries +ii libc6-dev:i386 2.17-3 i386 Embedded GNU C Library: Development Libraries and Header Files +ii libc6-i686:i386 2.17-3 i386 Embedded GNU C Library: Shared libraries [i686 optimized] +ii locales 2.17-3 all Embedded GNU C Library: National Language (locale) data [support] The test program was nbench2: http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz The only modification to the program was make the compiled executable dynamically linked instead of statically linked: --- Makefile~ 2004-12-30 02:23:30.0 + +++ Makefile2013-05-25 08:33:44.841319746 +0100 @@ -25 +25 @@ -CFLAGS = -s -static -Wall -O3 +CFLAGS = -s -Wall -O3 The results with libc6 2.13-38 are: TEST: Iterations/sec. : :--: NUMERIC SORT: 1063.5 : STRING SORT : 578.16 : BITFIELD: 5.1673e+08 : FP EMULATION: 183.46 : FOURIER : 28943 : ASSIGNMENT : 40.862 : IDEA:7928 : HUFFMAN : 3732.5 : NEURAL NET : 49.96 : LU DECOMPOSITION:1723 : ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 101.010 FLOATING-POINT INDEX: 61.778 ==LINUX DATA BELOW=== CPU : GenuineIntel Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz 0MHz L2 Cache: 6144 KB OS : Linux 3.9.0-1 C compiler : gcc version 4.7.2 (Debian 4.7.2-5) libc: MEMORY INDEX: 31.023 INTEGER INDEX : 21.571 FLOATING-POINT INDEX: 34.264 The results with libc6 2.17-3 (not re-compiled) are: TEST: Iterations/sec. : :--:- NUMERIC SORT: 1092.6 : STRING SORT : 602.64 : BITFIELD: 5.1374e+08 : FP EMULATION: 166.96 : FOURIER : 12296 : ASSIGNMENT : 38.235 : IDEA:7868 : HUFFMAN : 3462.4 : NEURAL NET : 51.758 : LU DECOMPOSITION:2237 : ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 98.435 FLOATING-POINT INDEX: 51.265 ==LINUX DATA BELOW=== CPU : GenuineIntel Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz 2396MHz L2 Cache: 6144 KB OS : Linux 3.9.0-1 C compiler : gcc version 4.7.2 (Debian 4.7.2-5) libc: MEMORY INDEX: 30.706 INTEGER INDEX : 20.777 FLOATING-POINT INDEX: 28.434 The overall benchmark is 5%-10% slower but the FOURIER sub-test only achieves half the rate. Recompiling on the system with the new libc6 produces similar results, in particular the FOURIER sub-test is still half the rate. When testing one of my own programs I see a slowdown of between 30% and 100%. -- Andrew. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
