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

原文发布于微信公众号 - 新智元(AI_era)

原文发表时间:2018-12-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券