Charles, what do you expect? That the VM spread out all global variables throughout the heap so that any broken access pattern cause not too many cache flushes? You're hammering a global from multiple threads, I don't think you can blame the JVM for that, be it for a new language or not.
Matthias On Thu, Apr 3, 2008 at 10:18 AM, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > > > John Rose wrote: > > Enclosed are the disassembly of the two loop kernels, from the Java 5 > > and Java 6 32-bit. The default JIT (on the machine I tested) was the > > server JIT. The loops look essentially the same to me on both releases. > > I also included the client version; those kernels look the same too. > > > > One difference is the effective addresses of the two shared variables > > happen to fall in distinct quadwords on Java 5 and in the same quadword > > on Java 6: > > > > 0x082025b4 &i in Java 5 0x082025b8 &firedCount in Java 5 0xb61dcae8 > > &i in Java 6 0xb61dcaec &firedCount in Java 6 > > > > This may be the best way to explain the performance > > difference, especially since moving firedCount into a separate class > > seems to erase the effect. > > > > Welcome to the multicore world! Memory is not flat like Kansas anymore. > > Pardon my ignorance, but why does that explain the performance > difference? Talking with Wayne Meissner he thought perhaps because the > two variables were closer together, updating one caused a cache flush of > both. That sounds reasonable, I suppose...but doesn't this still qualify > as a regression since performance is significantly worse under Java 6? > > I guess my concern is that one reason many of these new languages are > gaining traction on the JVM (especially in the case of Jython and JRuby) > is because they can be *actually* parallel. Without experimentally > finding this effect, we might have gone months or forever with poor > thread scaling, all because we used a single static variable instead of > separate thread-local variables. It's rather surprising, and makes me > worry about the rest of the codebase. > > So I guess there's a rule of thumb here: don't share data across threads > unless you absolutely need to. And perhaps: don't use statics (Gilad > would be proud). But something more concrete to say why this is bad, or > an explanation of how this effect is a trade-off for something much more > important (cache locality for field reads?) would help ease the pain... > > - 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 -~----------~----~----~----~------~----~------~--~---
