On Mon, 4 Dec 2023 16:04:35 GMT, Francesco Nigro <[email protected]> wrote:
>> Going out on this tangent... I've compared the mainline (Base) with a build >> where `String::equals` is restored to pre-JDK-8215017 using a modified >> version of the StringEquals microbenchmark that tests UTF16 Strings of size >> 3. One test (EQ) where the strings are equals, another (NE) where they are >> not. The EQ one is the main contender for a case that would benefit from >> avoiding the trailing byte check on aarch64: >> >> On my M1 (aarch64): >> >> >> Name Cnt Base Error Test Error Unit Change >> StringEquals.equalsUTF16_3_EQ 5 1,750 ± 0,009 1,864 ± 0,401 ns/op 0,94x >> (p = 0,070 ) >> StringEquals.equalsUTF16_3_NE 5 1,674 ± 0,026 1,839 ± 0,179 ns/op 0,91x >> (p = 0,001*) >> * = significant >> ``` >> >> Similarly restoring the pre-JDK-8215017 version seem to be a net loss on x86: >> >> Name Cnt Base Error Test Error Unit Change >> StringEquals.equalsUTF16_3_EQ 5 2.885 ± 0.054 2.886 ± 0.036 ns/op 1.00x >> (p = 0.837 ) >> StringEquals.equalsUTF16_3_NE 5 2.581 ± 0.002 2.756 ± 0.003 ns/op 0.94x >> (p = 0.000*) >> * = significant >> >> >> So it seems JDK-8215017 was either neutral or a small performance win >> (phew!). The avoided branch and overall reduction in code complexity >> outweighs the win (if any) from not having the redundant `COMPARE_BYTE` >> chunk of code emitted in the StringUTF16 case. There are other platforms I >> can't currently check, but I think it's likely that we'd see similar numbers >> there. So it seems to be the case that `StringUTF16::equals` can be safely >> removed. > > separated question @cl4es, how do you obtained the 'Change` column with the > `p` value? is in some jdk script I've missed? Gentle ping on the previous (although OT) question; did you have a OSS comparison tools which work on JMH results? If yes, is very nice! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1491970410
