Optimizing Java Linpack

[ index | benchmarks | speed | size | maintainability | rules | tools | compilers ]

I took the original Java Linpack benchmark, by Jack Dongarra and Reed Wade, and applied some of the optimizations from my Java Optimization page:

• Added the final modifier to performance-critical methods.
• Used compound assignment operators such as += wherever possible, changing code of the form a[i] = a[i] + x to a[i] += x (strength reduction).
• Used temporary scalars to hold frequently-used elements of 1D arrays (common subexpression elimination).
• Used temporary 1D arrays to hold frequently-used columns of 2D arrays (ditto).
• Eliminated unused variables (dead code elimination).
• Undid an unrolled loop.
• Supplied my own abs() method.

The optimized code is typically 10-20% faster when run on the JDK interpreter, depending on the architecture, but may not show any improvement at all when run under a just-in-time compiler. Here are some sample MFlops ratings (higher is better), running the original and optimized code. The first three results are for the JDK on different machines, while the last four results compare different just-in-time compilers on the same machine.

Machine	Original	Optimized
Sparc5/85, JDK 1.0.2	0.25	0.30
HP 712/60, JDK 1.0.2	0.15	0.16
DX4-120, JDK 1.0.2	0.22	0.26
DX4-120, Cafe 1.51	1.24	1.32
DX4-120, Visual Cafe PR 2	2.78	2.84
DX4-120, Netscape Navigator 3.0	1.87	1.92
DX4-120, Internet Explorer 3.0	3.21	3.21

Note that the benchmark is run 10 times to reduce clock granularity problems.

To try it for yourself, use the applet below. Depending on machine load, you may need to take the best of several runs.

[Your browser doesn't run Java]

Note: with more modern JITs, the optimized version is actually slower than the original (thanks to everyone who pointed this out :->). I suspect that putting the unrolled loop back and/or using JIT abs methods would restore its performance advantage. Consider this a salutory reminder of the dangers of optimization!