String.indexOf(single-char-String)

[Michael Bien]

Hello again,

I was trying to run JDK's benchmarks over night (second attempt 
actually) but had some difficulties to get stable results.

This makes it difficult to compare the modified version with a 
reference. I am not sure what the cause is, I have heard some intel CPUs 
can't run avx instructions for a long time without changing clock - 
maybe i am hitting this issue?
Its not the temperature and i turned boost and HT off + it runs in 
headless mode. One run already takes almost 5h and I have to run it 
twice - so i can't increase the iterations even more.


for example:

# Benchmark: 
org.openjdk.bench.java.lang.StringIndexOfChar.utf16_mixed_String
# Parameters: (loops = 100000, pathCnt = 1000, rngSeed = 1999)

# Run progress: 95.35% complete, ETA 00:13:20
# Fork: 1 of 1
# Warmup Iteration   1: 18592.094 ns/op    <- second fastest run?
# Warmup Iteration   2: 20519.413 ns/op
# Warmup Iteration   3: 19768.099 ns/op
# Warmup Iteration   4: 23093.410 ns/op
# Warmup Iteration   5: 29112.909 ns/op
# Warmup Iteration   6: 18962.671 ns/op
# Warmup Iteration   7: 16721.933 ns/op    <- fastest run?
# Warmup Iteration   8: 20267.809 ns/op
# Warmup Iteration   9: 23934.031 ns/op
# Warmup Iteration  10: 22474.836 ns/op
# Warmup Iteration  11: 19583.471 ns/op
# Warmup Iteration  12: 19595.319 ns/op
# Warmup Iteration  13: 24865.299 ns/op
# Warmup Iteration  14: 19581.014 ns/op
# Warmup Iteration  15: 19566.849 ns/op
# Warmup Iteration  16: 19576.219 ns/op
# Warmup Iteration  17: 19574.475 ns/op
# Warmup Iteration  18: 19565.854 ns/op
# Warmup Iteration  19: 26594.867 ns/op
# Warmup Iteration  20: 26532.977 ns/op
Iteration   1: 25484.070 ns/op
Iteration   2: 19594.206 ns/op
Iteration   3: 30327.037 ns/op
Iteration   4: 31029.242 ns/op  <- xxx
Iteration   5: 19560.472 ns/op
Iteration   6: 19611.728 ns/op
Iteration   7: 23214.511 ns/op
Iteration   8: 28455.757 ns/op
Iteration   9: 19787.638 ns/op
Iteration  10: 23737.501 ns/op
Iteration  11: 25947.249 ns/op
Iteration  12: 19768.214 ns/op
Iteration  13: 25789.970 ns/op
Iteration  14: 20558.622 ns/op
Iteration  15: 19611.317 ns/op
Iteration  16: 27761.431 ns/op
Iteration  17: 19749.799 ns/op
Iteration  18: 20862.478 ns/op
Iteration  19: 19581.498 ns/op
Iteration  20: 28094.839 ns/op


latin1_Short_String, latin1_Short_char, latin1_mixed_String, 
latin1_mixed_char, utf16_mixed_String and utf16_mixed_char have all 
large error bars (all in StringIndexOfChar).


best regards,

michael



On 23.11.21 17:06, Michael Bien wrote:
> On 23.11.21 15:57, Roger Riggs wrote:
>> Hi Michael,
>>
>> As you might expect performance of strings is very sensitive and has 
>> been tuned extensively over the years many times.
>>
>> Though this improves the performance for 1 character strings. It will 
>> have an impact on *every other* length of string.
>> You'll need to show that it does not impact performance of longer 
>> strings.
>
> yes of course. The if (str.length == 1) branch should be dead code and 
> eliminated by the JVM for all String constants with non-one lengths.
>
> Looking through the benchmarks in micro/*/java/lang/String*, all seem 
> to be using constants as parameter for indexOf(). To try to measure 
> the impact of the if branch i would have to write a benchmark with a 
> parameter which changes every iteration, right? Otherwise the branch 
> will be optimized away by the JIT.
>
>>
>> It may be worth looking further at other ways to achieve the result.
>
> agreed, I tried the most obvious approach first, but there is a chance 
> that the fast path can be put into the intrinsified 
> StringLatin1/StringUTF16 code instead.
>
> -michael
>
>
>>
>> Regards, Roger
>>
>>
>> On 11/22/21 3:52 PM, Michael Bien wrote:
>>> Hello,
>>>
>>> I kept forgetting which variants of the String methods perform 
>>> better with single-char-Strings and which with char (IDEs had the 
>>> tendency to suggest the wrong variant since it changed between JDK 
>>> releases). So i wrote JMH benchmarks and noticed that the last 
>>> method with a performance difference seems to be String.indexOf() - 
>>> all other variants performed equally (unless I overlooked some).
>>>
>>> this might be fairly easy to fix:
>>>
>>> https://github.com/openjdk/jdk/pull/6509
>>>
>>> (side effect: contains("c") is also faster)
>>>
>>> I haven't looked into the intrinsified code of StringLatin1 and 
>>> StringUTF16 to check if it could be fixed there (mostly because i 
>>> actually don't know how the JVM assembles those intrinsics). It 
>>> might be possible to improve this for short Strings in general, not 
>>> just for chars, dependent on why the intrinsified version is 
>>> actually slower for single-char-Strings. I opted for the trivial fix 
>>> in java code.
>>>
>>> best regards,
>>>
>>> michael
>>>
>>
>