Performance characteristics of mutable static primitives? - JVM Languages

Message from discussion Performance characteristics of mutable static primitives?

Charles Oliver Nutter

More options Apr 2, 5:43 am

From: Charles Oliver Nutter <charles.nut...@sun.com>

Date: Wed, 02 Apr 2008 10:43:46 +0100

Local: Wed, Apr 2 2008 5:43 am

Subject: Re: [jvm-l] Re: Performance characteristics of mutable static primitives?

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

John Wilson wrote:
> On 4/2/08, Charles Oliver Nutter <charles.nut...@sun.com> 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

Reply to author Forward