On Sat, 1 Jul 2023 14:42:07 GMT, 温绍锦 <[email protected]> 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
