On Mon, 4 Dec 2023 16:17:15 GMT, Claes Redestad <[email protected]> wrote:
> Does this suggest an optimization opportunity to ArraysSupport::mismatch, or > is the relative overhead due the inherent costs of finding the exact index in > the mismatch? I suppose that's the latter; but I need to study the produced ASM for both, in case of small sized strings. As said in https://github.com/openjdk/jdk/pull/16933#issuecomment-1838744137, the cost just fade away when cache accesses become the dominant cost > This only optimize the case where we're comparing the entirety of both > Strings. How common is this in practice? I have the sole data point of HTTP endpoint routing which *can* have, in the hot path and common cases, exact matching too, see https://github.com/franz1981/vertx-web/blob/c6740a5991a15567521c26ac3a08091e8603f2f2/vertx-web/src/main/java/io/vertx/ext/web/impl/RouteState.java#L1251-L1262 > It would be good to check a mixed benchmark where some inputs will use this > fast path and others won't to assert that this doesn't have an unexpected > negative impact from adding a few tests. You mean by having the different uses cases stressed in sequence with some probability (in order to induce some cache misses)? To be fair we should change the length too, and let the "batching" factor (ie the stride) of each different vectorized version to induce other branch-misses, instead of a "all or nothing" one, but sadly it means no longer having steady-state which will make more difficult to evaluate improvements. I'm +1 to this micro use case, but I would like to better understand how to write it right ------------- PR Comment: https://git.openjdk.org/jdk/pull/16933#issuecomment-1839084606
