OUT-OF-DATE! Read http://shootout.alioth.debian.org/      

- all benchmarks - n-body fannkuch (deprecated) meteor-contest fasta spectral-norm reverse-complement mandelbrot k-nucleotide regex-dna pidigits chameneos-redux thread-ring binary-trees hello-world sum-file nsieve nsieve-bits partial-sums recursive - all languages - BASIC FreeBASIC C GNU gcc C++ GNU g++ CAL Clean D Digital Mars Eiffel SmartEiffel Forth bigForth Forth GNU GForth Groovy Icon Io Lisaac Mercury Nice Oberon-2 OO2C Pike Prolog SWI Prolog YAP Rebol SML MLton SML SML/NJ Tcl Zonnon Mono

÷ BASIC FreeBASIC C GNU gcc C++ GNU g++ CAL Clean D Digital Mars Eiffel SmartEiffel Forth bigForth Forth GNU GForth Groovy Icon Io Lisaac Mercury Nice Oberon-2 OO2C Pike Prolog SWI Prolog YAP Rebol SML MLton SML SML/NJ Tcl Zonnon Mono

 Step 1 : Are the programs faster? At a glance.

This chart shows 3 comparisons - Time-used, Memory-used and Code-used ~ speed and size.

Each chart bar shows, for one unidentified benchmark, how much the fastest program used compared to the fastest Zonnon Mono program.

Look at speed another way - look at a box plot of Time-used data.

 Step 2 : Are the programs faster? Approximately.

This table shows 3 comparisons - Time-used, Memory-used and Code-used ~ speed and size.

Each table row shows, for one named benchmark, how much the fastest program used compared to the fastest Zonnon Mono program.

used what fraction? used how many times more?
Benchmark	Time	Memory	Code
n-body	1/2	2×	±
nsieve	±	2×	±

used what fraction? used how many times more?
Time-used	|-	|---	25%	median	75%	---|	-|
(CPU secs)	1/2	1/2	1/2	±	±	±	±

± read the measurements and then read the program source code.

 Step 3 : Are the programs faster? Measurements.

This table shows 5 measurements - CPU Time, Elapsed Time, Memory, Code and ≈ CPU Load ~ speed and size.

For each named benchmark, measurements of the fastest program are shown for comparison against measurements of the fastest Zonnon Mono program.

Program Source Code	CPU secs	Elapsed secs	Memory KB	Code B	≈ CPU Load
n-body
	14.75		11,524	1424
Zonnon Mono	34.61		5,168	1524
nsieve
	2.25		20,592	296
Zonnon Mono	2.32		9,744	368
fasta
	0.42		9,080	1240
	No program
k-nucleotide
	0.95		22,192	1052
	No program
reverse-complement
	0.22		3,984	592
	No program
mandelbrot
	0.20		3,548	623
	No program
recursive
	0.21		4,116	427
Zonnon Mono	Failed
pidigits
	0.23		8,720	938
	No program
binary-trees
	0.31		10,228	603
	No program
regex-dna
	2.37		35,808	921
	No program
nsieve-bits
	1.06		11,480	523
	No program
spectral-norm
	0.42		9,156	514
	No program
partial-sums
	0.25		10,960	474
Zonnon Mono	Failed

 Step 4 : Are there other programs for these benchmarks?

Remember - those are just the fastest and Zonnon Mono programs measured on this OS/machine. Check if there are other implementations of these benchmark programs for .

BASIC FreeBASIC C GNU gcc C++ GNU g++ CAL Clean D Digital Mars Eiffel SmartEiffel Forth bigForth Forth GNU GForth Groovy Icon Io Lisaac Mercury Nice Oberon-2 OO2C Pike Prolog SWI Prolog YAP Rebol SML MLton SML SML/NJ Tcl Zonnon Mono

Maybe one of those other programs is fastest on a different OS/machine.

 Step 5 : Are there other faster programs for these benchmarks?

Remember - those are just the fastest and Zonnon Mono programs measured on this OS/machine. Check if there are faster implementations of these benchmark programs for other programming languages.

n-body fannkuch (deprecated) meteor-contest fasta spectral-norm reverse-complement mandelbrot k-nucleotide regex-dna pidigits chameneos-redux thread-ring binary-trees hello-world sum-file nsieve nsieve-bits partial-sums recursive

Maybe one of those other programs is fastest on a different OS/machine.

  :  

java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode, sharing)

Home Page: Java SE at a Glance

Download: Java SE Downloads

See What about Java?

"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

  Home   Conclusions   License   Help