为什么“去虚拟化”对深度学习系统很有必要

　　下面，小编想给大家介绍一下虚拟化的本质和局限性，说一说为什么追求极致性能的场景要去虚拟化?

　　追溯虚拟化

　　虚拟化可能是计算机科学史上最伟大的思想之一。对此，计算机先驱DavidWheeler有一句名言:　

　　这句话被尊为软件工程的基本定理，并被C++之父BjarneStroustrup在专著《TheC++ProgrammingLanguage》序言中引用。然而，大多数人记住了前半句，却忽略了后半句，而后半句正是本文所要讨论的。

　　“anotherlevelofindirection”描绘了“虚拟化”的精髓：通过引入一层新的抽象，隐藏与上层应用无关的细节，有选择地向上层用户暴露一些功能供他们使用，也称为底层细节对用户透明，既不损害上层应用的功能，又能享受“关注点分离”(separationofconcerns)的好处，增加易用性。

　　可说：虚拟化案例无处不在，无往而不利。

　　操作系统是硬件资源的虚拟化:计算核心被虚拟化为过程;硬件内存变成虚拟内存;存储介质被虚拟化为文件系统;网络传输通过多层协议栈被虚拟化为文件描述符，使得数据传输就像读写普通文件一样。

　　分布式存储将多个单机文件系统通过网络互联虚拟化为网络文件系统，使用户不再关心网络数据传输的细节，可以像访问本地文件一样访问其他节点的数据。

　　当然，虚拟化造就了今天伟大的云计算技术和市场，云原生如火如荼。开发者只需要基于云服务的API编程，不需要API下的物理细节，成本低，可靠性高。

　　虚拟化的成功是不可否认的。但成也萧何，败也萧何，虚拟化也有其代价。

　　虚拟化与极致性能的矛盾

　　一层一层的抽象层次逐渐降低了编程的复杂性，每一层都向上隐藏了一些东西，上层也相应地失去了一些控制能力。每次抽象后，都会引入一些对上层的不确定性，最终的结果就是性能的天花板一步步下降。

　　以Hadoop的分布式存储为例，虚拟化的结果是掩盖数据的真实存储位置，无论在哪个节点，访问界面都是一样的。然而，当将一些MapReduce的数据处理任务调度到该集群时，如果Task被调度到数据所在的节点，则不需要网络传输，如果调度到其他节点，则需要将数据读取到内存，并通过网络发送到计算所在的节点。也就是说，隐藏的数据位置信息可能被调度器用来提高系统效率。

　　随着摩尔定律的放缓，不仅在深度学习领域，在任何追求极致性能的场景中，都有强烈的需求来突破和粉碎中间的抽象层次，并将其插入最后进行协同优化。

　　舒适区虚拟化

　　虚拟化试图为上层提供一剂一劳永逸的灵丹妙药，既解决了易用性，又不损害上层应用的性能要求。但虚拟化到底好不好应该具体问题具体分析，那么如何判断虚拟化是否合适呢?

　　试着在此抛出一个用于判断是否有必要引入一层抽象(虚拟化)的量化指标，供参考。每次引入虚拟化，就会向上层隐藏一些东西，向上提供的服务延迟就会导致不确定性(以分布式存储为例，有的数据近，有的数据远;以分布式GPU资源池为例，有的近，有的远)，服务响应延迟有波动范围，即[min,max]，延迟越小越好。　　

 

　　如果上层某个应用需要保证的最低延迟仍然大于max，那么这个虚拟化对这个应用没有损害，可以大胆引入这个虚拟化技术(即上图的C区域)。

　　如果上层某个应用需要保证的最低延迟介于min和max之间，那么引入这个虚拟化对这个应用是有害的。敲掉这个虚拟化，可以保证这个应用的延迟需求以min值满足(也就是上图的B区)。

　　如果上层某个应用需要保证的最低延迟小于min，即使敲掉当前层的虚拟化，也不能满足这个应用，需要继续向下敲击，共同优化，直到延迟得到满足(即上图的A区)。

　　鱼和熊掌兼得?

　　如上所述，虚拟化的基本思路是通过隐藏细节为上层应用提供假象，降低上层应用使用底层资源的复杂性。然而，有时隐藏的信息会阻碍上层应用程序挖掘的性能。两全其美有什么办法吗?

　　在《计算机系统结构的黄金时代》一文中，DavidPatterson开出的药方是从算法到硬件直接打通，结合算法和硬件的特点进行定制。DSL和DSA的定制表现，一方面是设计领域的特定语言，方便编程，另一方面是面向领域应用设计领域的特定架构，挖掘极致效率。

　　DavidPatterson的处方既不是在现有方案中插入新的抽象层次，也不是完全不需要中间抽象，而是将原有的抽象层次全部打碎重建，这是基于对算法和硬件特性的充分挖掘。这里解这里有两个关键点:软硬件协同设计(分工)和编译技术。

　　一方面，这里的思维和虚拟化的区别在于，不是向上层应用隐藏什么，而是强调向上层暴露什么，或者向上层转移什么职责。

　　另一方面，我们并不期待只要提供一层API抽象就能打败世界，而是对算法到硬件映射的复杂性有足够的了解。这种映射不仅包括与任务相关但与硬件无关的问题，还包括与硬件相关的问题，本质上相当于众所周知的编译技术。

　　谈到这里，想到另一个去虚拟化的绝佳例子，就是软件定义网络(Softwaredefinednetwork，SDN)。对于同一套硬件基础设施，交换机的最佳转发规则是不同的。SDN的思路是使交换机的转发规则可以编程。对于每个不同的业务负载，通过静态分析获得最佳的转发规则或策略(controlplane)，并根据这个规则对交换机进行编程。转发数据时，交换机只需要按照编程规则执行(dataplane)。

　　在SDN的例子中，交换机将部分职责转移给软件，软件根据不同的业务负载生成不同的路由规则(策略)，这是SDN平衡灵活性和终极性能的关键。

　　在OneFlow解决分布式深度学习问题时，也是类似的想法。它不是通过引入额外的抽象层次来实现的，而是分为控制平面和数据平面。在控制平面上，编译器根据特定深度学习模型的任务负载和底层硬件拓扑生成配置最佳的执行计划(executionplan)。这个plan不是一劳永逸的。它需要上层模型和底层硬件的知识。一旦模型或硬件拓扑发生变化，plan就会发生变化。但编译器生成plan的机制可以认为是不变的，也是整个系统的精髓。

  　　>>>>>>点击进入云计算专题