[Bug math/16898] New: pow() function execution time increase by factor 4000

["stefani at seibold dot net" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16898

            Bug ID: 16898
           Summary: pow() function execution time increase by factor 4000
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: stefani at seibold dot net

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.