Re: JVM performance on Linux (vs. Solaris/Windows)

[Jeff V. Merkey]

Martin J. Bligh wrote:

> K P wrote:
>
> > Sun's recently published SPECjbb_2005 numbers on Linux, Windows and
> > Solaris on their
> > Opteron system, and the Linux result is the lowest of the three by far:
> >
> > Linux: 
> > http://www.spec.org/jbb2005/results/res2006q1/jbb2005-20060117-00062.html 
> >
> > Solaris: 
> > http://www.spec.org/jbb2005/results/res2006q1/jbb2005-20060117-00063.html 
> >
> > Windows: 
> > http://www.spec.org/jbb2005/results/res2006q1/jbb2005-20060117-00064.html 
> >
> >
> > It's not evident if Sun spent any time analyzing and tuning the Linux
> > result. While the
> > majority of the tuning opportunities for SPECjbb_2005 are likely to be
> > in the JVM itself, I was
> > wondering (given the large spread between the OS's) if there were
> > other typical opportunities
> > to tune the Linux kernel for JVM performance and SPECjbb_2005.
> >
> > There are some other results showing excellent scalability with 
> > SPECjbb_2005 on
> > Linux/Itanium (such as SGI's:
> > http://www.spec.org/jbb2005/results/res2006q2/ ), but it's
> > not clear if there are other opportunities for tuning unique to Linux
> > on Opteron, or Linux
> > in general that should be explored
> >
> > Comments?
> >  
>
> SpecJBB is a really frigging stupid benchmark. It's *much* more affected
> by the stupid crap in Java (like their locking model) than anything in 
> the
> OS.
> Best to find another benchmark, oh and preferably somebody vaguely
> objective to run it ;-)
>
> M.
Note they ran the benchmark on an Opteron 285 instead of a Xeon with 16 
GB of memory.    Opteron peformance currently **SUCKS** with 2.6 series 
kernels under any kind of heavy I/O due to their cloning of the ancient 
82489DX architecture for I/O interrupt access and performance.  Looks 
like the test was stakced against Linux from the start.  Should have 
used a Xeon system. 

AMD needs to get their crappy I/O performance up to snuff.  Looking at 
the test parameteres leads me to believe there was a lot of swapping on 
a system with already poor I/O performance.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/