public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libm] pow() function execution time increase by factor 4000
@ 2014-05-02 20:45 Stefani Seibold
  2014-05-02 22:43 ` Carlos O'Donell
  0 siblings, 1 reply; 2+ messages in thread
From: Stefani Seibold @ 2014-05-02 20:45 UTC (permalink / raw)
  To: glibc-bugs

A pow(10.0, x) where x has the hex equivalent of 0xc022247c7a9c48f9l
needs 4000 times longer as x equal 0xc022247c7a9c4800l, which is nearly
the same value.

This happens on x86_64 Linux. I have tested it with the current git tree
and GLIB 2.19, but the behavior can also reproduced on an old EGLIBC
2.12 32 bit PowerPC Linux system.

The origin the fdlibm pow() function does not show this performance
impact, but is nearly three times slower as the best case libm execution
time. The result of the function call are the same.

As i figured out the value 0xc022247c7a9c48f9l run into the __slowpow()
branch, where 0xc022247c7a9c4800l does bypass this branch.

A "perf stat -e instructions" show that the 0xc022247c7a9c48f9 value
needs round about 1505962 instructions, the 0xc022247c7a9c4800l needs
only 385 instructions.

On the old PowerPC device the execution time is 1 us vs. 5000 us.

This makes pow() not very useable in a realtime environment.

Maybe the exp() has the same problem.

- Stefani



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Bug libm] pow() function execution time increase by factor 4000
  2014-05-02 20:45 [Bug libm] pow() function execution time increase by factor 4000 Stefani Seibold
@ 2014-05-02 22:43 ` Carlos O'Donell
  0 siblings, 0 replies; 2+ messages in thread
From: Carlos O'Donell @ 2014-05-02 22:43 UTC (permalink / raw)
  To: Stefani Seibold, glibc-bugs

On 05/02/2014 04:44 PM, Stefani Seibold wrote:
> A pow(10.0, x) where x has the hex equivalent of 0xc022247c7a9c48f9l
> needs 4000 times longer as x equal 0xc022247c7a9c4800l, which is nearly
> the same value.
> 
> This happens on x86_64 Linux. I have tested it with the current git tree
> and GLIB 2.19, but the behavior can also reproduced on an old EGLIBC
> 2.12 32 bit PowerPC Linux system.
> 
> The origin the fdlibm pow() function does not show this performance
> impact, but is nearly three times slower as the best case libm execution
> time. The result of the function call are the same.
> 
> As i figured out the value 0xc022247c7a9c48f9l run into the __slowpow()
> branch, where 0xc022247c7a9c4800l does bypass this branch.
> 
> A "perf stat -e instructions" show that the 0xc022247c7a9c48f9 value
> needs round about 1505962 instructions, the 0xc022247c7a9c4800l needs
> only 385 instructions.
> 
> On the old PowerPC device the execution time is 1 us vs. 5000 us.
> 
> This makes pow() not very useable in a realtime environment.
> 
> Maybe the exp() has the same problem.
> 
> - Stefani

This is not the right place to report a bug.

Please see:
http://www.gnu.org/software/libc/bugs.html

In addition what you're reporting is not a bug, but we can
discuss this in the bug you open.

Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-05-02 22:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-02 20:45 [Bug libm] pow() function execution time increase by factor 4000 Stefani Seibold
2014-05-02 22:43 ` Carlos O'Donell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).