Slow Interpreter

[dcampbell24]

The Interpreter seems to be very slow relative to other compiles and interpreters. On my machine (Intel(R) Atom(TM) CPU N475 @ 1.83GHz) it takes over 8 seconds to run a program that does nothing; when entering commands in an interactive session, there is a noticeable delay for "2 + 2". This is very annoying when doing interactive development and learning.

I spent some time using valgrind and pprof to look for obvious bottlenecks, but did not see any. I am guessing the issue may be related to the speed of the llvm JIT based on this stack overflow post.

[pao]

Startup speed is #260.

[timholy]

@davekong , are you saying it's always slow? On every command you execute? If so, this is not the typical experience---the main attraction of Julia is that it's fast.

[dcampbell24]

Yes, it is slow for every command in comparison to at least the interpreters for Clojure, Python, and R.

[dmbates]

It might help if you could post an example of code on which there is poor performance by Julia. In my experience, described on dmbates.blogspot.com, Julia code ran much faster than R code and even compiled code called from R using Rcpp.

[timholy]

Just to triple-check: you're saying that if you type "2 + 2" you get a delay, and if you type "2 + 2" again you still get the same delay, and can repeat this forever? If so, then there's definitely something wrong with your Julia installation. If this is the case, then we'd need to know more about how you installed Julia.

In contrast, if there's a delay the first time but it goes away for all subsequent times with the same command, that's normal. It sounds like you understand this stuff, but in case not, it occurs because code is being compiled the first time you run a command. On every subsequent run, it should have C-like speed. And indeed even for "new" commands the delay generally gets shorter the longer you use Julia, because it keeps all the previously-compiled functions around. So it no longer needs to compile the code for generating the printed version of an integer, for example, because it already did that.

This is a little beyond my experience, but I have the impression that an interpreter (versus an optimizing compiler) doesn't necessarily have to do as much work up-front. There's a lot more type inference required to generate well-optimized code, and that seems to take some time.

[dcampbell24]

The commands are only slow the first time, but I still think it would be worthwhile to try to improve the speed here. The JIT Wikipedia article explains the issues a little and some of the potential solutions. I don't know enough of the details about how Julia works to know what the best solutions may be, but maybe we can use some ideas from pypy or Hotspot.

[nolta]

How much memory do you have?

[dcampbell24]

The machine I noted earlier has 1GB, my desktop, on which I experience the same slowness, has 3GB.

[nolta]

And they both have Atom CPUs?

[dcampbell24]

The desktop has a dual core Intel(R) Pentium(R) D CPU 2.66GHz.

[Keno]

This will be easier once we have the static compiler which could pre-compile/cache frequently used functions and also eliminate the startup delay. However, it will take some work to get the static compiler working and there isn't really much we can do from this point without hits to overall performance or a not insignificant commitment of time (my humble opinion of course). Also, I do not consider the inital delay after using an expression for the first time to be a critical problem but rather a minor annoyance that I personally can endure until the static compiler is available.

[JeffBezanson]

You can try commenting out the line in codegen.cpp that calls FPM->run; this disables LLVM optimizations and shaves off about 20% of compile time. I don't know if that will be enough to make a meaningful difference. We will eventually expose this as a command line option.