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

[B. Blaser]

On Mon, 18 Feb 2019 at 10:27, Andrew Haley <aph at redhat.com> wrote:
>
> 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?

Intrinsic instruction sequences are definitely fast and other
optimizations can benefit from their mathematical properties.
Of course, statistical optimizations could be even faster but making
assumptions about predictability to exclude intrinsics is rather
dangerous.
The JVM should be able to decide dynamically whether to use intrinsics
or not depending on the reliability of its statistics?!

Bernard