Dear Carlos, One more time, thank you again for your quick and detailed answer... I really appreciate...
I do not want to "voice my opposition to changes to fix correctness over performances" because this does not make sense: I fully agree on the fact that quickly obtaining false result(s) is useless. However, before posting, the first thing I verified is the accuracy of the results in both versions of the libm. I still cannot observe any deviation in the results... However I (only) intensively use sin(), cos(), sqrt() and fabs(). This might explain why I cannot see any improvement in the computation of "some small finite set of inputs". I should also mention that "the application on which I am working" does not require high precision (we exclusively use "float" and no "double" for instance) and is mainly focused on a tradeoff between speed and accuracy... This might also explain the huge variation in the durations of the programs based on the two versions of libm. I would like to do something to help improving libm (for instance) but I am really not competent in this field... All I can do is to provide a factice example of program, but I am sure that you have a set of much more accurate and detailed benchmarks... I am also working on "calculation servers" (exclusively) based on x86-64, so the fact that the overhead is significantly reduced in 2.18 (almost back to the original performance) is *REALLY* a *GREAT RESULT* for me! Sorry I have caused any offence by my remark about the "negative impact on the trust in linux in its ability to stay competitive/efficient in this kind of computations" ... The performances obtained under Linux and libc6 (and...) are remarkable and the abovementioned results obtained with libm2-17 were really "disappointing". I see Linux (not only) as a competitive/efficient solution for a long time, even if it is not its main objective. I can experimentally prove this one more time with the abovementioned program and I could not believe in the latest results (with libm2-17)... I fully agree when you say that "the math library is the first target"! "My problem" is just one additional (real-world) example where, with no efficient and accurate libm, nothing can be achieved! I consider this as *the* solution, and will no longer bother you with my comments about libc6/libm. Thank you again, sorry for all these (long) mails, BB 2013/8/3 Carlos O'Donell <[email protected]> > On Fri, Aug 2, 2013 at 7:45 PM, Hal BugsBuster <[email protected]> > 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 users will contribute to the microbenchmark framework > in order to ensure that their use cases do not regress in performance. > > Cheers, > Carlos. >
