[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#709756: marked as done (libc6 2.17 performance slowdown)



Your message dated Mon, 16 Jun 2014 21:54:33 +0200
with message-id <20140616195433.GY5346@hall.aurel32.net>
and subject line Re: Bug#709756: (libc6 2.17 performance slowdown)
has caused the Debian Bug report #709756,
regarding libc6 2.17 performance slowdown
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
709756: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709756
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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.000000000 +0000
+++ Makefile	2013-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.

--- End Message ---
--- Begin Message ---
Version: 2.18-1

On Mon, Jun 16, 2014 at 08:04:39PM +0100, Andrew M. Bishop wrote:
> Aurelien Jarno <aurelien@aurel32.net> 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.

Thanks for the test. I am therefore closing this bug as fixed in version
2.18-1.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---

Reply to: