On Thu, 13 Jul 2023 08:44:02 GMT, Pavel Rappo <pra...@openjdk.org> 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