RFR: 8342540: InterfaceCalls micro-benchmark gives misleading results [v2]

[Andrew Haley]

On Mon, 21 Oct 2024 09:43:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I have no idea how often well-predicted megamorphic calls occur. I can speculate that the "typical" megamorphic case lies somewhere between these extremes, but that is all. It may well be that normal behaviour is chaotic, but I strongly suspect that the cases are unlikely to be equally probable, as they are here. So, it is possible that an utterly unpredictable access pattern is just as unrealistic as a perfectly predictable one.
> 
> Yeah, all right. We can have a test that brackets the real-world performance between "best" and "worst" cases.
> 
> If you want to make "best" and "worst" only differ in the actual payload, maybe we should compute both scrambled and non-scrambled indexes, feed both to `Blackhole`, and only then select the index based on `randomized`. This way we would always compute both indexes.

Sure, I can try that, but I doubt it'll affect much. The great virtue of the xorshift generator is to be so lightweight, just a few clocks, that it barely affects anything.

> Also stats question: Do you know if scrambling actually produces the full period in requested `range`, and whether the frequency for individual cases is roughly the same? We kinda assume this xor-step is well distributed and has good enthropy in lower bits, but is it in practice?

I don't think we assume it: the analysis is in Marsaglia's _Xorshift RNGs_ paper. The full period (except 0) is proven there. 

The generator I've used here is a compromise: it has to be just good enough to throw off a branch predictor, while still being of very low overhead. There are several elaborations of Xorshift with better statistical properties (see "xoroshiro*") but they are less successful at just getting out of the way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21581#issuecomment-2426382114