Processed: issetugid
Processing commands for cont...@bugs.debian.org:
forcemerge 718181 635205
Bug #718181 {Done: Adam Conrad adcon...@0c3.net} [libc0.1-dev] missing
declaration for issetugid
Bug #718181 {Done: Adam Conrad adcon...@0c3.net} [libc0.1-dev] missing
declaration for issetugid
Marked as found in versions eglibc/2.11.2-10.
Bug #635205 [libc0.1-dev] libc0.1-dev: no declaration of function 'issetugid'
Severity set to 'important' from 'normal'
Marked Bug as done
Marked as fixed in versions eglibc/2.17-91.
Marked as found in versions eglibc/2.13-38.
Merged 635205 718181
End of message, stopping processing here.
Please contact me if you need assistance.
--
635205: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635205
718181: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718181
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
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/handler.s.c.13754524424777.transcr...@bugs.debian.org
Bug#718577: libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
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
Bug#718577: libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
On Fri, Aug 2, 2013 at 12:10 PM, bugsbuster hal.bugsbus...@gmail.com wrote: * What led up to the situation? Upstream glibc fixed a number of correctness issues in non-default rounding modes. These correctness issues had a performance impact which has only just been fixed in 2.18. I suggest Debian backport Siddhesh Poyarekar's work to fix this: ~~~ commit 2506109403de69bd454de27835d42e6eb6ec3abc Author: Siddhesh Poyarekar siddh...@redhat.com Date: Wed Jun 12 10:36:48 2013 +0530 Set/restore rounding mode only when needed The most common use case of math functions is with default rounding mode, i.e. rounding to nearest. Setting and restoring rounding mode is an unnecessary overhead for this, so I've added support for a context, which does the set/restore only if the FP status needs a change. The code is written such that only x86 uses these. Other architectures should be unaffected by it, but would definitely benefit if the set/restore has as much overhead relative to the rest of the code, as the x86 bits do. Here's a summary of the performance improvement due to these improvements; I've only mentioned functions that use the set/restore and have benchmark inputs for x86_64: Before: cos(): ITERS:4.69335e+08: TOTAL:28884.6Mcy, MAX:4080.28cy, MIN:57.562cy, 16248.6 calls/Mcy exp(): ITERS:4.47604e+08: TOTAL:28796.2Mcy, MAX:207.721cy, MIN:62.385cy, 15543.9 calls/Mcy pow(): ITERS:1.63485e+08: TOTAL:28879.9Mcy, MAX:362.255cy, MIN:172.469cy, 5660.86 calls/Mcy sin(): ITERS:3.89578e+08: TOTAL:28900Mcy, MAX:704.859cy, MIN:47.583cy, 13480.2 calls/Mcy tan(): ITERS:7.0971e+07: TOTAL:28902.2Mcy, MAX:1357.79cy, MIN:388.58cy, 2455.55 calls/Mcy After: cos(): ITERS:6.0014e+08: TOTAL:28875.9Mcy, MAX:364.283cy, MIN:45.716cy, 20783.4 calls/Mcy exp(): ITERS:5.48578e+08: TOTAL:28764.9Mcy, MAX:191.617cy, MIN:51.011cy, 19071.1 calls/Mcy pow(): ITERS:1.70013e+08: TOTAL:28873.6Mcy, MAX:689.522cy, MIN:163.989cy, 5888.18 calls/Mcy sin(): ITERS:4.64079e+08: TOTAL:28891.5Mcy, MAX:6959.3cy, MIN:36.189cy, 16062.8 calls/Mcy So the improvements are: cos: 27.9089% exp: 22.6919% pow: 4.01564% sin: 19.1585% tan: 1.96086% The downside of the change is that it will have an adverse performance impact on non-default rounding modes, but I think the tradeoff is justified. ~~~ -- 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/CAE2sS1j3-Q4kTkmbtjokiSBcQnTDeG=yuhhv5xtybv19was...@mail.gmail.com
Bug#718577: libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
Hello, First of all, thank you for this quick answer and sorry for this (long) answer... However, I am not sure (sorry) to understand the full consequences of what you called a justified tradeoff... I cannot fully explain what I am doing exactly but I am working on soft real-time avionic problems and the use of libm2-17 is ... IMPOSSIBLE since it multiplies by two the duration of all our computations... Do you mean that all these catastrophic overheads are no longer existing in libm-2.18 ? In this case, please do not read the following sentences, this is really a good result for me. Otherwise - I cannot believe it - but I should mention that I am just using mathematic libraries as a beginner and I do not want to enter in sophisticated modes of the libm (no time/money for this) as well as the worldwide company for which I am working... and I fully disagree on the fact that the tradeoff is justified this is absolutely not true in my case and I do not use specific rounding modes, just the default options of the libm and gcc... Fortunately, till now same results are obtained via libm-2.13 and libm-2.17... but how can I explain/justify that it needs almost twice as much time? It is just IMPOSSIBLE/INCREDIBLE! I think that this will have a *SERIOUS* negative impact on the trust in linux in its ability to stay competitive/efficient in this kind of computations... Am I really the only one facing these ugly counterperformances of libm? So, sorry again if I misunderstood something, but I also need to automatize the installation of the mentioned program on several computers without using complicated tricks as backports and so on... So,what is the best and efficient way to proceed ? Keep libm-2.13 as long as possible or avoid any further trigonometric computation on Linux (and start using an FPGA -for instance - to be more efficient with future versions of libm)? To be as constructive as possible, is there a simple/concrete way to use the right rounding mode (WITHOUT MODIFYING THE FINAL RESULTS) in gcc with libm-2.18 or libm-2-17 with NO overhead? Otherwise, this is - in my opinion - really catastrophic for [Debian_]Linux... Sorry for my comments, as I said I am NOT a specialist in libm nor trigonometric tricks but I cannot hide the fact that I am really disappointed by this answer if there is no simple solution based on libm-2.17 or libm-2.18... Many thanks again for the answer... Still searching for a durable efficient solution, BB 2013/8/3 Carlos O'Donell car...@systemhalted.org On Fri, Aug 2, 2013 at 12:10 PM, bugsbuster hal.bugsbus...@gmail.com wrote: * What led up to the situation? Upstream glibc fixed a number of correctness issues in non-default rounding modes. These correctness issues had a performance impact which has only just been fixed in 2.18. I suggest Debian backport Siddhesh Poyarekar's work to fix this: ~~~ commit 2506109403de69bd454de27835d42e6eb6ec3abc Author: Siddhesh Poyarekar siddh...@redhat.com Date: Wed Jun 12 10:36:48 2013 +0530 Set/restore rounding mode only when needed The most common use case of math functions is with default rounding mode, i.e. rounding to nearest. Setting and restoring rounding mode is an unnecessary overhead for this, so I've added support for a context, which does the set/restore only if the FP status needs a change. The code is written such that only x86 uses these. Other architectures should be unaffected by it, but would definitely benefit if the set/restore has as much overhead relative to the rest of the code, as the x86 bits do. Here's a summary of the performance improvement due to these improvements; I've only mentioned functions that use the set/restore and have benchmark inputs for x86_64: Before: cos(): ITERS:4.69335e+08: TOTAL:28884.6Mcy, MAX:4080.28cy, MIN:57.562cy, 16248.6 calls/Mcy exp(): ITERS:4.47604e+08: TOTAL:28796.2Mcy, MAX:207.721cy, MIN:62.385cy, 15543.9 calls/Mcy pow(): ITERS:1.63485e+08: TOTAL:28879.9Mcy, MAX:362.255cy, MIN:172.469cy, 5660.86 calls/Mcy sin(): ITERS:3.89578e+08: TOTAL:28900Mcy, MAX:704.859cy, MIN:47.583cy, 13480.2 calls/Mcy tan(): ITERS:7.0971e+07: TOTAL:28902.2Mcy, MAX:1357.79cy, MIN:388.58cy, 2455.55 calls/Mcy After: cos(): ITERS:6.0014e+08: TOTAL:28875.9Mcy, MAX:364.283cy, MIN:45.716cy, 20783.4 calls/Mcy exp(): ITERS:5.48578e+08: TOTAL:28764.9Mcy, MAX:191.617cy, MIN:51.011cy, 19071.1 calls/Mcy pow(): ITERS:1.70013e+08: TOTAL:28873.6Mcy, MAX:689.522cy, MIN:163.989cy, 5888.18 calls/Mcy sin(): ITERS:4.64079e+08: TOTAL:28891.5Mcy, MAX:6959.3cy, MIN:36.189cy, 16062.8 calls/Mcy So the improvements are: cos: 27.9089% exp: 22.6919% pow: 4.01564% sin: 19.1585% tan: 1.96086% The downside of the change is that it will have an adverse performance impact on non-default rounding modes, but I think the tradeoff is
Processed: Re: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
Processing commands for cont...@bugs.debian.org: tags 718577 + upstream patch Bug #718577 [libc6] libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations Added tag(s) upstream and patch. quit Stopping processing here. Please contact me if you need assistance. -- 718577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718577 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.137548799810040.transcr...@bugs.debian.org
Bug#718577: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
tags 718577 + upstream patch quit Hal BugsBuster wrote: Do you mean that all these catastrophic overheads are no longer existing in libm-2.18 ? Yes, I believe Carlos was saying that glibc 2.18 has a fix for the performance regression, which Debian should apply: commit 2506109403de69bd454de27835d42e6eb6ec3abc Author: Siddhesh Poyarekar siddh...@redhat.com Date: Wed Jun 12 10:36:48 2013 +0530 Set/restore rounding mode only when needed [...] So the improvements are: cos: 27.9089% exp: 22.6919% pow: 4.01564% sin: 19.1585% tan: 1.96086% Thanks for your kindness and patience, and hope that helps, Jonathan -- 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/20130802235942.GA2945@elie.Belkin
Bug#718577: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
Hello, Thank you again for this quick answer... It would be REALLY good news (for me). Thank you again, BB 2013/8/3 Jonathan Nieder jrnie...@gmail.com tags 718577 + upstream patch quit Hal BugsBuster wrote: Do you mean that all these catastrophic overheads are no longer existing in libm-2.18 ? Yes, I believe Carlos was saying that glibc 2.18 has a fix for the performance regression, which Debian should apply: commit 2506109403de69bd454de27835d42e6eb6ec3abc Author: Siddhesh Poyarekar siddh...@redhat.com Date: Wed Jun 12 10:36:48 2013 +0530 Set/restore rounding mode only when needed [...] So the improvements are: cos: 27.9089% exp: 22.6919% pow: 4.01564% sin: 19.1585% tan: 1.96086% Thanks for your kindness and patience, and hope that helps, Jonathan
Bug#718577: libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
On Fri, Aug 2, 2013 at 7:45 PM, Hal BugsBuster hal.bugsbus...@gmail.com wrote: I cannot fully explain what I am doing exactly but I am working on soft real-time avionic problems and the use of libm2-17 is ... IMPOSSIBLE since it multiplies by two the duration of all our computations... I'm sorry to hear that, please feel free to volunteer your time to help upstream glibc or debian ensure that issues like this get fixed and tested quickly. Alternatively you can get involved to voice your opposition to changes to fix correctness over performances. Do you mean that all these catastrophic overheads are no longer existing in libm-2.18 ? The overhead depends on the rounding mode you are in. If you are using the default rounding mode and are on x86 or x86-64, then the overhead is significantly reduced in 2.18 (almost back to the original performance). In this case, please do not read the following sentences, this is really a good result for me. You don't really want all of 2.18, just the fix to bring performance back for certain libm functions. Otherwise - I cannot believe it - but I should mention that I am just using mathematic libraries as a beginner and I do not want to enter in sophisticated modes of the libm (no time/money for this) as well as the worldwide company for which I am working... and I fully disagree on the fact that the tradeoff is justified this is absolutely not true in my case and I do not use specific rounding modes, just the default options of the libm and gcc... Don't upgrade to 2.17 then. Wait for the bug to get fixed. Fortunately, till now same results are obtained via libm-2.13 and libm-2.17... but how can I explain/justify that it needs almost twice as much time? It is just IMPOSSIBLE/INCREDIBLE! The same results for some small finite set of inputs you tested? Upstream needs to make sure it returns correct results for the entire set of inputs in all modes. In this particular case we chose returning a correct answer over returning an incorrect answer (albeit quickly). This fixed a serious and real problem that other users were facing. Once we had that problem fixed we then proceeded to fix the performance and to try and restore it to original levels without returning incorrect answers. I think that this will have a *SERIOUS* negative impact on the trust in linux in its ability to stay competitive/efficient in this kind of computations... I disagree. Linux has nothing to do with this. This is all in the GNU C Library. You rely on your distribution to be aware of issues like this and to ensure that their glibc is updated in a timely fashion. Each distribution does what they do for their users. There are other distributions which have this defect already fixed. You are free to use whatever distribution you want. I bet Debian will have this fixed quickly, but you need to talk them to get it fixed. I'm an upstream glibc maintainer who reads this list in order to provide quick feedback about glibc issues. Am I really the only one facing these ugly counterperformances of libm? No. Lots of other people have reported this problem. So, sorry again if I misunderstood something, but I also need to automatize the installation of the mentioned program on several computers without using complicated tricks as backports and so on... So,what is the best and efficient way to proceed ? That is for you to judge with the help of those who assist you in your system installation and configuration. I'm not here to help in that capacity. Keep libm-2.13 as long as possible or avoid any further trigonometric computation on Linux (and start using an FPGA -for instance - to be more efficient with future versions of libm)? That is up to you to decide. Given that you have stated you have limited resources I would simply wait for the bug to be fixed. To be as constructive as possible, is there a simple/concrete way to use the right rounding mode (WITHOUT MODIFYING THE FINAL RESULTS) in gcc with libm-2.18 or libm-2-17 with NO overhead? Otherwise, this is - in my opinion - really catastrophic for [Debian_]Linux... No. You need to get glibc updated. And it's Debian GNU/Linux, but it also impacts any Debian derivative that uses glibc e.g. Debian GNU/kFreeBSD. Sorry for my comments, as I said I am NOT a specialist in libm nor trigonometric tricks but I cannot hide the fact that I am really disappointed by this answer if there is no simple solution based on libm-2.17 or libm-2.18... Upstream glibc is working very hard on performance microbenchmarks to use to ensure that core functional changes do not regress performance between releases. The math library is the first target for this microbenchmark framework. It is the first framework of it's kind in glibc, there has never been one in the past before. It is our hope that with the framework in place we can better determine the final performance impact that certain changes have on our users. We hope that our
