|Julia 1.6 有哪些使人眼前一亮的光点？

文章图片

文章图片

Julia 1.6 很可能会成为 Julia 的下一个长期支持（LTS）版本。因此，我们投入了更多时间来开发这个版本，确保未来健康生态系统所需的各种特性能够在该版本中实现。此外，我们还使用所有已注册的开源软件包对这个版本进行了回归测试，并跟踪和解决了相关问题。在 Julia 1.6 经过实地测试后，大约 1.7 发行版进入稳定状态时，我们将最终决定 1.6 是否将成为新的 LTS 版本。
一：并行预编译
执行一个模块中所有语句的操作通常涉及大量代码的编译，因此 Julia 创建了模块的预编译缓存以减少这部分时间开销。在 1.6 中，这个包预编译操作的速度更快了，并且发生在退出 pkg>模式之前。之前预编译仅作为单个处理的序列，在第一次 using/import 一个软件包时，在线性代码加载过程中需要时一对一地预编译依赖项。
在 1.6 中， pkg>模式获得了高度并行化的预编译操作，该操作在程序包动作后自动调用，以使活动环境随时可以加载。
二：编译时间百分比
这个小更改应该能帮助新手理解 Julia 的一个怪癖：计时宏 @time 和它的冗长伙伴 @timev 现在会说明报告的时间中有多少是花在了编译上
考虑到 Julia 的即时（JIT）/ 超前（JAOT）编译机制，第一次运行代码时，编译开销通常非常可观，而后续调用中可以看到很大的速度改进。这个更改会强调这种行为，可以作为一种提示，同时帮助消除不必要的编译工作（例如过度针对性的代码）。
三：消除不必要的重编译
Julia 最强大的特性之一就是它的可扩展性：你可以向先前定义的函数添加新方法，并对新类型使用先前定义的方法，有时，这些新实体会迫使 Julia 重编译代码以解决分派中的更改。这里分两个步骤：第一， “过时的”代码被无效化，将其标记为不适合使用；第二，根据需要将新的方法和类型考虑在内，再次从头开始编译代码。
Julia 的早期版本有些保守，在某些情况下，分派中没有实际更改，却也会让旧代码无效化。此外，在许多地方， Julia 及其标准库的编写方式都会破坏 Julia 的类型推断。编译器有时仅因为新方法“可能”被应用就被迫让代码无效化，于是关于类型的任何不确定性都会放大无效化的风险和频率。在 Julia 的旧版本中，这些影响加在一起让无效化频频出现：只是加载某些程序包就会导致多达 10% 的 Julia 预编译代码被无效化。重编译的延迟有时会让交互会话出现卡顿。当 Julia 的程序包加载代码中出现无效化时，它也延迟了下一个包的加载，那么当 SomePkg 依赖其他包时，这就会延长 using SomePkg 的等待时间。
四：减少编译器延迟
【|Julia 1.6 有哪些使人眼前一亮的光点？】除了让我们的库代码对编译器更友好之外，我们也在继续尝试加快编译器本身的速度。这仍然是我们面临的主要技术挑战之一。在这一版本中没有什么重大突破，但是我们确实做了一些适度的改进，对方法表数据结构做了优化。
五：帮助优化包延迟的工具链
Julia 1.6 与 SnoopCompile v2.2.0 或更高版本共同提供了用于编译器自省的新工具，尤其是（但不仅限于）针对类型推断的用途，开发人员可以使用新工具来分析类型推断，并确定特定的包实现选项如何与编译时交互。早期采用者已使用这些工具降低了首次使用的延迟，幅度从百分之几到大部分延迟不等。
六：二进制加载加速
为包提供可靠的可移植二进制文件是所有包环境都必须面对的一项挑战，尽管 Julia的策略一直是将可靠性和可重现性放在所有问题的首位，但之前这一选择是有不小代价的。我们针对可靠性和可重现性的解决方案是完全隔离已安装的二进制文件，并使用 BinaryBuilder.jl 框架来交叉编译它们。从 BinaryBuilder.jl 构建的库往往通过所谓的 JLL 包来使用，这个包提供了一个标准化 API ， Julia 包可以用它来访问给定的二进制文件。在过去， Julia 包会盲目地 dlopen() 库并加载库搜索路径中的任何库，导致加载时间暴涨，相比之下新方法的加载时间有了显著缩短。举个例子，在 Julia 1.4 中，加载 GTK+3 堆栈需要 7 秒钟，而以前在同一机器上约需 500 毫秒。经过数月的艰苦努力和仔细调查，我们很高兴地报告，在同一机器上使用 Julia v1.6 时，同一库堆栈现在只需不到 200 毫秒的加载时间。