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

[Andrew Haley]

On 2/18/19 1:26 PM, B. Blaser wrote:
> 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.

Yes, they can be.

> Of course, statistical optimizations could be even faster but making
> assumptions about predictability to exclude intrinsics is rather
> dangerous.

I'm not convinced that it is at all dangerous. The pattern I
illustrated is uncommon, and might will be considerably more common
than the pattern than the benchmark presented by Jatin. But we should
not choose our benchmarks so that they make our code look
good. Instead, we should use benchmarks to help us decide what to do.

> The JVM should be able to decide dynamically whether to use intrinsics
> or not depending on the reliability of its statistics?!

Perhaps so, yes. So before we decide to commit changes that may well make the
JVM worse on many (most?) workloads, we should find a way to do that.

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