On Thu, 13 Jul 2023 08:44:02 GMT, Pavel Rappo <[email protected]> wrote:
>>> For an arbitrary int[], unconditional vectorization might be unwarranted or
>>> puzzling.
>>
>> Could you clarify this statement? Thanks a lot.
>
>> > For an arbitrary int[], unconditional vectorization might be unwarranted
>> > or puzzling.
>>
>> Could you clarify this statement? Thanks a lot.
>
> My mental model is that Arrays.hashCode is to
> ArraysSupport.vectorizedHashCode as Arrays.mismatch to
> ArraysSupport.vectorizedMismatch. In either pair, the first method is
> applicable to some generic array, whereas the second method is applicable to
> an array that would definitely benefit from vectorized processing.
>
> When I see a call to ArraysSupport.vectorizedHashCode, it reads like a
> statement: this particular computation must be vectorized. Now, was it
> author's intention, or there simply were no alternatives to compute hash code
> of an array subrange or with a different initial value?
> @pavelrappo Actually I look at the implementation of
> `ArraySupport.vectorizedHashCode` and it does branching and only uses vector
> instructions if the length is sufficiently large. Please do benchmarking if
> you are uncertain with performance characteristics of functions. Thanks.
Are you sure you are talking about `vectorizedHashCode` and not
`vectorizedMismatch`? While the latter indeed branches on array length, the
former consists of simple for-loops, which might not be the actual thing anyway
because the whole method is `@IntrinsicCandidate`.
Regardless of any performance characteristics, the call to something named
`vectorizedHashCode` might needlessly draw attention to something that does not
deserve it.
My mental model might be wrong, but let me give you a stream analogy. Would you
not pause and think if you unexpectedly saw this?
...
.stream()
...
.parallel()
...
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1633888417
