Which is faster, Clojure or ClojureScript (and why)?

18
votes

If I had to guess, I'm pretty sure the answer is Clojure, but I'm not sure why. Logically (to me) it seems like ClojureScript should be faster:

Both are "dynamic", but ClojureScript

  • Compiles to JavaScript, running on V8
  • V8 engine is arguably the fastest dynamic language engine there is
  • V8 is written in C

whereas Clojure:

  • Is also dynamic
  • Runs in JVM, which has no built-in dynamic support, so I'm thinking thus JVM has to do whatever V8 is doing too, to enable dynamic support
  • and Java is slower than C

So how could Clojure be faster than ClojureScript? Does "dynamic" mean something different when saying JavaScript is dynamic and Clojure is dynamic? What am I not seeing?

(Of course if ClojureScript is indeed faster, then is the above reasoning correct?)

I guess, what does Clojure compile to....is at least part of the question. I know the JVM part can't just be a plain interpreter (otherwise ClojureScript would be faster), but Clojure can't compile to regular bytecode, as there's no "dynamic" in the JVM. So what's the difference between how ClojureScript is compiled/executed and how Clojure is compiled/excecuted and how plain Java is compiled/executed, and the performance differences implied in each?

3
clojurev8clojurescript
"Java is slower than C" may be true for many problem domains, but is irrelevant. The appropriate question is "Is Java slower than V8". V8 does not run your code as compiled C code, it is a JavaScript interpreter that happens to be written in C. – Eric J.
@EricJ. I guess that's my question then, I'm seeing V8 interpreting Clojure-generated JavaScript vs. a JVM that interprets Clojure. V8 compiles that JS down to machine code and runs it. What does the JVM do that's faster? – lobsterism
Clojure is compiled to byte code, just like Java. What made you think it wasn't? – Diego Basch
@DiegoBasch there's no dynamic support in the JVM. So how would it execute dynamic methods faster than V8, which is in my understanding the fastest dynamic runtime there is? – lobsterism
@lobsterism read this: clojure.org/compilation – Diego Basch

3 Answers

27
votes

This question is hard to answer precisely, without reference to a specific benchmark task (or even specific versions of Clojure or ClojureScript).

Having said that, in most situation I would expect Clojure to be somewhat faster. Reasons:

  • Clojure usually compiles down to static code, so it doesn't actually do any dynamic lookups at runtime. This is quite important: high performance code often produces bytecode that is very similar to statically typed Java. The question appears to be making the false assumption that a dynamic language has to do dynamic method lookups at runtime: this is not always the case (and usually isn't in Clojure)
  • The JVM JIT is very well engineered, and I believe it is currently still a bit better than the JavaScript JITs, despite how good V8 is.
  • If you need concurrency or need to take advantage of multiple cores then clearly there is no contest since JavaScript is single-threaded.....
  • The Clojure compiler is more mature than ClojureScript, and has had quite a lot of performance tuning work in recent years (including things like primitive support, protocols etc.)

Of course, it is possible to write fast or slow code in any language. This will make more of a difference than the fundamental difference between the language implementations.

And more fundamentally, your choice between Clojure and ClojureScript shouldn't be about performance in any case. Both offer compelling productivity advantages. The main deciding factor should be:

  • If you want to run on the web, use ClojureScript
  • If you want to run on the server in a JVM environnment, use Clojure
32
votes

Actually, V8 is written in C++. However, does basically the same thing as the JVM, and JVM is written in C. V8 JITs Javascript code and executes the JIT'd code. Likewise the JVM JIT compiles (or hotspot compiles) bytecode (NOT Java) and executes that generated code.

Bytecode is not static, as Java is. In fact it can be quite dynamic. Java, on the other hand is mostly static, and it is not correct to conflate Java with bytecode. The java compiler transforms Java source code into bytecode, and the JVM executes the bytecode. For more information, I recommend you look at John Rose's blog (example). There's a lot of good information there. Also, try to look for talks by Cliff Click (like this one).

Likewise, Clojure code is directly compiled to bytecode, and the JVM then does the same process with that bytecode. Compiling Clojure is usually done at runtime, which is not the speediest process. Likewise the translation of Clojurescript into Javascript is not fast either. V8's translation of Javascript to executable form is obviously quite fast. Clojure can be ahead of time compiled to bytecode though, and that can eliminate a lot of startup overhead.

As you said, it's also not really correct to say that the JVM interprets bytecode. The 1.0 release did that more than 17 years ago!

Traditionally, there were two compilation modes. The first mode is a JIT (Just in Time) compiler. Where bytecode is translated directly to machine code. Java's JIT compiling executes fast, and it doesn't generate highly optimized code. It runs OK.

The second mode is called the hotspot compiler. The hotspot compiler is very sophisticated. It starts the program very quickly in interpreted mode, and it analyzes it as the program runs. As it detects hotspots (spots in the code that execute frequently), it will compile those. Whereas the JIT compiler has to be fast because nothing executes unless it's JIT'ed the hotspot compiler can afford to spend extra time to optimize the snot out of the code that it's compiling.

Additionally, it can go back and revisit that code later on and apply yet more optimizations to it if necessary and possible. This is the point where the hotspot compiler can start to beat compiled C/C++. Because it has runtime knowledge of the code, it can afford to apply optimizations that a static C/C++ compiler cannot do. For example, it can inline virtual functions.

Hotspot has one other feature, which to the best of my knowledge no other environment has, it can also deoptimize code if necessary. For example, if the code were continually taking a single branch, and that was optimized and the runtime conditions change forcing the code down the other (unoptimized) branch and performance suddenly becomes terrible. Hotspot can deoptimize that function and begin the analysis again to figure out how to make it run better.

A downside of hotspot is that it starts a bit slow. One change in the Java 7 JVM has been to combine the JIT compiler and the hotspot compiler. This mode is new, though, and it's not the default, but once it is initial startup should be good and then it can begin the advanced optimizations that the JVM is so good at.

Cheers!

2
votes

This is not so much an answer as an historical comment: Both the HotSpot VM and the V8 js engine can have their origins traced to the Self project at Sun Microsystems, which I think prototyped a lot of the technology that allows them to run as fast as they do. Something to consider when comparing them both. I would've posted this as a comment but the reputation system prevented me.