On Fri, 1 Sep 2023 18:40:55 GMT, 温绍锦 <[email protected]> wrote:
>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>>
>> # Benchmark Result
>>
>>
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*"
>> make test TEST="micro:java.lang.Longs.toString*"
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8"
>>
>>
>> ## 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)
>> -Integers.toStringBig 500 avgt 15 6.825 ± 0.023 us/op
>> -Integers.toStringSmall 500 avgt 15 4.823 ± 0.023 us/op
>> -Integers.toStringTiny 500 avgt 15 3.878 ± 0.101 us/op
>>
>> +Benchmark (size) Mode Cnt Score Error Units (PR Update
>> 04 f4aa1989)
>> +Integers.toStringBig 500 avgt 15 6.002 ± 0.054 us/op (+13.71%)
>> +Integers.toStringSmall 500 avgt 15 4.025 ± 0.020 us/op (+19.82%)
>> +Integers.toStringTiny 500 avgt 15 3.874 ± 0.067 us/op (+0.10%)
>>
>> -Benchmark (size) Mode Cnt Score Error Units (baseline)
>> -Longs.toStringBig 500 avgt 15 9.224 ± 0.021 us/op
>> -Longs.toStringSmall 500 avgt 15 4.621 ± 0.087 us/op
>>
>> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04
>> f4aa1989)
>> +Longs.toStringBig 500 avgt 15 7.483 ± 0.018 us/op (+23.26%)
>> +Longs.toStringSmall 500 avgt 15 4.020 ± 0.016 us/op (+14.95%)
>>
>> -Benchmark Mode Cnt Score Error Units
>> (baseline)
>> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ± 0.733 ns/op
>>
>> +Benchmark Mode Cnt Score Error Units (PR
>> Update 04 f4aa1989)
>> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ± 0.422 ns/op
>> (+143.80%)
>>
>>
>>
>> ## 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)
>> -Integers.toStringBig 500 avgt 15 6.753 ± 0.007 us/op
>> -Integers.toStringSmall 500 avgt 15 4.470 ± 0.005 us/op
>> -Integers.toStringTiny 500 avgt 15 2.764 ± 0.020 us/op
>>
>> +Benchmark (size) Mode Cnt Score Error Units (PR Update
>> 04 f4aa1989)
>> +Integers.toStringBig 500 avgt 15 5.036 ± 0.005 us/op (+...
>
> 温绍锦 has updated the pull request with a new target base due to a merge or a
> rebase. The pull request now contains 16 commits:
>
> - remove unused import
> - UTF16 & Latin1 use same lookup table
> - assert bounds check
> - Integer/Long toString test against compact strings
>
> Co-authored-by: liach <[email protected]>
> - Adapt endian in pack
>
> Co-authored-by: liach <[email protected]>
> - use upper case for static final field
> - private static final Unsafe
> - code format
> - simplify code
> - format code & comment
> - ... and 6 more: https://git.openjdk.org/jdk/compare/2f7c65ec...0d149fa9
A comment on bounds checks. Before `StringUTF16::getChars(int, int, byte[])`
it's explicitly spelled out that the important bounds checks must have been
done already:
// Used by trusted callers. Assumes all necessary bounds checks have
// been done by the caller.
This is not spelled out for `Integer/Long.getChars(int/long, int, byte[])` but
might as well have been since all the usage thereof are from trusted sources
that calculate the indexes to fit the string inside the byte buffer.
Perhaps `Integer/Long.getChars` and `PACKED_DIGITS` should all be moved to
`java.lang.StringLatin1` and be annotated with the same comment as the
equivalent methods in `java.lang.StringUTF16`?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1705358539
