On Tue, 6 May 2025 21:45:34 GMT, Mohamed Issa <d...@openjdk.org> wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for >> java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are >> included to check the performance of specific input value ranges to help >> prevent regressions in the future. >> >> The results of all tests posted below were captured with an [Intel® Xeon >> 6761P](https://www.intel.com/content/www/us/en/products/sku/241842/intel-xeon-6761p-processor-336m-cache-2-50-ghz/specifications.html) >> using [OpenJDK >> v25-b21](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B21) as the >> baseline version. >> >> For performance data collected with the new built in range micro-benchmark, >> see the table below. Each result is the mean of 8 individual runs, and the >> input ranges used match those from the original Java implementation. >> Overall, the intrinsic provides a major uplift of 169% when very small >> inputs are used and a more modest uplift of 45% for all other inputs. >> >> | Input range(s) | Throughput with baseline >> (op/s) | Throughput with intrinsic (op/s) | Speedup | >> | :-------------------------------------: | >> :----------------------------------: | :----------------------------------: >> | :---------: | >> | [-2^(-1022), 2^(-1022)] | 6568 >> | 17678 | 2.69x >> | >> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932 >> | 200897 | 1.45x | >> >> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed >> with the changes. > > Mohamed Issa has updated the pull request incrementally with one additional > commit since the last revision: > > Add new set of cbrt micro-benchmarks src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 62: > 60: { > 61: 0, 3220193280 > 62: }; What is this constant? Its value is 0xbff0400000000000, which is -ve bit set, bias (top bit of exponent) clear, but one of the bits in the fraction is set. So its value is -0x1.04p+0. As well as the exponent it also sets the 1 bit, just below the 5 most significant bits of the fraction. I guess this in effect rounds up the value that is added in the final rounding. Is that right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24470#discussion_r2077214995
