69

Julia language compiles the script every time, can't we compile binaries with julia instead? I tried a small helloworld script with println function it took 2 to 3 seconds for julia to show the output! It would be better if we can make binaries instead of compiling every time

Update: There have been some changes in Julia, since I asked this question. Though I'm not following the updates for julia anymore, since I've asked this question and if you're looking for something similar, look into the below answers and comments by people who are following julia.

Also, its good to know that now it takes around 150 ms to load a script.

Asclepius
  • 57,944
  • 17
  • 167
  • 143
pahnin
  • 5,367
  • 12
  • 40
  • 57

2 Answers2

107

Keno's answer is spot on, but maybe I can give a little more detail on what's going on and what we're planning to do about it.

Currently there is only an LLVM JIT mode:

  • There's a very trivial interpreter for some simple top-level statements.
  • All other code is jitted into machine code before execution. The code is aggressively specialized using the run-time types of the values that the code is being applied to, propagated through the program using dynamic type inference.

This is how Julia gets good performance even when code is written without type annotations: if you call f(1) you get code specialized for Int64 — the type of 1 on 64-bit systems; if you call f(1.0) you get a newly jitted version that is specialized for Float64 — the type of 1.0 on all systems. Since each compiled version of the function knows what types it will be getting, it can run at C-like speed. You can sabotage this by writing and using "type-unstable" functions whose return type depends on run-time data, rather than just types, but we've taken great care not to do that in designing the core language and standard library.

Most of Julia is written in itself, then parsed, type-inferred and jitted, so bootstrapping the entire system from scratch takes some 15-20 seconds. To make it faster, we have a staged system where we parse, type-infer, and then cache a serialized version of the type-inferred AST in the file sys.ji. This file is then loaded and used to run the system when you run julia. No LLVM code or machine code is cached in sys.ji, however, so all the LLVM jitting still needs to be done every time julia starts up, which therefore takes about 2 seconds.

This 2-second startup delay is quite annoying and we have a plan for fixing it. The basic plan is to be able to compile whole Julia programs to binaries: either executables that can be run or .so/.dylib shared libraries that can be called from other programs as though they were simply shared C libraries. The startup time for a binary will be like any other C program, so the 2-second startup delay will vanish.

Addendum 1: Since November 2013, the development version of Julia no longer has a 2-second startup delay since it precompiles the standard library as binary code. The startup time is still 10x slower than Python and Ruby, so there's room for improvement, but it's pretty fast. The next step will be to allow precompilation of packages and scripts so that those can startup just as fast as Julia itself already does.

Addendum 2: Since June 2015, the development version of Julia precompiles many packages automatically, allowing them to load quickly. The next step is static compilation of entire Julia programs.

StefanKarpinski
  • 32,404
  • 10
  • 86
  • 111
  • 6
    I've seen a number of comments around the Web from the last year or so indicating that compiled executables/shared objects are the goal for Julia, but no indication of any progress. Can you offer any insight into where things stand on that? – dfreeman Mar 06 '13 at 21:26
  • 2
    A lot of progress has been made by Jameson Nash and Isaiah Norton, but it's not quite there yet. – StefanKarpinski Sep 25 '13 at 17:29
  • 26
    This functionality is now complete and merged on Julia master. Instead of taking ~1.5 seconds on my system to startup Julia, it now takes ~150 milliseconds – an impressive 10x speedup. If we can manage to accumulate another 10x speedup, which is entirely possible, Julia's startup time will be comparable to Ruby and Python. – StefanKarpinski Dec 16 '13 at 15:55
  • 1
    @StefanKrpinski, After julia itself starts up then it still takes a bit of time to load the packages I need. For example, using Julia Version 0.3.0-prerelease+3381 (2014-06-02 13:19 UTC) the shell command `julia -e "using DataFrames"` takes 21 seconds on my machine. Is there some way to address this? – G. Grothendieck Jun 04 '14 at 11:48
  • You can try creating a file called `base/userimg.jl` that does `using DataFrames` when compiling Julia. If this works, then you'll have DataFrames available as part of your system image, but this mechanism is still not terribly robust so it may or may not work. – StefanKarpinski Jun 04 '14 at 16:43
  • 5
    For reference, @G.Grothendieck, precompilation of modules is a new feature of `julia v0.4`, and greatly improves module loading times. – Maxim Sep 24 '15 at 16:03
  • Any progress in static compilation of Julia programs? PackageCompiler.jl does not seem to have been designed with that in mind. – Héliton Martins Jul 10 '21 at 14:02
48

At the moment Julia JIT compiles its entire standard library on startup. We are aware of the situation and are currently working on caching the LLVM JIT output to remedy the situation, but until then, there's no way around it (except for using the REPL).

Keno Fischer
  • 1,387
  • 12
  • 14
  • 22
    This has been implemented in the Julia nightlies and will be included in the 0.3 release. Startup time is vastly improved. – Isaiah Norton May 01 '14 at 03:17