[intrinsics] performance improvements for the intrinsified version of Objects::hash
Brian Goetz
brian.goetz at oracle.com
Wed Feb 27 21:22:04 UTC 2019
We are delegating hashing to a method:
int hash(int[] numbers)
which means that while we may be eliminating primitive boxing, we are
still paying for array boxing. Using either MH loop combinators or
hand-unrolled variants of the above should unlock more speedup on the
small (and most common) cases.
On 2/27/2019 3:24 PM, Alex Buckley wrote:
> On 2/26/2019 5:49 PM, Vicente Romero wrote:
>> In the last performance measurement we found a noticeable
>> degradation in performance for large number of arguments (~100), even
>> for primitive types. Patch [1] improves the performance for both
>> primitive and reference types with the difference that now the
>> performance is much better than vanilla JDK13 for primitive types but it
>> is still worst than vanilla for reference types. Although we are in
>> better shape now compared to the state as of 02/22. Keep tuned :)
>
> Previous intrinsification effort, relative to vanilla JDK 13:
>
> Intrinsified Vanilla Speedup
> testHash1IntVariable 42564 42799 1x
> testHash2IntVariables 41573 9019 5x
> testHash100IntVariables 4 27 0.15x
>
> New intrinsification effort, relative to vanilla JDK 13:
>
> Intrinsified Vanilla Speedup
> testHash1IntVariable 41149 42799 1x
> testHash2IntVariables 19075 9019 2x
> testHash100IntVariables 697 27 26x
>
> I note that the speedup of the 2IntVariables case is cut from 5x to
> 2x. That seems like quite a penalty for speeding up the
> 100IntVariables case (admittedly by a lot). But maybe what's happening
> is that the speedup improves as more variables are hashed. I wonder if
> it's fair to say for Objects::hash that vanilla invocation has a high
> fixed cost (box box box) and low variable costs (but who cares,
> because they're overwhelmed by the fixed cost) ... while intrinsified
> invocation has a low fixed cost (just run the BSM) but higher variable
> costs -- you pay for the hashing you get.
>
> Alex
More information about the amber-dev
mailing list