On Wed, 9 Aug 2023 22:54:28 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
>> Please review this PR to use modern APIs and language features to simplify >> equals, hashCode, and compareTo for BigInteger. If you have any performance >> concerns, please raise them. >> >> This PR is cherry-picked from a bigger, not-yet-published PR, to test the >> waters. That latter PR will be published soon. > > Pavel Rappo has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 13 additional > commits since the last revision: > > - Fix bugs in Shared.createSingle > - Merge branch 'master' into 8310813 > - Group params coarser (suggested by @cl4es) > > - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge. > Every testXYZ method invokes M operations, where M is the maximum > number of elements in a group. Shorter groups are cyclically padded. > - Uses the org.openjdk.jmh.infra.Blackhole API and increases > benchmark time. > - Fixes a bug in Shared that precluded 0 from being in a pair. > - Use better overloads (suggested by @cl4es) > > - Uses simpler, more suitable overloads for the subrange > starting from 0 > - Improve benchmarks > - Merge branch 'master' into 8310813 > - Restore hash code values > > BigInteger is old and ubiquitous enough so that there might be > inadvertent dependencies on its hash code. > > This commit also includes a test, to make sure hash code is > unchanged. > - Merge branch 'master' into 8310813 > - Add a benchmark > - Merge branch 'master' into 8310813 > - ... and 3 more: https://git.openjdk.org/jdk/compare/983eb997...6fa3f694 > Here's a status update for this PR. I'm currently benchmarking baseline > against this PR and this PR plus changes in #15197. It's a 3-way benchmark, > so to speak. Its purpose is to see whether performance degradation brought by > this PR to `equals` and `compareTo` can be sufficiently offset by the > improved `ArraysSupport.mismatch` mechanics. Sadly #15197 doesn't pan out as well as I'd hoped: the win on some array sizes is cancelled out by losses on others. I'll be shifting the focus of that PR over to simplifying in ways that will be performance neutral and enhancing the targeted `ArraysMismatch` microbenchmarks so that they work on tiny array sizes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1674563442
