Array copy and array compare seem like very similar optimization problems and could even share some infrastructure.
On Thu, Apr 11, 2019 at 9:23 AM John Rose <[email protected]> wrote: > On Dec 7, 2018, at 4:11 PM, Claes Redestad <[email protected]> > wrote: > > > > - Jim's proposal to use Arrays.equals is _interesting_: it improves > > peak performance on some inputs but regress it on others. I'll defer > > that to a future RFE as it needs a more thorough examination. > > > > - what we can do is simplify to only use StringLatin1.equals. If I'm not > > completely mistaken these are all semantically neutral (and > > StringUTF16.equals effectively redundant). If I'm completely wrong here > > I'll welcome the learning opportunity. :-) > > If they are semantically neutral then they belong in > the same place as the neutral intrinsics, which is > jdk.internal.util.ArraysSupport. This in turn calls > the question of how the operation differs from > the existing mismatch intrinsic. > > I'll go out on a limb here and say that the standard > ArraysSupport.mismatch intrinsic can probably be > tuned to cover string compares without hurting its > other customers. Often such intrinsics are only > engineered for throughput on long inputs. > Later on we may find they can be additionally > tuned for other workloads, by adjusting the setup > logic, or (alternatively) they can be factored into > multiple entry points for specific use cases, with > complete sharing of assembly-level code except > for differing setup logic for the different use cases. > This sort of thing is the case with our arraycopy > intrinsics (used by the JIT) and may well also be > the case for array matching intrinsics. > > I agree the above questions can be answered in > a separate investigation. > > — John
