I have heard many-a-times that LLVM is slow when it comes to compilation; I heard it in relations to why Go did not choose LLVM, and Rust having long compilation times, and this video where Jeff Bezanson talks about LLVM being slow.
I have no knowledge of compilers and I didn’t understand all the content in the video so I can’t comment on a technical perspective but does this mean that Julia will get slower and slower in the compilation if it continues to use LLVM?
Will this make Julia less and less like a dynamic language like Python and R?
I picture this in the future, I write a function, the first time it runs it takes 10 seconds, because of compilation. Afterward that it’s fast but the initial 10 seconds is going to be a pain. People will start talking about Julia as a “slow” language or that it’s a pretend-dynamic language as it’s actually almost the same as an AOT language given the compilation time.
I have come to love the Julia language for its performance and I am not sure if I should get worried about my version of the future actually happening? Can anyone in the know clarify this? Thanks!
On a reasonably recent computer, 10s compilation times are very long for a single function. Can you provide an example? For me, multiple packages precompile in a few seconds after a Pkg.update() (which, admittedly, I do daily). To get 10s+ compilation times, I need to use complex ecosystems like Plots.jl.
@Tamas_Papp Just an exaggeration but say it takes a bit of time, that is noticably longer than Python or R. It’s a “vision” from the future, one of the possibilities.
For the avoidance of doubt, I have the utmost respect for everyone working in the Julia ecosystem and especially the creators. I am sorry if my question can be interpreted in any way to suggest any hint of disrespect.
LLVM is outside of the control of the creators/maintainers of Julia. So if it continues to get slower and slower compilation time (maybe because its main targets are AOT languages), and Julia continues to depend on it, is there any reason to get worried? Maybe the 10 second compilation scenario in my original post was too much of an exaggeration, but the point is that if this trend of slower LLVM compilation time gets worse, is there any reason to worry for the average user who is investing time into learning/using Julia? Is the expectation of reasonably fast compilation time going to hold in the future?
IMHO it’s good to clarify and have this explained.
I actually think that several Julia developers also contribute to LLVM, so that is going to help. Also, it’s hard to say anything about trends in LLVM based on Julia as (at least on Julia 0.6 on my machine) Julia is still using LLVM 3.9.1 (latest LLVM release is 5.0.0 I believe).
No, there is no need for the average user to worry about this. The version of LLVM used, the patches being rolled, what optimization passes that are used etc, is something that the developers of Julia is very much in control of.
We still haven’t even began exploring all other good opportunities, for good reason. For example, LLVM JIT compilation is just one way to implement the Julia language: a quick loading interpreter could be a nice addition for just banging away at code. Also, we really haven’t explored ahead-of-time compilation all that much. Package precompilation doesn’t build a binary or whatnot of “basic functions” for the package that matches what your compilation cache is if you were to run the test suite: what if we were to do that? What if some packages just shipped a quick binary? (MakiE is already trying to do that)
Right now we are pretty clearly seeing “the worst” of it, but it’s also clear why. The movement for 1.0 is to get all of the breaking changes done. Compiler optimizations and compilation time optimizations are not breaking changes since by definition they optimize the code you already have. So if you’ve been watching Julia closely, you’ll see that there are issues on a lot of these GC or compiler optimizations, but these have all been put aside for now to do things like the type-system redo, broadcast overhaul, etc. which all break language syntax. And in Stefan’s talk on the Julia roadmap, he even explains that we know about a lot optimizations hanging around, but the focus has been to first get the language we want, then fix the outlying optimization problems.
So lets wait for the language to settle first (it’s almost there!), then we can talk about optimizing our implementation. When that comes around, the promise of 1.0 is that your codes will get the optimization upgrades without breaking, which is what’s required for the package ecosystem to keep growing and for Julia to be put into production use.
