Julia 每次运行都编译脚本么

关于这个问题Julia的作者有比较明确的回答。详细见：https://stackoverflow.com/questions/10268028/julia-compiles-the-script-every-time/10711762#10711762

这里给出解答的中文翻译：

Keno Fischer：

目前Julia JIT在启动时编译它的整个标准库。我们知道这种情况，目前正在缓存LLVM JIT编译以纠正这种情况，但在此之前，没有办法解决这个问题（除了使用REPL）。

StefanKarpinski：

Keno的回答很准确，也许我可以更详细地说明发生了什么，以及我们打算怎么做。

   Julia 目前只有LLVM JIT模式：

（1）对于一些简单的顶级语句，有一个非常简单的解释器。

（2）在执行之前，所有其他代码都被jit到机器代码中。Julia对应用代码中值的运行时类型进行了积极的专门优化，程序中的值使用动态类型推断，然后进行传递。

       这就是Julia在没有类型注释的情况下也能获得良好性能的原因：如果调用函数f(1)，则会得到专门用于Int64的代码（64位系统上的1类型）；如果调用f函数(1.0），则会得到专门用于Float64的新jitted版本代码（所有系统上的1.0类型）。由于该函数的每个编译版本都知道它将获得哪些类型，因此它可以以类似于C的速度运行。您可以通过编写和使用“类型不稳定”函数来破坏这种情况，这些函数的返回类型依赖于运行时数据，而不仅仅是类型，但是我们在设计核心语言和标准库时非常注意，尽量不要这样做。

      Julia的大部分内容都是自己编写的，然后经过解析、隐式类型(type-inferred)和运行时编译（jitted），因此从头启动整个系统需要15-20秒。为了加快速度，我们有一个分阶段的系统，在该系统中，我们解析、类型推断（type-infer），然后在文件sys.ji中缓存类型推断 AST的序列化版本。然后加载此文件，并在运行julia时用于运行系统。但是，sys.ji中没有缓存LLVM代码或机器代码，因此每次julia启动时仍需要执行所有LLVM 运行时编译代码，因此大约需要2秒。

      这2秒启动延迟是相当恼人的，我们有一个计划来修复它。基本计划是能够将整个Julia程序编译成二进制文件：既可以运行可执行文件，也可以从其他程序调用.so/.dylib共享库，就好像它们只是共享的C库一样。二进制文件的启动时间与任何其他C程序一样，因此2秒的启动延迟将消失。

附录1：自2013年11月以来，Julia的开发版本不再有2秒的启动延迟，因为它将标准库预编译为二进制代码。启动时间仍然比Python和Ruby慢10倍，因此还有改进的空间，但速度相当快了。下一步将是允许预编译包和脚本，以便这些包和脚本能够像Julia本身一样快速启动

附录2：自2015年6月以来，Julia的开发版本自动预编译了许多包，允许它们快速加载。下一步是静态编译整个Julia程序。