On Tue, 18 Jun 2024 01:09:49 GMT, Shaojin Wen <d...@openjdk.org> wrote:
>> Shaojin Wen 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: >> >> - Merge remote-tracking branch 'upstream/master' into merge_store_bench >> - bug fix for `putChars4C` >> - bug fix for `putChars4C` and `putChars4S` >> - use VarHandler CHAR_L & CHAR_B >> - copyright >> - bug fix for putIntBU >> - add cases for `getChar` & `putChar` >> - code format >> - add `setIntRL` & `setIntRLU` >> - add comments >> - ... and 3 more: https://git.openjdk.org/jdk/compare/322c6e37...4c9b9418 > > I re-ran the performance test based on WebRevs 04: > [Full](https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=04) - > [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=03-04) > ([4c9b9418](https://git.openjdk.org/jdk/pull/19734/files/4c9b9418fc4a95504867b6019b3e94605917f747)) > . > > # 1. Cases MergeStore does not work > @eme64 > I found `putChars4BV` and `putChars4LV` two cases MergeStore didn't work, if > support can be enhanced, it would be useful for people using VarHandle. > > > putChars4BV > putChars4LV > > > I also found that the performance of the case using VarHandle is particularly > good. Why? For example: > > setIntBV > setIntLV > setLongBV > setLongLV > > > # 2. Performance numbers > The names of these cases have the following B/L/V/U suffixes, which are: > > B BigEndian > L LittleEndian > V VarHandle > U Unsafe > R reverseBytes > C Unsafe.getChar & putChar > S Unsafe.getShort & putShort > > > ## 2.1 MacBook M1 Pro (aarch64) > > Benchmark Mode Cnt Score Error Units > MergeStoreBench.getCharB avgt 15 5340.200 ? 7.038 ns/op > MergeStoreBench.getCharBU avgt 15 5482.163 ? 7.922 ns/op > MergeStoreBench.getCharBV avgt 15 5074.165 ? 6.759 ns/op > MergeStoreBench.getCharC avgt 15 5051.763 ? 6.552 ns/op > MergeStoreBench.getCharL avgt 15 5374.464 ? 9.783 ns/op > MergeStoreBench.getCharLU avgt 15 5487.532 ? 6.368 ns/op > MergeStoreBench.getCharLV avgt 15 5071.263 ? 9.717 ns/op > MergeStoreBench.getIntB avgt 15 6277.984 ? 6.284 ns/op > MergeStoreBench.getIntBU avgt 15 5232.984 ? 10.384 ns/op > MergeStoreBench.getIntBV avgt 15 1206.264 ? 1.193 ns/op > MergeStoreBench.getIntL avgt 15 6172.779 ? 1.962 ns/op > MergeStoreBench.getIntLU avgt 15 5157.317 ? 16.077 ns/op > MergeStoreBench.getIntLV avgt 15 2558.110 ? 3.402 ns/op > MergeStoreBench.getIntRB avgt 15 6889.916 ? 36.955 ns/op > MergeStoreBench.getIntRBU avgt 15 5769.950 ? 11.499 ns/op > MergeStoreBench.getIntRL avgt 15 6625.605 ? 10.662 ns/op > MergeStoreBench.getIntRLU avgt 15 5746.742 ? 11.945 ns/op > MergeStoreBench.getIntRU avgt 15 2544.586 ? 2.769 ns/op > MergeStoreBench.getIntU avgt 15 2541.119 ? 3.252 ns/op > MergeStoreBench.getLongB avgt 15 12098.129 ? 31.451 ns/op > MergeStoreBench.getLongBU avgt 15 9760.621 ? 16.427 ns/op > MergeStoreBench.getLongBV avgt 15 2593.635 ? 4.698 ns/op > MergeStoreBench.getLongL avgt 15 12031.065 ? 19.820 ns/op > Merge... @wenshao what is the state of this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2247964317