On Apr 25, 2008, at 4:08 AM, Attila Szegedi wrote: > On 2008.04.25., at 12:54, hlovatt wrote: > >> All, Java, C#, & C, tests are on Windows XP running under >> Parallels on >> a Mac Book Pro., 2.33 GHz Intel Core 2 Duo, 2 GB 667 MHz DDR2 SDRAM. > > Benchmarking under a virtualized OS? Kirk just wrote recently about > that: <http://kirk.blog-city.com/can_i_bench_with_virtualization.htm>
A Java-to-Java comparison (VMWare/Windows to Mac OS X) would be interesting for VMWare aficionados. Scimark is a good benchmark for basic CPU/FPU use. It is sensitive to loop optimizations and array usage patterns, as well as to stray oddities like how your random number generator is designed. The JVM does well on loop opts., and there is always more to do (current bleeding edge is SIMD). A couple of scimark benchmarks use 2-D arrays (not surprising!) and the JVM is a little weak there because of the lack of true 2-D arrays. We have long known how to fix this under the covers, but as we soberly prioritize our opportunities, we've chosen to work on other things. An excellent outcome of the OpenJDK is that the community can now vote with code about which optimizations are most important. At best, this sort of small benchmark will reach C++ levels of performance on the JVM. (At least until we do really aggressive task decomposition and use our virtualization freedom to lie about data structure layouts. But at present the state of the art is to require heavy input from the programmer for such things.) At the risk of prolonging the benchmark battle, I have to admit that scimark is not the sort of app. I had in mind when I was bragging about the JVM earlier on this thread. (Sorry Fan guys. Major thread hijack here. Your stuff looks cool, esp. the library agnostic part.) The JVM's most sophisticated tricks (as enumerated elsewhere) have to do with optimistic profile-driven optimizations, with deoptimization backoffs. These show up when the system is large and decoupled enough that code from point A is reused at point B in a type context that is unknown at A. At that point, the JVM (following Smalltalk and Self traditions) can fill in missing information accumulated during warm-up, which can drive optimization of point A in terms of specific use cases at point B. All of this works best when the optimizations are allowed to fail when the use cases at B change (due to app. phase changes, e.g.) or when points C and D show up and causes the compilation of A's use cases to be reconsidered. Key methods get recompiled multiple times as the app. finds its hot spot. It is these sorts of optimistic, online optimizations that makes the JVM run faster than C++, when it does. (It does, e.g., when it inlines hot interface calls and optimizes across the call boundary.) Microsoft could do so with C# also, but probably not as long as the C# JIT runs at application load time, which (as I am told by friendly Microsoft colleagues) it does. A final note about C# vs. Java on Intel chips. We have noticed that the Intel (and AMD) chips are remarkably tolerant of junky object code. Part of the challenge of JVM engineering is to find optimizations that tend to make code run better across a range of platforms with other core competencies (like many-core SPARC, obviously for Sun). I speculate that Hotspot has been driven to work harder on clever optimizations not only because we have competed with other excellent implementations (IBM J9, BEA JRockit), but also because Java needs to run on a wider range of chips than C#; some of them are less forgiving than x86. A way to quantify the "chip factor" would be to compare the gap between server and client JITs on a range of Java apps., especially simpler more "static" ones like scimark. More forgiving chips would narrow the gap. Best wishes, -- John --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
