On Thu, 10 Jul 2025 21:23:50 GMT, Joe Darcy wrote:
> > > What is the accuracy of the algorithm in ulps (units the last place)?
> > > The java.lang.Math specification has max error and various other accuracy
> > > requirements any implementation must meet.
> >
> >
> > 0.51 ulps
>
> Please add
59x |
> | (-INF, -710.48], [710.48, INF) | 959296
> | 313839| 0.33x |
>
> Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed
> with the changes.
Mohamed Issa
On Thu, 10 Jul 2025 04:52:01 GMT, Joe Darcy wrote:
> What is the accuracy of the algorithm in ulps (units the last place)?
>
> The java.lang.Math specification has max error and various other accuracy
> requirements any implementation must meet.
0.51 ulps
-
PR Comment: https://gi
On Mon, 7 Jul 2025 04:48:18 GMT, Florian Weimer wrote:
> Isn't this effectively a libm benchmark (where the `sinh` implementation
> resides)? Please include the libm version for reference here. Thanks.
I'm not sure which libm version you're referring to. The only current sinh
benchmark I'm awa
On Mon, 7 Jul 2025 18:01:26 GMT, Joe Darcy wrote:
> Are there plans for a cosh intrinsic as follow-up work? There was a previous
> effort to intrinsify tanh.
Yes, the intention is to have cosh as next math intrinsic.
-
PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecommen
On Mon, 7 Jul 2025 18:03:54 GMT, Joe Darcy wrote:
> A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)]
> range where there is a performance degradation with the new implementation.
>
> What is the expected distribution of arguments to sinh?
I don't know about an expected
The goal of this PR is to implement an x86_64 intrinsic for
java.lang.Math.sinh() 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 command to run all range specific micro-benchm
On Mon, 2 Jun 2025 04:42:03 GMT, David Holmes wrote:
> > When you say "most of the non-x86 platforms", are you referring to the ones
> > with processor types listed below?
>
> Yes - 3 of the 5 non-x86 platforms.
>
> > It looks like aarch64 and riscv don't take that route and would fall back
>
On Mon, 2 Jun 2025 02:08:55 GMT, David Holmes wrote:
> This change also broke most of the non-x86 platforms, due to the new
> intrinsic not being implemented on those platforms.
When you say "most of the non-x86 platforms", are you referring to the ones
with processor types listed below?
1. j
On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa 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 re
On Fri, 30 May 2025 19:03:00 GMT, Sandhya Viswanathan
wrote:
>> Mohamed Issa has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add newline back to templateInterpreterGenerator_x86_64.cpp source file
>>
), 2^(-1022)] | 6568
> | 17678 | 2.69x |
> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932
> | 200897| 1.45x |
>
> Finally, the `jtreg
On Thu, 29 May 2025 08:36:31 GMT, Jatin Bhateja wrote:
>> Mohamed Issa has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - Remove comment mentioning invalid exception when NaN input is provided
>> - Use r
On Thu, 29 May 2025 08:21:29 GMT, Jatin Bhateja wrote:
>> Mohamed Issa has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - Remove comment mentioning invalid exception when NaN input is provided
>> - Use r
On Thu, 29 May 2025 09:01:05 GMT, Julian Waters wrote:
>> Mohamed Issa has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - Remove comment mentioning invalid exception when NaN input is provided
>> - Use r
), 2^(-1022)] | 6568
> | 17678 | 2.69x |
> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932
> | 200897| 1.45x |
>
> Finally, the `jtreg
On Tue, 27 May 2025 22:30:17 GMT, Sandhya Viswanathan
wrote:
>> 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/macroAssembler
), 2^(-1022)] | 6568
> | 17678 | 2.69x |
> | (-INF, -2^(-1022)], [2^(-1022), INF) | 138932
> | 200897| 1.45x |
>
> Finally, the `jtreg
On Wed, 7 May 2025 09:25:30 GMT, Andrew Haley wrote:
>> 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.
---: | :-: |
> | MathBench.cbrt | 152465| 208537
>| 1.37x |
>
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed
> with the changes.
Mohamed Issa has update
---: | :-: |
> | MathBench.cbrt | 148242| 209122
>| 1.41x |
>
> Finally, the `jtreg:test/jdk/java/lang/Math/CubeRootTests.java` test passed
> with the changes.
Mohamed Issa has up
On Sat, 26 Apr 2025 10:04:38 GMT, Andrew Haley wrote:
> What are the monotonicity and accuracy results for this approximation? Is it
> correctly rounded or faithfully rounded?
1. It's monotonic.
2. It has a maximum error of 0.5213 ULP.
3. It's not correctly rounded but it is faithfully rounded.
On Sat, 26 Apr 2025 11:01:58 GMT, Andrew Haley wrote:
> > the built in **cbrt** micro-benchmark
>
> How should we run that benchmark? Thanks.
`make test TEST="micro:MathBench.cbrt"`
-
PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2840442518
The goal of this PR is to implement an x86_64 intrinsic for
java.lang.Math.cbrt() using libm.
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.
24 matches
Mail list logo
