On Sat, 1 Jul 2023 14:42:07 GMT, 温绍锦 <d...@openjdk.org> wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved >> discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. >> [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ± 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ± 0.739 ops/us (+33.82%) >> >> >> ## 2. >> [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ± 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ± 0.271 ops/us (+0.63%) >> >> >> >> ## 3. >> [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ± 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ± 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ± 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ± 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ± 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ± 0.190 ops/us (-4.42%) > > 温绍锦 has updated the pull request incrementally with one additional commit > since the last revision: > > code style
src/java.base/share/classes/java/util/HexDigits.java line 44: > 42: * 0 -> '00' -> ('0' << 8) | '0' -> 0x3030 > 43: * 1 -> '01' -> ('0' << 8) | '1' -> 0x3130 > 44: * 2 -> '02' -> ('0' << 8) | '2' -> 0x3230 The description of the array content does not need to be exhaustive; just sufficient to understand how it is indexed and the meaning of the values. src/java.base/share/classes/java/util/HexDigits.java line 108: > 106: * Return a big-endian packed integer for the 4 ASCII bytes for an > input unsigned 2-byte integer. > 107: * {@code b0} is the most significant byte and {@code b1} is the > least significant byte. > 108: * The integer is passed byte-wise to allow reordering of execution. The more natural API would be to pass the 16-bit value as an int (or short). Simplifying the callers. Is there a significant performance difference? The extraction of the 8-bit values could be done here instead of the caller and still allow hardware specific instruction optimization. Also below, pass the 32-bit value as an int. src/java.base/share/classes/java/util/HexDigits.java line 116: > 114: /** > 115: * Return a big-endian packed long for the 8 ASCII bytes for an > input unsigned 4-byte integer. > 116: * {@code b0} is the most significant byte and {@code b4} is the > least significant byte. Typo "b4" -> "b3". src/java.base/share/classes/java/util/UUID.java line 475: > 473: long msb = mostSigBits; > 474: byte[] buf = new byte[36]; > 475: UNSAFE.putLongUnaligned( I understood that since UUID was not used during startup, that using VarHandles is the preferred abstraction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255985815 PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255966155 PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255962869 PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1255980037