diff options
author | Anssi Hannula <anssi.hannula@bitwise.fi> | 2020-01-27 12:45:10 +0200 |
---|---|---|
committer | Siddhesh Poyarekar <siddhesh@sourceware.org> | 2020-12-18 12:09:23 +0530 |
commit | f67f9c9af228f6b84579cb8c86312d3a7a206a55 (patch) | |
tree | ae71bde512cad296b275a769ccf68b8836c32117 /sysdeps/x86_64/fpu/s_lrint.S | |
parent | 59d572ef613252281e31f867099c43f098319ad7 (diff) | |
download | glibc-f67f9c9af228f6b84579cb8c86312d3a7a206a55.tar.gz glibc-f67f9c9af228f6b84579cb8c86312d3a7a206a55.tar.xz glibc-f67f9c9af228f6b84579cb8c86312d3a7a206a55.zip |
ieee754: Remove slow paths from asin and acos
asin and acos have slow paths for rounding the last bit that cause some calls to be 500-1500x slower than average calls. These slow paths are rare, a test of a trillion (1.000.000.000.000) random inputs between -1 and 1 showed 32870 slow calls for acos and 4473 for asin, with most occurrences between -1.0 .. -0.9 and 0.9 .. 1.0. The slow paths claim correct rounding and use __sin32() and __cos32() (which compare two result candidates and return the closest one) as the final step, with the second result candidate (res1) having a small offset applied from res. This suggests that res and res1 are intended to be 1 ULP apart (which makes sense for rounding), barring bugs, allowing us to pick either one and still remain within 1 ULP of the exact result. Remove the slow paths as the accuracy is better than 1 ULP even without them, which is enough for glibc. Also remove code comments claiming correctly rounded results. After slow path removal, checking the accuracy of 14.400.000.000 random asin() and acos() inputs showed only three incorrectly rounded (error > 0.5 ULP) results: - asin(-0x1.ee2b43286db75p-1) (0.500002 ULP, same as before) - asin(-0x1.f692ba202abcp-4) (0.500003 ULP, same as before) - asin(-0x1.9915e876fc062p-1) (0.50000000001 ULP, previously exact) The first two had the same error even before this commit, and they did not use the slow path at all. Checking 4934 known randomly found previously-slow-path asin inputs shows 25 calls with incorrectly rounded results, with a maximum error of 0.500000002 ULP (for 0x1.fcd5742999ab8p-1). The previous slow-path code rounded all these inputs correctly (error < 0.5 ULP). The observed average speed increase was 130x. Checking 36240 known randomly found previously-slow-path acos inputs shows 42 calls with incorrectly rounded results, with a maximum error of 0.500000008 ULP (for 0x1.f63845056f35ep-1). The previous "exact" slow-path code showed 34 calls with incorrectly rounded results, with the same maximum error of 0.500000008 ULP (for 0x1.f63845056f35ep-1). The observed average speed increase was 130x. The functions could likely be trimmed more while keeping acceptable accuracy, but this at least gets rid of the egregiously slow cases. Tested on x86_64.
Diffstat (limited to 'sysdeps/x86_64/fpu/s_lrint.S')
0 files changed, 0 insertions, 0 deletions