JavaOne

EnfranchisedMind's Adventures at JavaOne 
« Back to blog

Alternative Languages on the JVM

Bytecodes for alternative languages are different than those for Java, which makes different performance characteristics. Reputation about being fast is critical for adoption.
 
Testing Java, Scala, Clojure, JPC, Jython, and Rhino. [ No Groovy! -ed ]
 
Can a language go "To the Metal"? Write a mini loop of something that's an xor and divide. This is to figure out what the different languages are up to. (Running on the Azul JVM)
 
NOTE: The goal here is not to find the "fastest language". Also ignoring blatant language microbenchmark mismatch.
 
Java came out with an rolled loop in the JIT. Scala generated pretty much the same code. Clojure was very close -- no dispatch logic, but it did have overflow checks. JRuby did not have major inlining. Rhino ended up boxing the values.
 
Java's advantage came from the close fit with JIT expectations. Scala was pretty much there, too, but it had the same semantics as Java (no overflow promotion), and if that's added in, it looks just as bad as the others.
 
JPC is a Java DOS 3.1 emulator. For this example, had 16000 classes, 7800 compiles.
 
Clojure was "almost close". No obvious subroutine calls in inner loop. The downside shows a lot of ephemeral object allocation, which requires escape analysis to kill the git. There were lots of fixnum overflow checks everywhere, which could be turned off.
 
Jython has a massive allocation and extra locks are thrown in, in addition to the fix-num issue.
 
JavaScript/Rhino used doubles. No fix-num talks.
 
JRuby didn't hit the metal, because there was substantial pain when the language expected CachingCallSite::Call was inlined. This is apparently getting better.

Loading mentions Retweet

Comments (0)

Leave a comment...

 
Got an account with one of these? Login here, or just enter your comment below.
Posterous-login    Connect    twitter