Bug 16898 - pow() function execution time increase by factor 4000
Summary: pow() function execution time increase by factor 4000
Status: RESOLVED DUPLICATE of bug 13932
Alias: None
Product: glibc
Classification: Unclassified
Component: math (show other bugs)
Version: 2.20
: P2 normal
Target Milestone: 2.19
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-05-03 12:20 UTC by stefani
Modified: 2014-06-12 19:26 UTC (History)
0 users

See Also:
Last reconfirmed:
fweimer: security-

simple test program (994 bytes, application/gz)
2014-05-03 12:21 UTC, stefani

Note You need to log in before you can comment on or make changes to this bug.
Description stefani 2014-05-03 12:20:13 UTC
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.

IMHO it is a bug since the origin fdlibm does not have this performance impact.

- Stefani

Attach is a simple test program to reproduce the issue.
Comment 1 stefani 2014-05-03 12:21:06 UTC
Created attachment 7584 [details]
simple test program
Comment 2 Joseph Myers 2014-05-07 15:42:04 UTC
This is already filed as bug 13932.

*** This bug has been marked as a duplicate of bug 13932 ***