How fast is JIVA?

One of the first questions that springs to mind when considering purchasing high performance computing system is "how fast is it?" It's speed that makes super computers "super" right? When you invest in parallel computing you're investing in getting things done faster. And JIVA might raise some curious eyebrows because it's written in Java a language known for it's portability and utility but not its speed. Our technical team is made up primarily of aerospace engineers and computer scientists. They take performance seriously. And when we decided that security concerns mandated an implementation in Java, we were worried that JIVA's performance might suffer because of it.

JIVA is written in Java, and runs primarily as a volunteer computing system, which means that there are generally two parameters that affect its performance:   the performance penalty for running in a Java Virtual Machine, and the overall availability of the machine it is running on.

Performance Impact of Using Java

One of our first priorities was to find a way to quantitatively compare JIVA's performance more traditional high performance numerical codes.   Fortunately for us, the good folks at NIST (the National Institute of Standards and Technology) beat us to the punch.

The Scimark 2 Numerical Benchmarks (written by Roldan Pozo and Bruce Miller) provide two sets of codes:   one in C and one in Java, that run through identical suites of Fast Fourier Transforms, Jacobi Successive Over-Relaxation, Monte Carlo integration, Sparse matrix multiplication, and dense Lower-Upper matrix factorization problems.   By running the two codes on the same machine it is possible to get a good idea of the differences in performance.

Purists might argue that there are incredibly optimized FORTRAN libraries to do these things, and that those would be faster than either C or Java, and we agree.   But this does provide a good comparison optimized native code to Java and addresses the more general question of "how much of a performance hit will JIVA suffer if implemented in Java?" at least to our own satisfaction.

We compiled the native code with all optimizations turned on and compared it to the performance we got running the Java version in a screen saver on the same machine. As it turns out, JIVA runs at about 91% of the speed of the native code, so the performance hit was a mere 9%.

Performance Impact of Host Availability

One thing that we found is that the actual availability of the computers on which your code runs has a much bigger impact than whether it is native or Java.  

If you are comparing the work done by a dedicated computer (one that does nothing but run your code 24 hours a day) to the work done on a volunteered system (which only can run your code when the system is not being used), whether you are using Java or native code is pretty much lost in the noise.  

Consider the following table, in which we consider how many machines are required to match the performance of a single computer running native code around the clock.

If you are considering using a volunteer system instead of a dedicated one, you are going to need about two volunteer machines in this case to run your code to get the same performance, regardless of whether you are using native code or JIVA.  

The bottom line: host availability is the dominant factor, and whether you're using native code or Java, you'll need about the same number of volunteers to match the work done by dedicated hardware.

And with JIVA's enhanced security features and portability, you'll probably get more volunteers anyway...