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

[B. Blaser]

Here it is:

http://cr.openjdk.java.net/~bsrbnd/jdk8217561/webrev.05/

I've just added the interesting use-case of inserting elements in a search tree.
The insertion is absolutely unpredictable with random elements whereas
fully predictable with sorted elements.

Benchmarking this example is hard as it'd compute the average
insertion time in a search tree which highly depends on its
topography.
That's why I decided to add it to the test-case doing some manual
measurement using 'System.nanoTime()'.

This experiment revealed at no surprise that the intrinsic is really
worth being used only in the non-predictable case which the heuristic
is for.

Any Reviewer feedback and hopefully approval would be welcome
(hotspot:tier1 is still OK on x86_64 xeon)!

Thanks,
Bernard

On Wed, 20 Feb 2019 at 20:16, B. Blaser <bsrbnd at gmail.com> wrote:
>
> Thanks for your feedback, Andrew and Vladimir.
> I'll update the webrev accordingly adding the heuristic and the benchmarks.
>
> Bernard
>
> On Wed, 20 Feb 2019 at 18:53, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
> >
> > On 2/20/19 9:39 AM, Andrew Haley wrote:
> > > On 2/19/19 3:16 PM, B. Blaser wrote:
> > >
> > >> So, I did some experiments and it seems that the most important
> > >> branch is the last one.
> > >> If data is well balanced like in the initial benchmark I posted,
> > >> branch prediction is poor and the intrinsic is 2x faster, in all
> > >> other cases it'd be better to avoid it:
> > >
> > > I tried this an it seems to work.
> > >
> > > This idea looks extremely promising. It's not perfect in that there
> > > are still datasets that confuse it, but it's surely an improvement
> > > over what we have today.
> > >
> > > Vladimir, what say you? This is a useful heuristic which avoids
> > > performance regressions caused by min/max in almost all cases. I say
> > > we want it.
> >
> > Yes, this would be nice.
> >
> > >
> > > NB: this heuristic is probably good for CMOV instructions too.
> >
> > Agree, we had a lot of comments back when we implemented CMOV. There was big discussion what is better - short jump or
> > cmove. It all depends on bench prediction as in this case.
> >
> > Regards,
> > Vladimir