For interest here are some benchmarks for Scigmark running on the server VM with the large data set. First Apple 1.5:
SciGMark 1.0 - Java - specialized FFT (1048576): 62.711646778865195 SOR (1000x1000): 802.7910624263924 Monte Carlo : 68.74147451132121 Sparse matmult (N=100000, nz=1000000): 389.20565429955906 LU (1000x1000): 485.554737191564 PolyMult (N=100): 544.318902672618 Composite Score: 392.22057964671995 java.vendor: Apple Inc. java.version: 1.5.0_13 os.arch: i386 os.name: Mac OS X os.version: 10.5.2 Apple 1.6: SciGMark 1.0 - Java - specialized FFT (1048576): 60.0700425355947 SOR (1000x1000): 809.360923579094 Monte Carlo : 247.8628256348222 Sparse matmult (N=100000, nz=1000000): 392.63803077958215 LU (1000x1000): 482.56725581280824 PolyMult (N=100): 530.6558813726939 Composite Score: 420.5258266190992 java.vendor: Apple Inc. java.version: 1.6.0_05 os.arch: x86_64 os.name: Mac OS X os.version: 10.5.2 SoyLatte: SciGMark 1.0 - Java - specialized FFT (1048576): 62.49180158350285 SOR (1000x1000): 776.1668443011343 Monte Carlo : 242.5986885023368 Sparse matmult (N=100000, nz=1000000): 414.2394617450079 LU (1000x1000): 399.2015785688642 PolyMult (N=100): 461.52110196389737 Composite Score: 392.7032461107906 java.vendor: Sun Microsystems Inc. java.version: 1.6.0_03-p3 os.arch: amd64 os.name: Darwin os.version: 9.2.2 All runs are for a MacBook Pro 2.33 GHz Intel Core 2 Duo, 2 GB 667 MHz DDR2 SDRAM on OS X 10.5.2 (despite what SoyLatte thinks) with my typical mix of programs running (Safari, Entourage, Word, Excel, iTunes, and Firefox). The benchmarks are all from within Netbeans. The Apple 1.6 appears to be a bit quicker - but not much in it for this benchmark. On Apr 26, 9:26 am, hlovatt <[EMAIL PROTECTED]> wrote: > For interest, the same benchmarks on the native Mac OS running > SoyLatte with the -server option and the large data set are: > > SciGMark 1.0 - Java - specialized > FFT (1048576): 66.06220438347867 > SOR (1000x1000): 788.5439976789686 > Monte Carlo : 241.39879385124996 > Sparse matmult (N=100000, nz=1000000): 425.0726583860497 > LU (1000x1000): 414.8516922439953 > PolyMult (N=100): 531.6603292535906 > > Composite Score: 411.2649459662221 > > java.vendor: Sun Microsystems Inc. > java.version: 1.6.0_03-p3 > os.arch: amd64 > os.name: Darwin > os.version: 9.2.2 > > Which is a little faster - so the overhead of Parallels plus Windows > is small compared to native 10.5.2. > > It would be interesting to see some other benchmarks that are more > like a typical OO application. The Scimark tests, whilst typical of > scientific applications, are not like typical OO applications; few > virtual methods, little GC, etc. > > Sorry to the Fan people for high jacking their thread. > > On Apr 26, 6:54 am, John Rose <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
