You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Erik Svensson <er...@phlogiston.se> on 2021/01/27 08:05:38 UTC
[math] FastMath isn't fast...
Hello all!
I work for a fintech company and we do a lot of risk computations using, among other things, FastMath.
Recently I had the opportunity to do some performance testing using JMH and found, to my surprise, that once
you move beyond Java 8, java.lang.Math outperforms FastMath, sometimes quite considerably. Graal11 especially is very performant.
I’ve traced the cause to the introduction of @HotSpotIntrinsicCandidate in java 9 that replaces the Java 8 JNI call.
I could just use the Math package where we explicitly call the FastMath package but we use other commons.math stuff that depends on FastMath which means that
they miss out on the possible performance gains.
I’m wondering if there is any effort to handle this in FastMath as the gains are quite considerable.
One solution would be to check for the annotation in the Math package, and if it’s available, use the Math package instead.
Cheers
Erik Svensson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] FastMath isn't fast...
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le mer. 27 janv. 2021 à 17:39, Erik Svensson <er...@phlogiston.se> a écrit :
>
> Hello all!
>
> I work for a fintech company and we do a lot of risk computations using, among other things, FastMath.
> Recently I had the opportunity to do some performance testing using JMH and found, to my surprise, that once
> you move beyond Java 8, java.lang.Math outperforms FastMath, sometimes quite considerably. Graal11 especially is very performant.
Actually, this kind of issue has been noticed for a long time:
https://issues.apache.org/jira/browse/MATH-1113
https://issues.apache.org/jira/browse/MATH-901
https://issues.apache.org/jira/browse/MATH-740
At the time, it seemed that the most consistent advantage of "FastMath"
was accuracy:
https://issues.apache.org/jira/browse/MATH-1114
But this could also have evolved into "Math" having become more accurate.
>
> I’ve traced the cause to the introduction of @HotSpotIntrinsicCandidate in java 9 that replaces the Java 8 JNI call.
>
> I could just use the Math package where we explicitly call the FastMath
> package but we use other commons.math stuff that depends on FastMath
> which means that they miss out on the possible performance gains.
The project includes micro-benchmarks[1] but they have been obsoleted by
the advent of JMH; so you are quite welcome to contribute your JMH tests.
>
> I’m wondering if there is any effort to handle this in FastMath as the gains are quite considerable.
The next major version is supposed to require Java 8.
The first step would be to establish, for each function,
* whether the "FastMath" version is slower, and if so
* whether it is more accurate
than its "Math" equivalent.
> One solution would be to check for the annotation in the Math package, and if it’s available, use the Math package instead.
See Matt's reply.
Thanks,
Gilles
[1] https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/userguide/java/org/apache/commons/math4/userguide/FastMathTestPerformance.java;h=d140393d224b4ff6592224f48b59e8950963b49b;hb=HEAD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] FastMath isn't fast...
Posted by Matt Sicker <bo...@gmail.com>.
Are we even allowed to use the intrinsic annotation in user code? Java
9 introduces modules in that they wish to hide internal details, and
this sounds like an internal detail?
On Wed, 27 Jan 2021 at 10:39, Erik Svensson <er...@phlogiston.se> wrote:
>
> Hello all!
>
> I work for a fintech company and we do a lot of risk computations using, among other things, FastMath.
> Recently I had the opportunity to do some performance testing using JMH and found, to my surprise, that once
> you move beyond Java 8, java.lang.Math outperforms FastMath, sometimes quite considerably. Graal11 especially is very performant.
>
> I’ve traced the cause to the introduction of @HotSpotIntrinsicCandidate in java 9 that replaces the Java 8 JNI call.
>
> I could just use the Math package where we explicitly call the FastMath package but we use other commons.math stuff that depends on FastMath which means that
> they miss out on the possible performance gains.
>
> I’m wondering if there is any effort to handle this in FastMath as the gains are quite considerable.
>
> One solution would be to check for the annotation in the Math package, and if it’s available, use the Math package instead.
>
>
> Cheers
> Erik Svensson
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org