Compare the performance of Java 6 -server programs against some other language implementation.

For more information about the Java implementation we measured see ↓ about Java 6 -server.

Compare to:

 Java 6 -server comparison summary


1/2 1/3 1/4 … Java 6 -server is better
Programs Time Memory Use Source Size Reduced N
k-nucleotide  No GNU g++
fannkuch1/4132
binary-trees1/23±
regex-dna1/25±
n-body±16±
fasta±17±
spectral-norm±12±
mandelbrot22±
pidigits2183
chameneos-redux211±
reverse-complement321/2

± look at the measurements

 Java 6 -server comparison measurements

Program & Logs CPU secs Memory KB Size B Elapsed secs ~ CPU Load
 fannkuch 
Java 6 -server66.1013,768115018.34  80% 75% 99% 99%
C++ GNU g++ #271.421,09255471.41  100% 0% 0% 0%
 binary-trees 
Java 6 -server #230.80289,72460319.57  77% 26% 24% 30%
C++ GNU g++ #240.8099,39655340.79  0% 0% 0% 100%
 regex-dna 
Java 6 -server #245.39563,420153416.01  79% 67% 78% 58%
C++ GNU g++ #328.80116,612159928.80  31% 0% 0% 70%
 n-body 
Java 6 -server #225.2312,440142425.21  0% 0% 0% 100%
C++ GNU g++ #423.84788142823.84  1% 0% 100% 0%
 fasta 
Java 6 -server #27.5212,67212407.51  98% 0% 0% 2%
C++ GNU g++ #46.0774412666.07  0% 100% 0% 0%
 spectral-norm 
Java 6 -server #215.9412,5769504.09  97% 97% 99% 97%
C++ GNU g++ #712.011,03211143.01  100% 100% 100% 100%
 mandelbrot 
Java 6 -server #346.3648,94890311.72  99% 99% 99% 99%
C++ GNU g++ #524.7028,8008586.18  100% 100% 100% 100%
 pidigits 
Java 6 -server #413.8528,04818165.36  57% 61% 53% 62%
C++ GNU g++ #32.711,5966822.72  0% 9% 7% 100%
 chameneos-redux 
Java 6 -server #419.7212,81613777.06  56% 51% 77% 78%
C++ GNU g++ #412.101,16018003.46  83% 76% 99% 100%
 reverse-complement 
Java 6 -server #42.97473,3285922.99  36% 57% 0% 7%
C++ GNU g++ #21.81245,09210981.13  15% 31% 21% 88%

 about Java 6 -server

java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)

Home Page: http://java.sun.com/j2se/

Download: http://java.sun.com/j2se/downloads/

"Remember how HotSpot works. It starts by running your program with an interpreter. When it discovers that some method is "hot" -- that is, executed a lot, either because it is called a lot or because it contains loops that loop a lot -- it sends that method off to be compiled. After that one of two things will happen, either the next time the method is called the compiled version will be invoked (instead of the interpreted version) or the currently long running loop will be replaced, while still running, with the compiled method. The latter is known as "on stack replacement" and exists in the 1.3/1.4 HotSpot based systems."

Benchmarking the Java HotSpot VM

Revised BSD license