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.bugsbuster@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.
Reply to: