John Wilson wrote:
> On 4/2/08, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
>> I ran into a very strange effect when some Sun folks tried to benchmark
>> JRuby's multi-thread scalability. In short, adding more threads actually
>> caused the benchmarks to take longer.
>>
>> The source of the problem (at least the source that, when fixed, allowed
>> normal thread scaling), was an increment, mask, and test of a static int
>> field. The code in question looked like this:
>>
>> private static int count = 0;
>>
>> public void pollEvents(ThreadContext context) {
>> if ((count++ & 0xFF) == 0) context.poll();
>> }
>>
>> So the basic idea was that this would call poll() every 256 hits,
>> incrementing a counter all the while. My first attempt to improve
>> performance was to comment out the body of poll() in case it was causing
>> a threading bottleneck (it does some locking and such), but that had no
>> effect. Then, as a total shot in the dark, I commented out the entire
>> line above. Thread scaling went to normal.
>
> That is rather odd.
>
> Shouldn't count be volatile?
>
> If it's declared as volatile does that make any difference?
I had not tried it because I expected volatile would only make it
slower. And in this case, the code in question didn't really care about
perfect accuracy for the counter since it's just a rough guide. But
here's numbers with volatile on my machine:
Apple Java 5:
~/NetBeansProjects/jruby ➔ java -server Trouble 1
time: 9047
fired: 3906250
time: 9007
fired: 3906250
time: 9613
fired: 3906250
time: 9846
fired: 3906250
time: 10005
fired: 3906250
~/NetBeansProjects/jruby ➔ java -server Trouble 2
time: 22349
fired: 3540696
time: 27641
fired: 3341096
time: 26815
fired: 3546695
time: 26641
fired: 3542920
time: 26789
fired: 3534386
soylatte Java 6:
~/NetBeansProjects/jruby ➔ java -server Trouble 1
time: 9777
fired: 3906250
time: 9701
fired: 3906250
time: 9070
fired: 3906250
time: 8656
fired: 3906250
time: 9065
fired: 3906250
~/NetBeansProjects/jruby ➔ java -server Trouble 2
time: 24781
fired: 3464957
time: 23668
fired: 3758204
time: 21235
fired: 3783215
time: 22198
fired: 3761491
time: 22937
fired: 3752534
So as expected, volatile does slow things down a lot, but Java 6 does do
a little better here. Also interesting to see that volatile completely
obliterates any gain from running multiple threads on both Java 5 and
Java 6, and the total time is almost 3x slower than a single thread on
Java 5.
I tried another non-volatile run using i += 1 rather than i++ and the
numbers were almost identical, with Java 6 severely degrading with
multiple threads running and Java 5 improving.
Here's another set of numbers from Vladimir Sizikov, on a dual-core
windows machine running Sun Java 5 and Sun Java 6:
D:\work>D:/re/java5/bin/java -server Trouble 2
time: 1666
fired: 3345620
time: 1453
fired: 4033604
time: 629
fired: 3592687
time: 569
fired: 3595772
time: 578
D:\work>D:/re/java6/bin/java -server Trouble 2
time: 1595
fired: 3896153
time: 1588
fired: 3900934
time: 2090
fired: 3896066
time: 2133
fired: 3891300
time: 2154
fired: 3892321
Again, significantly worse performance in Java 6 with multiple threads.
- Charlie
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
