Julia官宣：为机器学习构建一种语言和编译器

自从Julia团队提出“需要一流的语言、编译器和机器学习（ML）生态系统”以来，该领域呈现出一些有趣的发展趋势。

在现有的系统如TensorFlow或PyTorch中，不仅权衡问题（tradeoff）没有得到解决，而且它们的“边界”比以往任何时候都更加明显，因为这两个框架都包含不同的“静态图（static graph）”和“动态图机制（eager execution）”接口。

在目前的框架还不够完善的情况下，一些激动人心的新项目如雨后春笋般出现，完全省去了图（graph），并将可微分编程（differentiable programming）引入主流：

• Theano团队的Myia将Python的一个子集区分并编译为高性能GPU代码；
• Swift for TensorFlow扩展了Swift，可以将兼容的函数编译为TensorFlow图；
• Flux生态系统正在使用许多聚焦于ML的工具扩展Julia的编译器，包括gradients、CUDA内核编译、自动批处理以及对TPU等新硬件的支持。

所有这些项目都拥有巨大的潜力，但团队认为Julia更有优势。

本文探讨了团队如何使用Julia重新思考ML工具，并对现代ML工具需要做的工作提供一些见解。

Flux加持，Julia更适于机器学习

我们需要一种语言来编写可微算法，而Flux使得Julia成为了这样的一门语言。 Julia专为数学和数值计算而设计，非常适合表达ML算法。同时，它在编译器中融合了现代设计和新思想，更容易满足最前沿ML的高性能需求。

在典型的框架中，所有的内容需要用几十万行的C++代码来堆砌，而Flux仅仅是几千行简单的Julia代码。只需要一个用于gradient的包（Zygote.jl），一个用于支持GPU的包（CuArrays.jl），“撒”上一些轻便的功能，“烘烤”十五分钟，便可弹出一个功能齐全的ML堆栈。

与其他下一代ML系统一样，Flux致力于提供较为直观的界面，并对任何类型的图形构建或性能注释采取强硬措施。

Julia支持Flux所有特性，包括控制流、数据结构和宏等。用户可以在Jupyter notebook上交互式编程，并将高性能数字与便捷的绘图、可视化做结合。

但Julia也想获取传统“静态图”框架的优势——零开销的“源到源”AD、操作符融合、多GPU/分布式训练和单二进制（single-binary ）部署。

这该如何实现呢？需要直接从Julia编写的语法中提取和分析“静态图”，这实际上是编译器完全正常的工作。从某些角度来看，大多数ML系统问题都是经过深入研究的标准编译器问题。使用编译语言就足以解决许多问题，扩展编译器是解决更多问题的最佳方法。

在此只介绍这个领域当前工作中的一个示例—即获取梯度、编译GPU和TPU以及自动批处理。

采用“梯度”

我们突破了反向模式微分（reverse-mode differentiation）的极限，将其视为一个语言级别的问题。现有框架通过跟踪（tracing）来实现这一点。引入了一种新的张量类型，它记录了所执行的所有基本数学操作，产生了一个图形（或符号表达式），其中删除了主机语言的控制流和数据结构。

然而，这带来了一个困难的权衡：我们要么接受解释器的开销（eager execution），要么冻结用户控制流，并限制可以构建的模型的种类（static graphs）。

相反，如果图（graph）是Julia自身的语法呢？

将这个想法发挥到极致，我们构建了Zygote，它直接在SSA形式的IR上工作，并支持控制流，递归，数据结构和宏等语言功能。

然后，我们可以通过LLVM之类的编译器生成的SSA形式的伴随代码，并将传统编译器优化的所有好处应用于我们的前向和反向传递。

此外，这种方法为扩展该编译器基础结构提供了机会，可以使用更高级和特定于域的优化，例如内核融合和编译到TPU等加速器。 Swift for TensorFlow和Myia开发人员在源到源AD技术的复兴中正在探索类似的方法。

Julia用于此任务的一个关键优势是它可用于实现基本数值库，如微分方程求解器或优化库; 这巧妙地解决了ML社区日益增长的需求，研究人员通过高性能代码（如光线跟踪器和物理引擎）反向传播，但gradient仍必须在C ++中手动实现。

相比之下，由于Julia的实施是用Julia编写的，所以从ODE到金融定价模型（ financial pricing model）的所有内容都可以轻松地进行区分。 将这些强大的工具带入模型是深度学习真正成为可微分编程的地方。

为GPU编写Julia

GPU编程是现代ML的重要组成部分。框架在内部提供内核，但是用户只能看到有限的一组数学运算，不能直接对GPU进行编程。 相比之下，Julia中的GPU编程一直是一流的CUDA内核（可以很好地编写并从脚本或笔记本中运行）。

一个简单的向量加法核看起来与CUDA C等价。

function kernel_vadd(a, b, c)
    i = (blockIdx().x-1) * blockDim().x + threadIdx().x
    c[i] = a[i] + b[i]
    return
end

但是，Julia的类型特化（type specialization）可以在GPU上实现一组强大的附加抽象。例如，上面的代码并不局限于密集的浮点数组，而是可以给出稀疏的复数数组。

Julia on TPUs

谷歌最近开放了他们的云TPU使用的XLA IR，使得ML以外的其他框架和用户都可以利用这个重量级硬件。 XLA功能强大但有限：它无法运行Python解释器，当然也没有良好的性能。 然后框架最终处于与gradient相似的位置，只能使用程序跟踪来撬开Python，最终得到一个快速但更有限的ML语言。

而我们只需要从已经编写的Julia程序中提取“静态图”并将其直接编译到XLA，从而允许Julia本身在TPU上运行。（实际上，这只是Julia通常编译过程的一个简单扩展，该编译过程从程序中提取尽可能大的“静态子图”，然后将它们发送到LLVM。）

这使我们可以充分利用Julia语言的表现力，包括 控制流，递归，多调度，高阶函数，强大的数据结构和抽象，自定义数字类型，以及现有的包，如微分方程求解器和线性代数例程。所有这些工作都是在TPU中使用高性能收缩阵列引擎的同时进行的。

自动Batching

为了从这些加速器中获得最大收益，批处理程序通常会同时将前向和反向传递应用于多个训练示例。在一些简单的情况下，比如卷积网络，通过将10张图像按照额外的批处理维度连接起来来处理这个问题是很简单的。但是在处理各种结构的输入（如树或图）时，这项任务变得更加困难。

大多数研究人员通过手工批处理代码来解决这一问题。针对不同的框架（DyNet、TensorFlow Fold）提出了不同的解决方案，它们在可能的情况下尝试将一些高级操作批处理在一起，但是这些操作通常要么有自己的可用性问题，要么无法实现手工编写的代码的性能。

我们认为这个问题与单程序多数据（SPMD）编程的问题是相同的，后者已经被语言和编译器社区研究了几十年，并且在最近的批处理方法（如matchbox）中变得很明显。 实际上，它与GPU内部使用的并行模型非常相似，并且已经实现为CPU的SIMD单元的编译器变换。

从这项工作中获得灵感，我们正在Julia中实现相同的转换，为标量SIMD单元和模型级批处理提供SPMD编程。这使我们能够实现在单个示例上编写简单代码的理想，同时仍然在现代硬件上获得最佳性能。

总结

我们认为，机器学习的未来取决于语言和编译技术，特别是扩展新的或现有的语言，以满足ML研究的高要求。这不仅对ML社区有好处，对一般的数值编程也有好处；能够很好地支持差异化、向量化和外来硬件的语言将足以推动科学的许多进步。

原文链接：

https://julialang.org/blog/2018/12/ml-language-compiler