RFR(XS): JDK-8010941: MinJumpTableSize is set to 18, investigate if that's still optimal
niclas.adlertz at oracle.com
Thu Sep 5 07:59:37 PDT 2013
Yes. SPARC is also included in the results.txt
I'll give an example:
LOSS: At 3:
Run result "switch_calculation": 166204.989 Â±(95%) 52.012 Â±(99%) 71.097 ops/msec
Run statistics "switch_calculation": min = 166105.218, avg = 166204.989, max = 166602.390, stdev = 111.134
Run confidence intervals "switch_calculation": 95% [166152.977, 166257.000], 99% [166133.892, 166276.085]
Run result "switch_calculation": 204049.471 Â±(95%) 119.901 Â±(99%) 163.897 ops/msec
Run statistics "switch_calculation": min = 203408.606, avg = 204049.471, max = 204390.380, stdev = 256.193
Run confidence intervals "switch_calculation": 95% [203929.570, 204169.372], 99% [203885.574, 204213.368]
Here, we have tried a switch statement with 3 cases (hence "3") and we lose performance by using a jump table (hence "LOSS").
When we use a jump table ("Using JumpTable") we get the score 166204.989 ops/msec, but when we don't use jump tables ("Not") we can do more ops/msec, 204049.471.
Again, sorry for the confusion.
On 5 sep 2013, at 16:52, Azeem Jiva <azeem.jiva at oracle.com> wrote:
> I agree with Aleksey, the data in raw format is hard to read. Can you organize the data into a chart or table? Have you tried a SPARC system?
> Azeem Jiva
> ----- Original Message -----
> From: aleksey.shipilev at oracle.com
> To: niclas.adlertz at oracle.com
> Cc: vladimir.kozlov at oracle.com, hotspot-compiler-dev at openjdk.java.net
> Sent: Thursday, September 5, 2013 7:14:01 AM GMT -08:00 US/Canada Pacific
> Subject: Re: RFR(XS): JDK-8010941: MinJumpTableSize is set to 18, investigate if that's still optimal
> Hi Niclas,
> I have trouble interpreting the results. What are the different numbers after win/loss? Jump table sizes? What is "Not"? Shouldn't "Not" be the same if they are not using the Jump Table? I am very confused.
> On 05.09.2013, at 16:41, Niclas Adlertz <niclas.adlertz at oracle.com> wrote:
>> Hi all.
>> Sorry for the delay.
>> I've written a JMH test and the results differs from what I previously got. Because of this, I propose the new MinJumpTableSize number to be 10.
>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8010941/webrev01/
>> Kind Regards,
>> Niclas Adlertz
>> On 22 maj 2013, at 00:48, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>> On 05/21/2013 10:17 PM, Vladimir Kozlov wrote:
>>>> We usually do about 20000 iterations and run with -Xbatch to make sure
>>>> tested method is compiled before time measurement.
>>> Yeah, that works if the benchmark is the single method call. Anything
>>> more complex require more complex warmup.
>>>>> Also, I begin to wonder if after the multiply_by_power_of_ten inlining
>>>>> start to affect how far we unroll the loop, since the jump tables are
>>>>> starting to be larger.
>>>> You can avoid it by
>>> Or, (chanting) use JMH:
>>> Or, (chanting again) use JMH, because it does not really use indexed
>>> loops, but rather volatile-predicated loop, so the loop unrolling is
>>> ineffective (double ineffective with the source data re-read from the
>>> fields on every iteration).
>>> Before you jump on other platforms, look into the assembly to see if
>>> your benchmark are actually generate the code that makes sense (i.e.
>>> trapped on any of the issues Vladimir and me had speculated here):
More information about the hotspot-compiler-dev