Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Fri, 1 Sep 2023 12:01:58 GMT, 温绍锦 wrote: >> @cl4es can you help me to review this PR? > >> @wenshao How about of approach used in [James Anhalt's >> algorithm](https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/)? >> >> It reduces number of multiplications ([and store operations in case of >> writing by 4-8 byte >> words](https://github.com/plokhotnyuk/jsoniter-scala/blob/b1020bafa7e2e5b7e8dd87b86a9e860975f4695e/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2004-L2023)) >> but increases the total number of instructions for the routine. > > If the compiled code size is greater than 325 (FreqInlineSize), it will not > be inlined and performance will slow down. This algorithm obviously greater > than 325. > > different algorithms perform differently on different types of tiny/small/big > values. > > The [first > commit](https://github.com/openjdk/jdk/pull/14699/files/8bdda26b8bb7f6162592a07445ecd2285e4fabaa) > of this PR performs better under big values. But I still use the current > algorithm, with few changes, and performance can be improved in all scenarios. > @wenshao Please do not rebase or force-push to an active PR as it invalidates > existing review comments. Note for future reference, the bots always squash > all changes into a single commit automatically as part of the integration. > See [OpenJDK Developers’ > Guide](https://openjdk.org/guide/#working-with-pull-requests) for more > information. to solve the problem of build failure, i did git rebase & push force. - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1704556037
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Thu, 31 Aug 2023 02:36:09 GMT, 温绍锦 wrote: >> 温绍锦 has updated the pull request incrementally with one additional commit >> since the last revision: >> >> assert bounds check > > @cl4es can you help me to review this PR? > @wenshao How about of approach used in [James Anhalt's > algorithm](https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/)? > > It reduces number of multiplications ([and store operations in case of > writing by 4-8 byte > words](https://github.com/plokhotnyuk/jsoniter-scala/blob/b1020bafa7e2e5b7e8dd87b86a9e860975f4695e/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2004-L2023)) > but increases the total number of instructions for the routine. If the compiled code size is greater than 325 (FreqInlineSize), it will not be inlined and performance will slow down. This algorithm obviously greater than 325. different algorithms perform differently on different types of tiny/small/big values. The [first commit](https://github.com/openjdk/jdk/pull/14699/files/8bdda26b8bb7f6162592a07445ecd2285e4fabaa) of this PR performs better under big values. But I still use the current algorithm, with few changes, and performance can be improved in all scenarios. - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1702637851
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Thu, 31 Aug 2023 19:53:17 GMT, Claes Redestad wrote: >> 温绍锦 has updated the pull request incrementally with one additional commit >> since the last revision: >> >> assert bounds check > > src/java.base/share/classes/java/lang/StringUTF16.java line 1585: > >> 1583: buf, >> 1584: Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), >> 1585: PACKED_DIGITS_UTF16[r]); > > What performance would you get if you used the same lookup table as the other > implementations, but inflate the value to UTF-16 on the fly? > > > int packed = (int)Integer.PACKED_DIGITS[r]; > int inflated = ((packed & 0xFF00) << 8) | (packed & 0xFF)); > UNSAFE.putIntUnaligned( > buf, > Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), > inflated); > > > This would avoid juggling more lookup table data around than before, > alleviating some of the concerns voiced in this PR comment thread. Good suggestion, using the same lookup table, we can get similar performance. int packed = (int) Integer.PACKED_DIGITS[-i]; int inflated = ((packed & 0xFF00) << 8) | (packed & 0xFF); charPos -= 2; assert charPos >= 0 && charPos < buf.length : "Trusted caller missed bounds check"; UNSAFE.putIntUnaligned( buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), inflated, false); The performance comparison data is as follows: -Benchmark Mode Cnt Score Error Units -StringBuilders.toStringCharWithInt8UTF16 avgt 15 26.812 ± 0.095 ns/op +Benchmark Mode Cnt Score Error Units (use same lookup table) +StringBuilders.toStringCharWithInt8UTF16 avgt 15 27.807 ± 0.046 ns/op - PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1312910616
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 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 ScoreError Units >> (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 1589.327 ± 0.733 ns/op >> >> +BenchmarkMode 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 incrementally with one additional commit > since the last revision: > > assert bounds check While I share the wariness against lookup tables (and the microbenchmarks that lend them too much credence), I think the approach in this PR is mostly an incremental improvement on an existing design and should be evaluated as such. By packing two lookup tables into one we reduce the opportunity for cache misses. The new lookup table is no larger as the two existing ones, so we're not wasting memory or sacrificing density. Having it in a single table makes it less likely that the arrays will end up in different locations on the heap or in compiled code. I see mostly positives here. The main drawback is the proliferation of `Unsafe` usage. Switching out the lookup table-based algorithm for something clever without a lookup table is laudable, but comes with a new set of challenges and should be done as a follow up. Since these tables can be aggressively constant-folded into the code section by our JITs it might even turn out to be a wash. If @RogerRiggs is happy with asserts in lieu of explicit bounds checking then I move to approve this. src/java.base/share/classes/java/lang/StringUTF16.java line 1585: > 1583: buf, > 1584: Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), > 1585: PACKED_DIGITS_UTF16[r]); What performance would you get if you used the same lookup table as the other implementations, but inflate the value to UTF-16 on the fly? int packed = (int)Integer.PACKED_DIGITS[r]; int inflated = ((packed & 0xFF00) << 8) & (packed & 0xFF)); UNSAFE.putIntUnaligned( buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), inflated); This would avoid juggling more lookup table data around than before, alleviating some of the concerns voiced in this PR comment thread. - PR Review: https://git.openjdk.org/jdk/pull/14699#pullrequestreview-1605608821 PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1312156127
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Thu, 31 Aug 2023 02:36:09 GMT, 温绍锦 wrote: >> 温绍锦 has updated the pull request incrementally with one additional commit >> since the last revision: >> >> assert bounds check > > @cl4es can you help me to review this PR? @wenshao How about of approach used in James Anhalt's algorithm: https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/ It reduces number of multiplications (and store operation in case of writing by 4-8 byte words) but increases the total number of instructions for the routine. - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701346461
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Thu, 31 Aug 2023 14:32:43 GMT, Andrew Haley wrote: > > I'm wondering if a micro benchmark like this is very realistic. > > Exactly so! This is almost the canonical example of the "JMH considered > harmful" talk I gave recently. The subject is a joke! Yes, I love JMH, but be very careful how you use it. - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701185887
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Thu, 31 Aug 2023 14:15:41 GMT, John Hendrikx wrote: > I'm wondering if a micro benchmark like this is very realistic. Exactly so! This is almost the canonical example of the "JMH considered harmful" talk I gave recently. - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701167979
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 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 ScoreError Units >> (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 1589.327 ± 0.733 ns/op >> >> +BenchmarkMode 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 incrementally with one additional commit > since the last revision: > > assert bounds check I'm wondering if a micro benchmark like this is very realistic. They may score positive as eventually these helper tables are in the inner most cache level, but it may be a net negative for larger functions that only do integer conversion occasionally, and almost always have a cache miss when doing a conversion. The tables may also be displacing other more useful cache lines. In my opinion, cache is a limited resource, and having a low level function use a big chunk of it may be optimal for a micro benchmark, but seems unlikely to be optimal overall. If you are only doing mass string to integer conversion, I'm sure it will do better. If you are writing out JSON that sometimes contains integers, the integer conversions may now sometimes have cache misses (in which case a non-cached based conversion would perform better), or the conversion is displacing other more useful cache lines. - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701138931
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 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 ScoreError Units >> (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 1589.327 ± 0.733 ns/op >> >> +BenchmarkMode 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 incrementally with one additional commit > since the last revision: > > assert bounds check @cl4es can you help me to review this PR? - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1700286359
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 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 ScoreError Units >> (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 1589.327 ± 0.733 ns/op >> >> +BenchmarkMode 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 incrementally with one additional commit > since the last revision: > > assert bounds check @AlanBateman can you help me to review this PR? - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1694137748
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Wed, 26 Jul 2023 20:31:16 GMT, Quan Anh Mai wrote: > It could be worth it to have a cache for small integers to skip the > calculations altogether. this PR is only for calculation optimization. caching small values should be a separate PR - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1653445373
Re: RFR: 8310929: Optimization for Integer.toString [v13]
On Tue, 18 Jul 2023 01:49:17 GMT, 温绍锦 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 ScoreError Units >> (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 1589.327 ± 0.733 ns/op >> >> +BenchmarkMode 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 incrementally with one additional commit > since the last revision: > > assert bounds check It could be worth it to have a cache for small integers to skip the calculations altogether. - PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1652451460
Re: RFR: 8310929: Optimization for Integer.toString [v13]
> 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 ScoreError Units > (baseline) > -StringBuilders.toStringCharWithInt8 avgt 1589.327 ± 0.733 ns/op > > +BenchmarkMode 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 (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ± 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... 温绍锦 has updated the pull request incrementally with one additional commit since the last revision: assert bounds check - Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/36f361f6..a69f6d2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14699=12 - incr: https://webrevs.openjdk.org/?repo=jdk=14699=11-12 Stats: 10 lines in 3 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699
