Package: libc6 Version: 2.17-7 Severity: important Dear Maintainer,
* What led up to the situation? I tried to upgrade my debian testing 64 bits, based on a 3.2.0-amd64 kernel (and libc6/libm-2.13.so) to use the current testing/jessie debian based on a 3.9.8-amd64 kernel (and libc6/libm-2.17.so). Before any modification, here is the configuration for libm.so.6 & cie: # uname -a Linux XXX 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux # cat /etc/debian_version jessie/sid # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.9-1-amd64 root=UUID=... ro quiet # grep name /proc/cpuinfo model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz # ls -l /lib/x86_64-linux-gnu/libm.so.6 lrwxrwxrwx 1 root root 34 août 2 11:39 /lib/x86_64-linux-gnu/libm.so.6 -> /lib/x86_64-linux-gnu/libm-2.17.so # file /lib/x86_64-linux-gnu/libm-2.17.so /lib/x86_64-linux-gnu/libm-2.17.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=45ca5df04f1a1ae3f9ef707c6fa167b35649971e, for GNU/Linux 2.6.32, stripped And one of my programs suddenly appears to be very slow in this new Debian version. I tried on a second machine (with another processor (intel i7 ws i5) & hardware (HP vs DELL)) and I observed exactly the same problem. * What exactly did you do (or not do) that was effective (or ineffective)? I searched a while and finaly retrieved the old version of libm (libm-2.13.so), because my program is intensively using libm and obtained the following results when switching between the two versions of libm (running with jessie) : # gcc loopmodel1.c -o loopmodel1 -O2 -Wall -Wextra -lm # strip loopmodel1 # rm /lib/x86_64-linux-gnu/libm.so.6 # ln -s /lib/x86_64-linux-gnu/libm-2.13.so /lib/x86_64-linux-gnu/libm.so.6 # file /lib/x86_64-linux-gnu/libm-2.13.so /lib/x86_64-linux-gnu/libm-2.13.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=6db0096207f3ccc0ea5f39304c7153becb0b821a, for GNU/Linux 2.6.26, stripped # /usr/bin/time -v ./loopmodel1 Command being timed: "./loopmodel1" User time (seconds): 297.27 System time (seconds): 0.00 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:58.12 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 496 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 173 Voluntary context switches: 1 Involuntary context switches: 25199 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # rm /lib/x86_64-linux-gnu/libm.so.6 # ln -s /lib/x86_64-linux-gnu/libm-2.17.so /lib/x86_64-linux-gnu/libm.so.6 # /usr/bin/time -v ./loopmodel1 Command being timed: "./loopmodel1" User time (seconds): 633.36 System time (seconds): 0.00 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 10:35.16 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 540 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 183 Voluntary context switches: 1 Involuntary context switches: 53690 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 * What was the outcome of this action? Using the old-testing version of libm (libm-2.13.so) on the same OS without recompiling makes my program run almost two times faster than using the current testing version of libm (libm-2.17.so). * What outcome did you expect instead? At least same speed using the two versions of libm ! I cannot provide the "original program" (confidential) but I can provide a simplified/modified program, using exclusively trigonometric functions and a loop to provide an example of such "problem". Firstly I suspected a problem between i386 and amd64 versions of libm-2.17.so because on one of the computers I had to use the command "dpkg --add-architecture i386" to install some 32bits libraries which are required by a 3D visualization program. But this is not installed on the second computer! I have also posted this question in Debian forums with no conclusive answer. Do you know if there is a bug in libm-2.17.so ? Anybody else observes this result ? Thank you in advance, BB -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130802161053.7131.11441.report...@pcdduvivier.univ-valenciennes.fr