On Tue, 12 Sep 2023 22:44:35 GMT, 温绍锦 <d...@openjdk.org> wrote:
>> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 112: >> >>> 110: | (DIGITS[b1 & 0xff] << 16) >>> 111: | (((long) DIGITS[b2 & 0xff]) << 32) >>> 112: | (((long) DIGITS[b3 & 0xff]) << 48); >> >> Can you reverse the order of these source lines to put the shifts of the >> higher order bits before the lower order bit shifts. `3333222211110000`. >> Its easier to understand where the bits end up in the long. >> The rest of the change is better focused. > > if reverse packDigits order, performance will be slow, I don't know why yet. > > The following is the data running on MacBookPro M1 Max : > > make test TEST="micro:java.util.UUIDBench.toString" > > Benchmark (size) Mode Cnt Score Error Units (current order > 4f6ed3e6) > UUIDBench.toString 20000 thrpt 15 96.396 ? 0.946 ops/us > > > Benchmark (size) Mode Cnt Score Error Units (reverse > packDigits order) > UUIDBench.toString 20000 thrpt 15 86.496 ? 0.542 ops/us Looks like something that might be an interesting puzzler for JIT compiler folks. Perhaps added implicit casts to long messes something up? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1323773899
