Your message dated Sun, 27 Apr 2014 14:59:29 -0600 with message-id <[email protected]> and subject line Closing, was fixed in 2.18-1 has caused the Debian Bug report #718577, regarding libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations 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 [email protected] immediately.) -- 718577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718577 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Version 2.18-1 This bug was fixed with the upload of 2.18-1, as far as I can tell from the bug log. ... Adam
--- End Message ---
