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 <[email protected]> > On Fri, Aug 2, 2013 at 12:10 PM, bugsbuster <[email protected]> > 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 <[email protected]> > 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. > ~~~ >
