Hello,
After much more thorough analysis of benchmarks on different platforms I
tend to cancel this patch proposal.
As Brian rightly remarked [3], the benchmark has peculiar explicit
iteration over the data. This is more like 2nd anti-pattern in safe
looping JMH sample [4]. This actually came out of larger experiment in
Lucene geo-search. But canonical case like [5] is also important.
For micro-benchmarks with any kind of safe looping, there can be a
degradation up to 7x. It is caused by spilling/re-materialization of
registers that hold constants when they are alive around the call (good
case benefits when they are moved out of loops).
The possible other way to improve singnum should probably be platform
specific.
Joe and Brian, thanks again for taking a look.
[3]
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067671.html
[4]
https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_34_SafeLooping.java
[5] http://cr.openjdk.java.net/~dchuyko/8249198/DoubleSignum.java
On 7/10/20 11:56 PM, Brian Burkhalter wrote:
Hi Dmitry,
Regarding the benchmarks [1], I was curious as to why you chose to use
the reduce() method, which inside it loops over invocations of
signum(), given the considerations discussed in the sample
JMHSample_11_Loops.java [2]? Is that in order to force inlining? I
have not used the @CompilerControl annotation.
Thanks,
Brian
[1]
http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/test/micro/org/openjdk/bench/java/lang/DoubleSignum.java.html
http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/test/micro/org/openjdk/bench/java/lang/FloatSignum.java.html
[2]
https://hg.openjdk.java.net/code-tools/jmh/file/4a420afe8a9e/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_11_Loops.java
On Jul 10, 2020, at 1:28 PM, Joe Darcy <joe.da...@oracle.com
<mailto:joe.da...@oracle.com>> wrote:
I'll leave it to others to review the benchmarks.
