[PATCH] 8217561 : X86: Add floating-point Math.min/max intrinsics, approval request

Andrew Haley aph at redhat.com
Mon Feb 18 09:27:39 UTC 2019

On 2/17/19 8:21 PM, B. Blaser wrote:
> The unpredictability is necessary to measure the instruction sequence
> only which is more than 2x faster than before.
> However, I agree that your predictable example is a bit less than 3x
> slower with the intrinsic, but we have the same regression with the
> existing integer min/max intrinsic:
> @Benchmark
> public float iMinReduce(Blackhole bh) {
>     int result = Integer.MAX_VALUE;
>     for (int i=0; i<COUNT; i++)
>        result = Math.min(result, ints[i]);
>     return result;
> }
> @Benchmark
> public float fMinReduce(Blackhole bh) {
>     float result = Float.MAX_VALUE;
>     for (int i=0; i<COUNT; i++)
>        result = Math.min(result, floats[i]);
>     return result;
> }

Yes, we do. So, I suspect that the predictable case is very common. Is
this intrinsic good or bad? Does it make Java better or worse?

> Note that Jatin's example is also biased but up to 10x faster than before!
> Nevertheless, the interest of intrinsics goes far beyond these
> examples as they also open the door of other optimizations like the
> algebraic simplifications you mentioned previously, see [1] & [2].

Sure, but how common is that really? Are we making Java worse by adding
these intrinsics? If so, why are we doing it?

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-compiler-dev mailing list