[patterns-instanceof-primitive] RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch [v3]

[Michael Hixson]

On Sun, 12 Mar 2023 09:16:17 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> @rgiulietti In local benchmarks, the compact version of `long_double` is slower than what was in the PR originally, which in turn is slower than the "lazy trailing zeros" version in my previous comment.
>> 
>> Did you arrive at that compact form through benchmarking?  If so, great - my benchmarks might be bad or I might have conflicting results because I'm on Windows.  If not, I'll suggest that faster forms of this method may exist, which may be worth investigating... eventually.
>
> I added a benchmarks file (we may or may not keep it in the final PR) that we can discuss during the finalization of the PR on openjdk/jdk/. In any case, feel free to take a look on the test.
> 
> I followed these [instructions](https://openjdk.org/groups/build/doc/testing.html) for more info. 
> 
> The following are quick measurements on an Apple M1 Max chip/macOS 13.2.1 (22D68) -- quick meaning that if we want to keep them, we should run them with 3 forks for 15wi/15i at least.
> 
> 
> sh make/devkit/createJMHBundle.sh
> 
> bash configure --with-boot-jdk="<.....>/prebuilt/jdk-19.jdk/Contents/Home/" --with-jmh=<.....>/jdk/make/devkit/../../build/jmh/jars/ -disable-warnings-as-errors
> 
> make test TEST="micro:org.openjdk.bench.jdk.preview.patterns.Exactness" MICRO="OPTIONS=-p "pollute=true";VM_OPTIONS=--enable-native-access=ALL-UNNAMED;RESULTS_FORMAT=json" CONF=rel
> 
> Exactness.test_float_int_based_on_compare             avgt    5  22001.714 ±  21.124  ms/op
> Exactness.test_float_int_based_on_filtering           avgt    5  21459.505 ± 159.797  ms/op
> Exactness.test_int_float_based_on_filtering           avgt    5   1464.611 ±   5.375  ms/op
> Exactness.test_int_float_based_on_leading_trailing    avgt    5   2741.839 ±  10.300  ms/op
> Exactness.test_long_double_based_on_filtering         avgt    5   1379.058 ±   4.329  ms/op
> Exactness.test_long_double_based_on_leading_trailing  avgt    5   2439.624 ±   4.366  ms/op
> Exactness.test_long_float_based_on_filtering          avgt    5   1491.983 ±   8.019  ms/op
> Exactness.test_long_float_based_on_leading_trailing   avgt    5   2736.461 ±   9.508  ms/op
> 
> 
> Interesting that both float_int are the same and I observe that the filtering ones (or compact) are better than all the analytical (leading_trailing).

@biboudis It's interesting that your `long_double` results conflict with mine.

My results on an i7-7700K + Windows:

Benchmark                                             Mode  Cnt     Score     Error  Units
Exactness.test_long_double_based_on_filtering         avgt    5  4579.436 ±  66.288  ms/op
Exactness.test_long_double_based_on_leading_trailing  avgt    5  3322.384 ± 110.679  ms/op


My results on an i9-7960X + Windows:

Benchmark                                             Mode  Cnt     Score     Error  Units
Exactness.test_long_double_based_on_filtering         avgt    5  5403.940 ± 186.774  ms/op
Exactness.test_long_double_based_on_leading_trailing  avgt    5  3828.349 ±  81.673  ms/op


I've never been able to build the JDK, so I copied your test code into a standalone project with Java 19 and JMH 1.36.  So there's that, the processors, and the operating systems as possible sources of the difference.

I'm not sure how to tell whose results are more "correct", if there is such a thing.  I suppose that if the performance is a wash, the filtering approach is more attractive: it's easier to understand and it's stylistically similar to the rest of the exactness methods.

Thanks for trying out the benchmarks anyway.

-------------

PR: https://git.openjdk.org/amber/pull/91