Performance of Pattern Matching for switch (Third Preview)

[Jordan Zimmerman]

Hi Jan,

Thanks for the detailed reply. TBH I didn't spend much time on the test so your comments are appropriate. I wrote the test after JFR reported SwitchBootstrap.typeSwitch as a hotspot in a project I'm working on. I think different tests getting different lengths doesn't really poison the tests as both implementations have the same chances for list sizes and content.

> I wonder how much effect has the use of ConcurrentHashMap

I tried the test with both a simple HashMap and ConcurrentHashMap and the delta was similar as I recall.

PR 9779 looks promising. Anyway, as a Java user I would expect that the compiler can write better code than I can manually FWIW.

Cheers.

-Jordan


> On Aug 11, 2022, at 1:26 PM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hi Jordan,
> 
> 
> 
> Thanks for the report. Yes, the performance of various pattern matching switches is something that we'd like to improve, which is a task that will probably take a while. Currently, one PR relevant to your benchmark is:
> 
> https://github.com/openjdk/jdk/pull/9779 <https://github.com/openjdk/jdk/pull/9779>
> 
> Looking at the benchmark, I have a few comments/questions:
> 
> 1. I see the "Data" generate the test List of a random length between 1000 and 2000, but as far as I can tell, different testcases will get a List of a different length. So the testcases are not really the same, as their input has a different length. Do I miss something here?
> 
> 2. The actual content of the List is also random, but, again, the content is not the same for all the testcases, which I believe could skew the results (consider input data which could have a majority of Fruit.Apple, and a different set of data which would have a majority of Fruit.Pear - the tasks to solve this is not the same). The effect of this is probably limited, though.
> 
> 3. The test uses 4 threads, but when I run it with this setting, the error margins are very wide, making the results much less reliable (per my understanding). Which may be a consequence of the limited amount (4 physical) of cores available on my laptop.
> 
> 
> 
> I've tweaked the test to use input data of length 1000 for all cases, and new Random(0) to generate the data.
> 
> 
> 
> The for one thread (testEnhancedSwitch uses the code from PR 9779, testEnhancedSwitchLegacy uses the code currently in the mainline, testManualSwitch is the same as in your testcase):
> 
> TestEnhancedSwitch.testEnhancedSwitch        thrpt    5   95020.310 ±  689.833  ops/s
> TestEnhancedSwitch.testEnhancedSwitchLegacy  thrpt    5   68175.714 ± 2245.512  ops/s
> TestEnhancedSwitch.testManualSwitch          thrpt    5  102640.203 ± 2384.880  ops/s
> 
> And for two threads:
> 
> TestEnhancedSwitch.testEnhancedSwitch        thrpt    5  47714.842 ± 2206.843  ops/s
> TestEnhancedSwitch.testEnhancedSwitchLegacy  thrpt    5  47080.128 ± 1679.960  ops/s
> TestEnhancedSwitch.testManualSwitch          thrpt    5  41116.334 ± 4938.590  ops/s
> 
> 
> 
> (In the multi threaded mode, I wonder how much effect has the use of ConcurrentHashMap.)
> 
> 
> 
> Thanks,
> 
>     Jan
> 
> 
> 
> On 10. 08. 22 12:04, Jordan Zimmerman wrote:
>> Hi Folks,
>> 
>> I've been experimenting with Pattern Matching for switch (Third Preview). I noticed that the performance of these enhanced switches is far worse than manual matching. Is this due to this only being a preview and optimizations have yet to be done? Anyway, I thought I'd mention what I found as an FYI.
>> 
>> Here's the jmh benchmark I used:
>> 	
>> 	https://gist.github.com/Randgalt/a68ceee62cd8127431cbe6e7afbfdf44 <https://gist.github.com/Randgalt/a68ceee62cd8127431cbe6e7afbfdf44>
>> 
>> Here are the results:
>> 
>> Benchmark                               Mode  Cnt      Score       Error  Units
>> TestEnhancedSwitch.testEnhancedSwitch  thrpt    5  30789.482 ± 17667.365  ops/s
>> TestEnhancedSwitch.testManualSwitch    thrpt    5  44651.612 ±  5135.641  ops/s
>> 
>> Cheers.
>> 
>> -Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220811/2bb2ed1c/attachment.htm>