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
chameneos-reduxNo program
regex-dna1/241/2
sum-file±2±
nsieve±2±
pidigits±4±
binary-trees±3±
fannkuch±3±
spectral-norm29±
fasta23±
nsieve-bits24±
k-nucleotide27±
n-body212±
mandelbrot23±
partial-sums43±
recursive412± 7
reverse-complement64±

± look at the measurements

 Java 6 -server comparison measurements

Program & Logs CPU secs Memory KB Size B Elapsed secs ~ CPU Load
 regex-dna 
Java 6 -server #24.0652,248711  
C++ GNU g++ #36.4513,4081588  
 sum-file 
Java 6 -server #24.7822,872222  
C++ GNU g++ #26.2914,864260  
 nsieve 
Java 6 -server4.0319,824452  
C++ GNU g++ #33.7610,788313  
 pidigits 
Java 6 -server #23.3111,728938  
C++ GNU g++ #22.853,124652  
 binary-trees 
Java 6 -server #27.5624,012603  
C++ GNU g++ #25.917,000541  
 fannkuch 
Java 6 -server #211.799,888761  
C++ GNU g++ #28.283,096554  
 spectral-norm 
Java 6 -server27.1526,424514  
C++ GNU g++17.493,092442  
 fasta 
Java 6 -server #219.9610,0961240  
C++ GNU g++ #411.693,1201248  
 nsieve-bits 
Java 6 -server #35.1312,204517  
C++ GNU g++2.803,328494  
 k-nucleotide 
Java 6 -server15.7566,5401052  
C++ GNU g++ #37.639,3121380  
 n-body 
Java 6 -server27.5410,8881430  
C++ GNU g++ #212.789361705  
 mandelbrot 
Java 6 -server #36.629,984623  
C++ GNU g++3.003,312584  
 partial-sums 
Java 6 -server #26.859,460470  
C++ GNU g++ #31.843,096531  
 recursive N = 7 reduced workload 
Java 6 -server0.689,652427  
C++ GNU g++0.16808345  
 reverse-complement 
Java 6 -server3.6446,700863  
C++ GNU g++ #30.6313,288810  

 about Java 6 -server

Java HotSpot(TM) Server VM (build 1.6.0-b105, 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