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 users will contribute to the microbenchmark framework in order to ensure that their use cases do not regress in performance. Cheers, Carlos. -- 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/CAE2sS1i5T2-=yr_8qclx9-71nl2tazopf_t339z6stzrgkv...@mail.gmail.com