软硬件共同定义:超异构开放生态
去年的时候,抛砖引玉的写了一篇“硬件定义软件?还是软件定义硬件?”的文章,现在再看,发现很多考虑不全面不深刻的地方。继续抛砖,与大家深入探讨此话题。
今天这篇文章,我们主要关注如下话题:
超异构计算,为什么需要开放生态? 开放生态应该由硬件定义还是软件定义? 什么样的生态才算开放?
01 处理器类型:从CPU到ASIC
1.1 CPU指令集架构ISA
ISA(Instruction Set Architecture,指令集架构),是计算机体系结构与编程相关的部分(不包含组成和实现)。ISA定义了:指令集、数据类型、寄存器、寻址模式、内存管理、I/O模型等。
CPU图灵完备,是可自运行的处理器:CPU主动从指令内存读取指令流,然后译码后执行;指令执行会涉及到数据的载入(Load)、计算和存储(Store)。
我们可以把处理器简单地分为控制平面和计算平面两部分。
CPU是指令流驱动计算的处理引擎。
1.2 (CPU视角的)GPU架构
架构侧重软硬件之间的交互“接口”,而微架构侧重具体实现。因此,GPU架构通常指的是CPU视角看到的GPU“接口”。从CPU视角看GPU的处理流程:
CPU把数据准备好,并保存在CPU内存中; 将待处理的数据从CPU内存复制到GPU内存(处理①); CPU指示GPU工作,配置并启动GPU内核(处理②); 多个GPU内核并行执行,处理准备好的数据(图中的③处理); 处理完成后,将处理结果复制回CPU内存(处理④); CPU把GPU的结果进行后续处理。
1.3 ASIC专用处理引擎
ASIC功能逻辑完全确定:通过驱动程序和CSR和可配置表项交互,以此来控制硬件运行。
ASIC覆盖的场景较小,并且类型多种多样;即使同一场景,不同厂家实现依然存在差别;ASIC场景碎片化,毫无生态可言。
和GPU类似,ASIC的运行依然需要CPU的参与:
数据的输入:数据在内存准备好,CPU控制ASIC引擎的输入逻辑,把数据从内存搬到处理引擎; ASIC的运行控制:控制CSR、可配置表项、中断等; 数据的输出:CPU控制ASIC引擎的输出逻辑,把数据从引擎搬到内存,等待后续处理。
ASIC是数据流驱动计算的处理引擎。
1.4 DSA领域专用架构
DSA是在ASIC基础上的回调,具有一定的可编程能力,覆盖场景更多,性能和ASIC同量级。
DSA经典案例:
AI-DSA,如谷歌TPU; 网络DSA,如Intel Barefoot P4-DSA网络交换芯片。
1.5 小结:从CPU到ASIC,架构越来越碎片化
指令是软件和硬件的媒介,指令的复杂度(单位计算密度)决定了系统的软硬件解耦程度。
按照指令的复杂度,典型的处理器平台大致分为CPU、协处理器、GPU、FPGA、DSA、ASIC。
世间万物由基本粒子组成,复杂处理由基本计算组成。
指令复杂度越高,单个处理器引擎覆盖的场景就会越小,处理器引擎的形态就会越多。
从CPU到ASIC,处理器引擎越来越碎片化,构建生态越来越困难。
02 计算架构:从异构到超异构
2.1 CPU性能瓶颈,引发连锁反应
在云计算、边缘计算以及一些超级终端的复杂计算场景,对灵活性的要求远高于对性能的要求。
CPU通用灵活性好,在符合性能要求的情况下,各类复杂计算场景,CPU依然是最优选择。
对算力的需求不断增加,不得不通过各种异构加速方式进行性能优化。
实践证明,在复杂计算场景,提升性能的同时,不能损失通用灵活性(言外之意,目前很多技术方案损害了灵活性)。
2.2 异构计算存在的问题
复杂计算的挑战:系统越复杂,需要选择越灵活的处理器;性能挑战越大,需要选择越偏向定制的加速处理器。本质矛盾是:单一处理器无法兼顾性能和灵活性;即使我们拼尽全力平衡,也只“治标不治本”。
CPU+xPU异构计算中的xPU,决定了整个系统的性能/灵活性特征:
GPU灵活性较好,但性能效率不够极致; DSA性能好,但灵活性差,难以适应复杂计算场景对灵活性的要求。案例:AI落地困难。 FPGA功耗和成本高,需要一些定制开发,落地案例不多。 ASIC功能完全固定,难以适应灵活多变的复杂计算场景。
异构计算还存在计算孤岛的问题:
异构计算面向某个领域或场景,领域之间的交互困难。 服务器物理空间有限,无法多个物理加速卡,需要把这些加速方案整合; 需要强调的是:整合,不是简单的拼凑,而是要架构重构。
2.3 超异构存在的前提条件:复杂系统和超大规模
基础特征:①超大规模的计算集群;②复杂宏系统,是由分层分块的组件(系统)组成。
单服务器的宏系统复杂度,以及超大规模的云和边缘计算,使得“二八定律”在系统中普遍存在,因此,可以把:相对确定的任务沉淀到基础设施层,相对弹性的沉淀到弹性加速部分,其他继续放在CPU(CPU兜底)。
2.4 从异构并行到超异构并行
计算从单核的串行走向多核的并行;又进一步从同构并行走向异构并行。未来,计算需要进一步从异构并行走向超异构并行。
异构计算是CPU+xPU的两个层次的处理引擎类型,而超异构计算则是CPU+GPU+DSA的三个层次的处理引擎类型。
超异构计算,不是简单的集成,而是把更多的异构计算整合重构,各类型处理器间充分的、灵活的数据交互,形成统一的超异构计算宏系统。
2.5 Intel:超异构、XPU和oneAPI
2019年,Intel提出超异构计算相关概念;目前为止,Intel没有完全符合超异构概念的产品。
超异构计算的基础引擎是XPU,XPU是多种架构的组合,包括CPU、GPU、FPGA 和其他加速器;
oneAPI是开源的跨平台编程框架,底层是不同的XPU处理器,通过OneAPI提供一致性编程接口,使得应用跨平台复用。
2.6 Intel超异构分析
2.7 NVIDIA自动驾驶Thor
(上图为Atlan架构示意图,Atlan和Thor架构相同,性能上有差异)
NVIDIA自动驾驶Thor芯片,由数据中心架构的CPU+GPU+DPU三部分组成,算力高达2000TFLOPS的超异构计算芯片。
Thor是把传统多个DCU(SOC)的功能融合成单个超异构处理芯片。
2.8 为什么是现在?
首先,是需求驱动。软件新应用层出不穷,两年一个新热点;并且,已有的热点技术仍在快速演进。元宇宙是继互联网和移动互联网之后的下一个互联网形态,要想实现元宇宙级别的体验,需将算力提升1000倍。
其次,工艺和封装支撑。工艺封装持续进步,工艺10nm以下,芯片从2D->3D->4D。Chiplet使得在单芯片层次,可以构建规模数量级提升的超大系统。系统规模越大,超异构的优势越明显。
最后,系统架构需要持续创新。通过架构创新,在单芯片层次,实现多个数量级的性能提升。挑战:异构编程很难,超异构编程更是难上加难;如何更好地驾驭超异构,是成败的关键。
2.9 小结:超异构设计和开发难度呈指数上升
软件需要跨平台复用,跨①不同架构、②不同处理器类型、③不同厂家平台、④不同位置、⑤不同设备类型。
如此复杂的超异构该如何驾驭?
03 开放架构和生态的现状
3.1 开放架构和生态综述
系统必然是在某个层次开放:
用户接口:应用程序必须提供UI供用户使用。 开发库:指提供函数的代码,开发者可以从自己的代码中调用这些函数来处理常见任务,如CUDA库等。 操作系统:提供系统调用接口。 硬件需要提供硬件接口/架构,给系统软件调用,如I/O接口、CPU架构、GPU架构等。
互操作性:不同的系统、模块一起协同工作并共享信息的能力。系统堆栈的相邻两层,遵循配对的接口协议进行交互;如果接口不匹配,就需要有接口转换层。
开放接口/架构及生态:基于互操作性,形成标准的开放的接口/架构;大家遵循此接口/架构开发产品和服务,从而形成开放生态。
3.2 RISC-V:开放CPU架构
x86架构主要应用在PC和数据中心领域,ARM架构主要应用在移动领域,目前也在向PC和服务器领域拓展。
为了给芯片提供低成本CPU,加州大学伯克利分校开发了RISC-V, RISC-V已成为行业标准的开放ISA。
理论上可通过静态编译、动态翻译等方式,实现跨不同CPU架构运行。但都存在损耗及稳定性等问题,需要很多移植方面的工作。
一个平台上的程序难以在其他平台上运行(静态),运行时跨平台(动态)更是难上加难。
理想情况,如果形成RISC-V的开放生态,没有了跨平台的损耗和风险,大家可以把精力专注于CPU微架构及上层软件的创新。
RISC-V的优势:
免费。指令集架构免费获取,不需要授权,没有商业上掣肘。 开放性。任何厂家就可以设计自己的RISC-v CPU,大家共建一套开放的生态,共荣共生。 简洁高效。没有历史包袱,ISA更高效。 标准化。最关键的价值。如果RISC-v变成主流架构,就没有了跨平台等成本或代价。
3.3 GPU架构生态
目前,GPU还没有像CPU RISC-V一样,有标准化的、开源的ISA架构。
CUDA是NVIDIA GPU的开发框架,向前兼容。
OpenCL是完全开放的异构开发框架,可以跨CPU、GPU、FPGA等处理引擎。
3.4 DSA,混战
①DSA领域多种多样,即使同一领域,②不同厂家的DSA架构仍不相同,甚至③同一厂家不同代产品的架构也不相同。
最典型的AI-DSA场景,目前就处在各种DSA架构混战的阶段。
要想构建DSA的生态:
软件定义,不需要开发应用,兼容已有软件生态; 少量编程(许多DSA编程,类似静态配置脚本),门槛较低的标准的领域编程语言; 开放架构,防止架构过多导致的市场碎片化。
DSA架构一般来说分为静态和动态两部分:
静态部分。类配置脚本,通过编译器映射到具体的DSA引擎,编程实现DSA引擎的具体功能。 动态部分。DSA的动态部分通常不是编程实现,而是跟已有软件进行适配;相当于是把软件的数据平面/计算平面卸载到硬件,控制平面依然在软件;符合软件定义的思路。
3.5 DSA/ASIC集成平台:NVIDIA DPU
DPU集成虚拟化、网络、存储、安全等DSA/ASIC引擎,DOCA框架:库文件、运行时和服务、驱动程序组成。
DPU/DOCA是非开源/开放的封闭架构、平台和生态。
3.6 DSA/ASIC集成平台:Intel IPU
和NVIDIA DPU类似,Intel IPU集成虚拟化、网络、存储、安全等DSA/ASIC引擎。
IPDK是开源的基础设施编程框架,可运行在CPU、IPU、DPU或交换机。
Intel和Linux基金会的OPI项目:为基于 DPU/IPU 类技术的下一代架构和框架,培育一个标准的开放生态系统。
Intel IPU/IPDK/OPI是开源/开放的架构、平台和生态。
3.7 硬件使能:Hardware Enablement
随着数据中心演变成虚拟机、裸金属机和容器的组合,OpenStack社区扩大成新的OpenInfra社区。
旨在推进开放基础设施领域技术发展,包括:公共云、私有云、混合云,以及AI/ML、CI/CD、容器、边缘计算等。
Ubuntu硬件使能版本:为了更好地支持最新的硬件,会经常更新内核版本,不太适合企业用户。
OpenInfra硬件使能:软件组件需要在云和边缘环境使能硬件,包括GPU、DPU、FPGA等。
在硬件加速/软件卸载的语境下,硬件使能可以理解成:
软件要支持硬件加速,“硬件加速原生”; 如果存在硬件加速的资源,则采用硬件加速模式; 如果不存在硬件加速的资源,则继续采用传统的软件运行模式。
04 硬件定义软件,还是软件定义硬件?
4.1 系统的控制平面和计算平面
把分层分块的系统,映射到软硬件具体实现:控制平面运行在CPU,计算/数据平面运行在CPU、GPU、DSA等处理引擎。
4.2 泛义的软硬件接口
泛义的接口:
块和块之间、层和层之间的接口; 软件和软件之间、硬件和硬件之间、软硬件之间的接口。
软件和硬件之间的接口:
硬件定义接口,软件适配; 软件定义接口,硬件适配; 硬件/软件定义接口,软件接口适配层; 硬件/软件定义接口,接口适配层卸载; 软件硬件设计遵循标准接口(要求:标准、高效、开源、迭代)。
4.3 什么是硬件/软件定义?
系统是由软件和硬件组成,也必然是软硬件协同的。从软硬件的相互关系和影响,阐述软件定义和硬件定义。
评价标准:系统的业务逻辑由谁决定;软件和硬件的交互接口(架构)由谁决定。
“硬件定义软件”定义为:系统的业务逻辑以硬件实现为主,软件实现为辅;软件依赖于硬件提供的接口构建。
“软件定义硬件”定义为:当一个系统的业务逻辑以软件实现为主,硬件实现为辅;或者硬件引擎是软件可编程的,硬件引擎按照软件编程的逻辑执行操作;硬件依赖于软件提供的接口构建。
4.4 硬件/软件定义的依据:系统复杂度
硬件定义软件,还是软件定义硬件,跟系统复杂度是休戚相关的。
系统复杂度较小,迭代较慢。可以快速设计优化的系统软硬件划分,先硬件开发,然后开始系统层和应用层的软件开发。
量变引起质变,随着系统复杂度上升,系统迭代快,直接实现一个完全优化的设计难度很大。系统实现变成了演进式:
前期系统不够稳定,算法和业务逻辑在快速迭代,需要快速实现想法。这样,基于CPU的软件实现就比较合适; 随着系统发展,算法和业务逻辑逐渐稳定,后续逐步优化到GPU、DSA等硬件加速来持续优化性能。
硬件定义还是软件定义?本质上是系统定义。系统的复杂度过高,实现难以一次到位,于是系统的实现,变成了持续优化和迭代的过程。
4.5 硬件/软件定义的本质:归纳和演绎
硬件/软件定义的本质,是通过归纳和演绎实现系统及系统的发展。从长期和发展的视角看,系统是由软硬件共同定义的。我们以典型的处理引擎实现进行分析:
CPU:把所有领域归纳出共性(最基本的指令),这个共性“放之四海皆准”。也即是说,相对其他平台,“CPU不需要再归纳”,只需要持续演绎新的领域和场景。软件定义:CPU已经是成熟的软件平台,可以基于CPU快速实现系统原型,当系统的算法和业务逻辑稳定后,可通过硬件加速进行性能优化。 GPU:把很多个领域归纳出共性,然后硬件实现共性,软件实现个性。GPU平台实现后,可以持续演绎新的领域新的场景。GPU是足够通用、成熟的并行计算开发平台。 DSA:把某个领域多个场景的业务逻辑进行归纳:硬件实现共性部分,软件实现个性部分。DSA平台实现后,可以在此领域演绎新的场景。 ASIC:具体场景的算法和业务逻辑直接变成硬件,软件只是基本的控制作用。直接映射,谈不上归纳和演绎。
05 总结:软硬件共同定义,
超异构开放生态
5.1 软件原生支持硬件加速
软件原生支持硬件加速:
软件架构调整,控制面和计算/数据面分开; 控制面和计算/数据面接口标准化; 硬件加速资源的发现能力,自适应选择软件计算/数据面或硬件计算/数据面。 数据的输入,可以来源于软件,也可以来源于硬件; 数据的输出,可以去向软件,也可以去向硬件。
5.2 完全可编程
完全可编程,不是CPU可编程,而是在极致优化性能基础之上的可编程。完全可编程是分层的可编程体系:
基础设施层可编程。基础设施层Workload不经常变化,可以采用DSA架构。 弹性应用可编程。支持主流GPU编程方式,可以把常见应用通过DSA,实现更高效率的加速。 应用可编程。应用不确定性最大,仍然运行在CPU。同时,CPU负责兜底,所有其他不适合加速或没有加速引擎的任务都在CPU运行。
实现完全可编程的同时,性能数量级的提升:
从整个系统看,绝大部分是DSA加速的,因此系统的性能效率接近于DSA; Chiplet+超异构,系统规模数量级提升,系统性能数量级提升; 从用户角度,应用运行在CPU,用户体验到的是100%的CPU可编程。
5.3 开放接口和架构
ASIC/DSA覆盖的领域/场景较小,芯片对场景的覆盖(相比CPU、GPU)越来越碎片化。
构建生态越来越困难。需要从硬件定义,逐步转向软件定义。
超异构计算,包括CPU、GPU,也包括多种DSA、ASIC类型的处理器。
异构的引擎架构越来越多,必须构建高效的、标准的、开放的接口和架构体系,才能构建一致性的宏架构(多种架构组合)平台,才能避免场景覆盖的碎片化。
5.4 计算需要跨不同类型处理器
超异构包含CPU、GPU、FPGA、DSA等不同类型的处理器,计算任务需要跨不同类型的处理器运行。
oneAPI是Intel开源的跨平台编程框架,通过oneAPI提供一致性编程接口,使得应用可以跨不同类型处理器运行。
更广泛的,不仅仅是跨不同类型的处理器,还要能跨不同厂家的芯片平台。
5.5 超异构开放生态
要想提升算力利用率,就需要把一个个孤岛的计算资源,整合成统一的资源池。
需要通过跨平台融合,实现计算资源池化:
维度一:跨同类型处理器架构。如软件可以跨x86、ARM和RISC-v CPU运行。 维度二:跨不同类型处理器架构。软件需要跨CPU、GPU、FPGA和DSA等处理器运行。 维度三:跨不同的芯片平台。如软件可以在Intel、NVIDIA等不同公司的芯片上运行。 维度四:跨云网边端不同的位置。计算可以根据各种因素的变化,自适应的运行在云网边端最合适的位置。 维度五:跨不同的云网边服务供应商、不同的终端用户、不同的终端设备类型。
超异构时代,必须要形成开放的生态,才能让计算资源形成一个整体,才能满足元宇宙等应用场景对算力数量级提升的要求。
5.6 软硬件共同定义:超异构开放生态
首先,是超异构计算架构。CPU+GPU+FPGA+DSA等多种架构处理引擎组成的超异构计算;实现既要又要:接近CPU的灵活性,接近ASIC的性能效率,以及多个数量级提升的性能。
其次,要平台化&可编程。两个一切:软件定义一切,硬件加速一切;两个完全:完全可软件编程的硬件加速平台,完全由软件编程决定业务逻辑;一个通用:足够的通用性,满足多场景、多用户的需求,满足业务的长期演进。
最后,要标准&开放。架构/接口标准、开放,持续演进;拥抱开源开放的生态;支持云原生、云网边端融合;用户无(硬件、框架等)平台依赖。
0条评论