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,

2013/8/3 Carlos O'Donell <carlos@systemhalted.org>

On Fri, Aug 2, 2013 at 12:10 PM, bugsbuster <hal.bugsbuster@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 <siddhesh@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.
~~~