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

[Andrew Haley]

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