Why Java?
I'm guessing lots of folks will question my decision to implement Opal
in Java. I won't go overboard to defend my decision, but I do think it's
worth explaining myself.
Q: Why consider switching from C to Java?
A: It's a lot easier (for me) to correctly implement an algorithm
(and the program that wraps it)
in Java. That's because there's less complexity to memory management,
and also because the tools available for writing and testing Java
programs provide (in my opinion) vastly superior support to the coder.
Q: But Java is too slow to use in fast scientific software! What are you thinking?
A: What I'm thinking is that it's not all that slow, really.
Before going down this path, I found that there's plenty of evidence that
Java programs written with speed in mind (read: not using a ton of objects)
can compete quite nicely with the speed of programs written in C.
For a hint of the evidence that convinced me to give it a try, see:
-
a survey
of a number of benchmarks, which finds that Java performance on numerical
code is comparable to that of C++.
- in particular, see the informative
paper mentioned first in the survey.
-
a comparison of Java to C++ over a wide range of applications.
OK, so Java-lovers tell us that Java is fast. I was intrigued, but not
convinced. How to convince myself? Do my own test. I did, reimplementing
the original C code for Opal (and the subpackage,
alignalign) in a new Java
application.
I omit all details here, and hope you'll believe that the test
was as fair as I could make it. The C program was built to be as fast
as possible, given algorithmic constraints (e.g. using memory pools to avoid
malloc overhead).
With esentially identical algorithms, the Java implementation ran about
10% slower than the C implementation (on average) over a wide range of
inputs and several computers. Given the implementation and
portability benefits that come with using Java, that was close enough for me.
(update: 01/11/2011)
It is worth noting that in the three years since releasing Opal, I've identified at least three reasons
not to implement an application in Java:
- It can be a pain for an end user to get a modern JVM installed on an old system, if
they don't have sysadmin privileges
- I've seen some trouble with Java buffered I/O when reading very large inputs from
pipes (i.e. instead of from file)
- Java doesn't allow for SIMD vector-parallel acceleration
Travis Wheeler