如何评价陈天奇团队新开源的TVM？ 第1页

从去年nnvm推出之后，非常感谢在zhihu和 @王健飞 上有一些讨论 如何评价陈天奇的模块化深度学习系统NNVM？ ，关于nnvm剩下的瓶颈。这个讨论本身加上早期的nnvm编译尝试，让我意识到了可以支持快速调优底层op的重要性。在接下来的八个多月里面我们不断迭代完成了TVM。

TVM尝试从更高的抽象层次上总结深度学习op的手工优化经验，用来使得用户可以快速地以自动或者半自动的方法探索高效的op实现空间。

TVM和已有的解决方案不同，以XLA作为例子，TVM走了和目前的XLA比更加激进的技术路线，tvm可以用来使得实现XLA需要的功能更加容易 ：已有的解决方案本身基于高级图表示的规则变换，可以产生一些图级别的组合op优化，如conv-bn fusion，但是依然要依赖于手写规则来达到从图的表示到代码这一步。图的op表示到代码本身可以选择的东西太多，如何做线程，如何利用shared memory，而大部分没有在图语言里面得到刻画，导致难以自动化。 这样下去深度学习系统的瓶颈必然从op实现的复杂度变成了实现graph compiler中模式生成规则的复杂度。走这个方向需要非常大的工程团队的支持，而我们希望采用更少的人力达到同样甚至更好的效果。

我们采取了风险更大但是回报也更大的长远技术路线。简单地说，TVM通过把图到op生成规则这一步进一步抽象化，把生成规则本身分成各个操作原语，在需要的时候加以组合。基于tvm我们可以快速地组合出不同的schedule方案。

这个想法并不新颖，正如其它回答中提到的Halide，或者polyhedra method都是尝试去做这件事情。想法虽然美好，但是自动代码生成这条路线必须要生成代码效率到达手写的80%-90%效率以上，才会有实际使用的价值。一旦到达了80%到90%的效率以上，通过fusion，layout的一些高级联合优化就可以弥补这一个gap来得到比直接组合手写代码更好的效果。

但是这也正是这个问题最困难的地方，我们需要能使得自动或者半自动生成的代码达到手写代码的效果。在TVM之前，已有的解决方案都还没有解决这个问题。我知道的最好的GPU自动生成代码大概可以到Cublas的50%的运行效率，而大部分的已有方案只是针对单线程cpu有比较好的效果。

当然已有的解决方案有不少值得参考的地方。比如polyhedra method本身非常精辟地把程序优化的大部分问题总结为针对整数集的分析。Halide里面的schedule和declaration分离的思想等。这些思想都非常强地影响了TVM的设计

这本身是一个很有趣的科研问题，dmlc的的初衷就是去解决这样新的问题，发布新的解决方案。TVM在很大程度上解决了这个问题。要解决它，需要做到两点：设计足够大的schedule空间，使得它可以囊括包括cpu和gpu在内可以做到的手写优化，设计足够强大的搜索算法。之前的方法之所以没有图片，难点在于需要足够大的空间。

所有的抽象总是有缺陷的，所以死抱一个固定的抽象肯定不能解决所有的问题。但是可以被写出来的手工优化基本上也是可以被抽象的。过去的几个月我们就是沿着这样的思路，不断地去总结手工优化的经验加以抽象到TVM中。虽然我们不敢保证TVM包含所有可能的手工优化，但是我基本上cover了我知识范围里面可以涉及到的东西（使得TVM至少比我知道的多）。随着TVM的演化，会有更多的这样的手工优化经验可以被加入进来。这也真是需要HPC机器学习和编译等各方面人才一起合力的结果。

到目前为止，我们基本可以确定TVM目前提供的schedule空间在cpu上可以做到90%，相似或者超过一些手写优化库效果的方案，在gpu上几本可以做到达到或者超过手写cuda的方案，但是和手写assembly在一些情况还有80%的差距（主要来源于gpu的寄存器分配比较困难）。TVM本身也意识到的手写优化的重要性，会在允许在各个级别混用手写优化的代码， 来弥补剩下这一平衡。

这是一个非常激动的前沿课题，基于这个项目本身还会有不少有趣的研究方向，我们在很多地方已经可以看到非常好的效果。所以我们非常希望对于机器学习，hpc，编译原理，硬件加速 有兴趣的同学一起加入进来，一起来推动这个项目。而因为我们目前到达的效果本身，TVM已经可以被使用于实际的应用场景中了。

最后有一些细节上面的东西，TVM本身的设计中是非常注重开发效率和可扩展性。TVM直接提供了非常好用的python和真机调试框架，可以不依赖于上层框架直接基于python开发调试。这一点使得tvm在调试开发和效率迭代上面比起已有的方案有比较大的优势。未来我们也会放出一些样例教程，让大家都可以开发高效的代码