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 -~----------~----~----~----~------~----~------~--~---
