Hi. Le mer. 27 janv. 2021 à 17:39, Erik Svensson <e...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
