in short, it’s a reasonably good static compilier but a terrible JIT (or bascially it’s not a JIT)…
By saying that its a static compiler, what I mean is that it does not use any runtimme information to produce optimized code. (Here static information is basically anything in the type domain whereas runtime information being anything in the value domain). The advantage of this approach is that if the code is well writen, the performance will be predictably good, the compile time will also be very predictable since it’s only compilied on the first call. Being a new language, the advantage we have here is to design the language in a way that writing good code is easy and provide tools to help it.
OTOH, this also makes it a bad JIT (in some tranditional sense) compare to essentially all JIT you can find elsewhere. Basically we can only produce good code, possibly among the best of any code produced by JIT thanks to LLVM’s optimization passes, but can only do so for good julia code (i.e. if you follow performance tip). If you fail to do that, or write in a pattern that’s frequently seen in R/python/JS, the performance will be much slower compare to other JIT out there since the JIT for those languages has to deal with these code so they implements a lot of speculative or profiling based optimizations to get good performance. Jeff’s talk provided a really nice analogy. What we have is basically an asm.js compiler (and including syntax to make writing it easier) and what other JITs have is, well, a JIT. If you feed asm.js to both, we’ll beat them with no doubt but if you feed normal js to both we’ll have no way to perform comparable to the real JITs out there. Hope it’s not too hard to see that having an asm.js compiler is very far from having aproper js JIT.