茱莉亚每次都编写脚本?

Julia语言每次编译脚本,我们不能用julia编译二进制文件吗? 我尝试了一个带有println函数的小型helloworld脚本,它让茱莉亚花了2,3秒的时间来显示输出! 如果我们可以做二进制代码而不是每次编译会更好

更新:因为我问了这个问题,Julia有了一些变化。 虽然我不再关注julia的更新,但是因为我已经提出了这个问题,而且如果您正在寻找类似的东西,请查看以下茱莉亚人的回答和评论。

此外,它很好地知道,现在需要大约150毫秒加载一个脚本。

目前,Julia JIT在启动时编译了整个标准库。 我们知道这种情况,目前正在cachingLLVM JIT输出来纠正这种情况,但在此之前,除了使用REPL外,没有办法解决这个问题。

基诺的回答很有用,但是也许我可以详细介绍一下正在发生的事情以及我们计划要做的事情。

目前只有一个LLVM JIT模式:

  • 对于一些简单的顶级语句,有一个非常简单的解释器。
  • 所有其他代码在执行之前被分解成机器代码。 该代码使用运行时types的代码被积极地专门化,通过使用dynamictypes推断在程序中传播。

即使在代码没有types注释的情况下,Julia也能获得良好的性能:如果调用f(1)将得到专用于Int64代码 – 64位系统上的1types; 如果你调用f(1.0)你会得到一个专门用于Float64的新版本 – 所有系统上的1.0 。 由于该函数的每个编译版本都知道它将获得什么types,因此它可以以类似C的速度运行。 你可以通过编写和使用返回types取决于运行时数据而不是types的“types不稳定”函数来破坏这个,但是我们在devise核心语言和标准库时非常小心,不要这样做。

Julia大部分是自己编写的,然后被parsing,types推断和jitted,所以从头开始整个系统需要15-20秒。 为了使速度更快,我们有一个分阶段的系统,我们在文件sys.jiparsing,types推断,然后cachingtypes推断的AST的序列化版本。 这个文件然后被加载并用于在运行julia时运行系统。 但是,没有LLVM代码或机器代码在sys.ji被caching,所以每次启动julia时,所有的LLVM jitting仍然需要完成,因此大约需要2秒。

这个2秒的启动延迟是非常烦人的,我们有一个解决它的计划。 基本计划是能够将整个Julia程序编译为二进制文件:可以运行的可执行文件或可以从其他程序调用的.so / .dylib共享库,就像它们只是共享C库一样。 二进制启动时间就像任何其他的C程序,所以2秒的启动延迟将消失。

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

附录2:自2015年6月以来,Julia开发版自动预编译了许多软件包,使其能够快速加载。 下一步是整个Julia程序的静态编译。