编者按JohnHennessy和DavidPatterson是建筑领域的权威。他们在2017年图灵奖获奖演讲中表示，未来十年将是建筑的黄金时代。当CPU性能达到瓶颈时，就需要为特定领域定制专用处理器，也就是目前大家熟悉的DSA（DomainSpecificArchitecture）。随后，撰写了一篇专业论文来详细论证此事（参见参考资料）。那么，逆向思考，是否有一款足够“通用”的处理器，既能“包治百病”，又能按照摩尔定律快速提升性能，尽可能满足众多客户当前和未来的需求？需要？1.从历史中汲取灵感1.1RISC体系结构的兴起20世纪70年代到80年代初期，由于流水线等技术的应用，CPU速度提升非常快，而内存容量和速度则相对落后。变长指令格式可以提供更高的代码密度，同样大小的内存空间可以装载更多的指令，从而间接提高运行速度。而且此时的编译器能力比较有限，编译器很难合理利用CPU寄存器，也无法针对微架构的具体特性进行深入的性能优化，这使得CPU设计人员更喜欢直接内存-内存和寄存器内存式指令执行模式。这些是典型的复杂指令集(CISC)特性。这一时期几乎所有的处理器设计都按照CISC路线发展，并走向了一个极端：不断加入新的指令，试图在指令集架构上为高级编程语言提供更直接有效的支持水平，等等。这种发展路线使得硬件复杂度迅速飙升，研发成本不断增加，研发周期变长，编译器也很难利用这个日益复杂的指令集。随后，RISC体系结构应运而生。IBM的JohnCocke认为，更加精简和清晰的指令集设计将有助于降低硬件开发的难度和成本，同时也有助于编译器优化代码。当时在伯克利任教的DavidPatterson和他的学生的成果在1983年国际固态电路会议(ISSCC)上发表。虽然制造工艺老旧，主频比DEC、摩托罗拉、英特尔等同期竞争对手制造的处理器慢了将近一半，晶体管数量也只是零头，但更干净的新设计辅助了其他工具，例如编译器。下一步是打败行业内的所有竞争对手。RISC架构处理器提倡简化指令集设计、固定指令长度、统一指令编码格式、加速通用指令。这在当时是有悖于CISC主流设计风格的。但RISC阵营的DavidPatterson手上已经有了成功的芯片和硬件测试结果，1983年的ISSCC大会上聚集了数位与DavidPatterson持相同观点的支持者，RISC流派开始逐渐占据上风。CISCISA呈现“第28定律”的特点：80%的指令很少使用，只有20%的指令经常使用。RISC对20%的指令集进行了重组、优化和加速，其余80%的指令都是通过这20%的简单指令组合完成的，性能高于CISC。我们无意介绍CISC和RISC之间的历史恩怨。之后的情况是：两个概念的ISA也相互学习，相互融合，逐渐形成了x86、ARM和RISC-v三巨头竞争的现状。1.2从微服务到云计算服务分层最开始，所有的应用都是单块的“巨型”应用系统。企业应用系统通常由三个主要部分组成：客户端用户界面、数据库和服务器端应用系统。渐渐地，尤其是越来越多的应用系统被部署到云端，软件的变化受到了很大的限制：应用系统一小部分的变化也需要更新整个单体应用系统。重建和部署；单体应用程序逐渐难以维护良好的模块化结构。当扩展系统时，必须扩展整个应用系统，而不仅仅是系统中需要更多资源的部分。这些问题催生了微服务架构风格：将应用程序构建为一组小型服务。除了能够独立部署和扩展这些服务之外，每个服务还提供了可靠的模块边界，甚至允许使用不同的编程语言编写不同的服务。此外，这些服务可以由不同的团队管理。微服务方式将一个完整的应用系统拆分成用户关心的应用核心本身，以及其他辅助服务，如：基础设施服务，如VM、容器、网络、存储、安全等；软件层服务，如负载均衡、数据库、文件系统、访问控制、消息队列、物联网接入平台等。“万物皆服务”，从微服务的角度来看，云计算是由不同服务组成的分层服务体系：每一层都是一个服务族，然后不同层次的服务族组成了整个云计算服务体系，也就是我们熟悉的云计算三层服务IaaS、PaaS和SaaS。更详细的软件堆栈如上图所示。所有来自非云系统的“服务”堆栈都需要由用户自己拥有和维护。经过IaaS、CaaS、PaaS、FaaS，最后是SaaS，一切都由提供商运维。.从左到右的过程是“服务”堆栈的较低层不断被云运营商接管的过程。这也是“20-80法则”的一个鲜明案例：80%的任务由云运营商负责，20%的任务由用户负责；经销商负责的部分只占价值的20%。1.3结语：“80/20法则”生效。80/20法则（又称80/20法则、关键少数法则、帕累托法则）起源于洛桑大学的意大利经济学家维弗雷多·帕累托（VifredoPareto）的关注。对于80/20的联系，他在文章《政治经济学》中说明了这个现象，例如：意大利大约80%的土地为20%的人口所有，80%的豌豆产量来自20%的人。植物等。这一原则在当今的企业管理中得到广泛应用。回到计算机领域，80/20法则也是一个普遍法则：CISC指令过于冗余，只有20%的指令经常被使用，而另外80%的指令很少被使用。因此，RISC只保留了20%的通用简单指令。一个应用系统完全不同的只有应用的核心部分（约占20%），其他如网络访问、存储磁盘、文件系统、数据库、负载均衡、消息队列等（约占80%）%)其实对用户来说是比较无所谓的，是很多应用系统都会用到的组件。云计算是由许多服务组成的服务分层系统。随着不断的抽象和封装，云运营商不断接管众多服务层的80%以上，用户只需关注20%的应用和功能。2.分析各类处理引擎2.1从单位计算复杂度的角度指令是软件和硬件之间的媒介，指令的复杂度（单位计算密度）决定了系统中软硬件的解耦程度。根据指令的复杂程度，典型的处理器引擎大致分为CPU、协处理器、GPU、FPGA、DSA、ASIC。如果任务运行在CPU上，则定义为软件运行；如果任务运行在协处理器、GPU、FPGA、DSA或ASIC上，则定义为硬件加速运行。鱼和熊掌不可兼得，指令复杂性和编程灵活性是两个相反的特性：指令越简单，编程灵活性越高，所以我们说软件具有更高的灵活性；指令越复杂，性能越高。数值越高，限制越多，只能用于特定领域或场景的应用，其软件的灵活性越差。2.2从处理器引擎类型的数量来看，处理器引擎主要有六种类型。根据不同类型的处理引擎的数量，形成一个金字塔形的处理器层次结构（Hierarchy）：CPU，也就是最通用的处理器引擎，CPU指令是最基本的，因此具有最好的灵活性。在这个级别上，只有处理器形式的CPU。协处理器是基于CPU扩展指令集的运行引擎，如ARM的NEON、Intel的AVX、AMX扩展指令集及相应的协处理器。GPU本质上是很多CPU小核的并行化，所以NP、Graphcore的IPU等都是和GPU同级别的处理器类型。FPGA在架构上可以用来实现定制的ASIC引擎，但由于具备硬件可编程能力，可以切换到其他ASIC引擎，具有一定的灵活可编程能力。DSA，是一种接近ASIC的设计，但具有一定的可编程性。覆盖的领域和场景比ASIC更大，但仍然有太多领域需要特定的DSA来覆盖。ASIC，是一种完全不可编程的定制处理引擎，理论上是最复杂的“指令”和最高的性能效率。由于覆盖的场景很小，需要大量的ASIC处理引擎来覆盖各种场景。为了更简洁地理解常见的六种处理引擎的定位和作用，我们将它们两两组合，定义三类处理引擎：基础层任务。基础设施层的任务比较明确，适合DSA和ASIC处理引擎处理。应用层加速了一些任务。基础设施层由Vendor提供，而应用层则供用户应用。用户的应用多种多样，因此应用层的加速也需要一定的灵活性。这样看来，GPU和FPGA是比较适合的。应用层不可加速的部分。主要是一些通用的处理，比如控制和一些细粒度的计算。协处理器实际上是CPU的一部分。因此，CPU（包括协处理器）可以负责正常的控制处理以及一些计算任务。2.3从处理器覆盖场景来看，“尺寸长，尺寸短”，每一种处理器都有自己的优缺点：CPU和协处理器，最好的灵活可靠的Programmable，可以用于任何领域和场景。但是性能是最低的。GPU和FPGA，更好的软件或硬件编程能力，覆盖更多领域和场景，但性能并不完美。DSA和ASIC性能最好。但DSA可编程性差，可以覆盖特定领域；ASIC完全不可编程，只能覆盖特定领域的特定场景。“专业的人做专业的事”，通过CPU+Coprocessor+GPU+FPGA+DSA+ASIC等各类处理引擎的混合架构，可以兼顾性能和灵活性：从宏观上看，大部分计算都是donethrough加速完成，性能有了明显提升；从用户应用程序的角度来看，应用程序仍然运行在CPU上，与以前没有任何变化，仍然由它自己“控制一切”。3、设计理想的宏处理器由于80/20定律，在整个系统栈中，用户关心的20%的相对不确定的任务仍然需要通过软件编程来实现；这些比较明确的任务存在于每个用户应用系统中，占80%，适合通过硬件加速来实现。3.1目前的处理器芯片基本上都是“单兵作战”。处理器芯片由各种处理器引擎组成。在云计算数据中心中，主要有三种同构处理器芯片。分析如下表所示。这里我们分析一下由三种引擎组成的同构处理器：CPU是数据中心中最常见的处理器，但是由于在性能上采用了这样的优化手段，力求提升整个服务器和数据中心的计算能力。GPU在HPC、图形等领域具有很大优势。近年来，随着AI的兴起，同时AI算法也在快速更新，这使得GPU成为了最适合AI的处理器，GPU大放异彩。DSA的主要领域也在AI。第一个经典的DSA处理器是GoogleTPU。目前，受限于AI算法的快速迭代，还没有大规模落地DSA处理器的案例。即使像谷歌这样强大，可以从芯片、框架到服务统筹优化，严格来说，TPU依然没有大规模落地。3.2CPU+xPU的异构处理还是不够。另外，对于单处理器引擎来说，性能和灵活性是一对矛盾体。如果只考虑同构计算，很难做到方方面面。CPU+GPU/FPGA/DSA的架构可以通过板级集成或者片内集成等多种异构方式来实现，但是仍然存在一些问题。传统异构计算的架构以CPU为中心。这个架构本身就有一些问题：IO路径。CPU+xPU架构的IO路径太长，IO成为整个算力的瓶颈。输入和输出损失。CPU+xPU加速在CPU和xPU之间增加了额外的数据输入和输出损失。系统复杂性。异构计算是显式的。CPU端软件知道自己在加速，CPU端需要处理与加速器端的数据和消息交互。仍然受限于硬件加速处理器的特性，异构计算仍然无法兼顾性能和灵活性：GPU异构加速架构。虽然GPU具有非常好的弹性加速能力，涵盖的领域也非常多，但是受限于GPU的性能效率，无法做到极致的性能加速。FPGA异构加速架构。FPGA可以是硬件可编程的，可以通过FaaS（这里的FaaS是FPGAasaService）机制实现弹性加速。FPGA的问题在于成本和功耗太高，以及设计规模的限制，只能做极少数的小型加速引擎。DSA异构加速架构。DSA可以实现极致的性能加速能力，但仅限于特定领域，因此使用范围有限。3.3Teamwork实现通用超异构处理器。随着CPU、GPU等常用处理引擎的成熟，以及技术和Chiplet技术的进步，我们可以在单个芯片中集成更多的处理器引擎，从而在单个芯片中超越两个形态学处理引擎成为可能，超异构处理单元（HPU）逐渐成为现实。如上图，有点像塔防游戏，我们设置了三层“防御”，然后待处理的任务就像是“需要消灭的敌人”（假设有100个单位待处理任务）：第一层“防御”，DSA+ASIC可覆盖80%任务（即80个任务）性能加速，可快速“淘汰”。但受覆盖区域和场景限制，会有20%（即20个任务）的“漏网之鱼”；第二层“防御”，GPU+FPGA可以覆盖接下来80%的任务，性能依旧强劲。可以处理剩余任务的80%（即16个任务）。但是还是有一些“顽固的敌人”不太适合硬件加速（剩下的4个任务）。第三层“防御”，CPU和协处理器作为“定海神针”，可以覆盖所有场景。他们负责“消灭”最后一个“顽敌”（即处理最后4个任务）。没有硬件加速，100个任务全部需要CPU处理；有了加速，CPU只需要处理4个任务。当整个设计足够平衡时（各种加速引擎不成为性能瓶颈），我们可以反过来说通过超异构处理器HPU可以实现25倍的性能提升。受到宏观超大规模数据中心的影响，同时也受到软硬件深度融合的支撑，我们可以在这里继续优化“28定律”，假设我们可以增加可处理任务的比例不同级别的处理引擎再增加10%。这样：DSA+ASIC完成90个任务，GPU+FPGA完成9个任务，最后CPU只需要完成1个任务。或者反过来，通过软硬件融合，实现通用超异构处理器GP-HPU，实现100倍的性能提升。3.4超越传统SOC通用超异构处理器GP-HPU可以看作是一个SOC，但它与传统SOC有很大区别。如果不认识到这些差异，就不可能理解HPU的性质。下表显示了一些典型的差异和比较。
