小言_互联网的博客

拯救 CPU!

284人阅读  评论(0)

在过去的10-20年间,硬件技术取得了惊人的进步,但在高性能数据中心和高度受限的移动环境中却仍然不能“奢求”廉价的性能。很多人认为,硬件的下一个进步是将神经网络加速器添加到CPU + GPU集群中。然而,这可能会扼杀SoC的性能......

作者 | Tony King-Smith

译者 | 弯月,责编 | 郭芮

出品 | CSDN(ID:CSDNnews)

以下为译文:

自从CPU问世以来,AI是计算方式的一次根本性转变,越来越多的人开始接受这个观点。由于大多数算法都是先写成CPU上执行的顺序代码,然后再利用GPU加速来处理神经网络工作负载,因此很多人认为,硬件的下一个进步是将神经网络加速器添加到CPU + GPU集群中。

然而,这可能会扼杀SoC的性能,可能无法提供预期的性能或效率。但在本文中,我将介绍一些其他的解决方法。

 

简介:SoC的兴起

 

智能手机的崛起在技术领域——尤其是计算硬件取得了巨大进步。片上系统(Systems on Chip,即SoC)只需几瓦的功耗就能提供桌面级系统的性能,然而,由于低功耗和热力学上限方面对高性能的严格要求,我们不得不思考如何设计高性能Soc,利用仅有几瓦特的功率提供媲美桌面级芯片的高性能。

随着移动SoC的发展,片上功能的复杂性也不断发展。最初在2G手机早期,我们只有16位的MCU,而到今时今日移动Soc逐渐发展成为了有史以来最复杂的计算平台之一。它包含了一个芯片上可能加载的所有功能:软件执行(CPU +缓存)、图形加速(GPU)、通信(Wi-Fi、3G / 4G调制解调器、蓝牙)、视频压缩和解压缩、相机管线(ISP),还要连接一系列低速外围设备——包括显示控制器、触摸屏、传感器接口、电源管理、散热管理等。如今的移动SOC处理器一般都是6个甚至更多的CPU组成的64位CPU集群,再加上数百或数千个ALU核心组成的GPU,提供的计算能力甚至超过了3-4年前的台式计算机。

鉴于我们现在已经掌握了这种先进的SoC设计技术,当然应该一如既往地坚持我们正在开展的工作,并加入神经网络加速器,不是吗?对于操作数在每秒100G左右的任务来说,这个主意不错。然而,对于要求操作数在每秒50-100T甚至更多处理能力的车用多传感器系统来说,这是一项艰巨的任务。提高时钟速度和性能说起来容易做起来难,因为我们已经在拼命压榨性能了。神经网络加速器需要数十GB/s或更多带宽,而这些带宽只能占用CPU和GPU的中央存储器资源,因此这项任务会更为艰难。

 

片上带宽非常复杂

 

如果每个处理器无法在执行每项任务时获得所需的数据,那么即便SoC的性能再高也没有任何意义。这就是为什么如今的移动SoC上都加载了先进的片上存储器缓存以及复杂的高带宽片上网络(Networks-On-Chip,即NOC),目的都是为了将各种处理器和加速器连接到存储器、外围设备等。

然而,如今的SoC中许多功能块都连接到了NOC上(通常是NOC网络)。因此,每次数据移动,都必须决定谁有优先权。最终这发展成为了一项非常复杂的任务,而且难度随着时钟速度的提高而加剧。由于优先级决策而丢失的每个时钟周期都会导致带宽丢失,而功能块等待访问NOC,实际上就相当于丢失了时钟周期。

随着先进硅工艺的发展,我们主要的受益是能够在芯片上放置更多的存储器——通常是SRAM(静态RAM)。存储器越接近需要存储的功能块,它的访问速度就越快,读取或写入数据所需的功耗就越小。SRAM非常易于使用,因为你可以随机读取或写入任何数据单元,而且速度非常快。这就是许多应用都使用SRAM的原因,比如片上高速缓冲存储器、FIFO、缓冲器,以及紧密耦合的本地存储器。

但是,由于片上的存储器越来越多,因此在这些SRAM块之间移动数据的情况也越来与频繁。于是,SoC上的NOC的巨大需求出现了。我们放在芯片上的存储器越多,对整个芯片架构的需求就越苛刻。

所有高性能SoC设计人员所面临的最大挑战之一就是,如何在众多工作负载和各种操作条件下,管理和优先处理异常复杂的数据流。

 

外部存储器的需求也很高

 

SoC中的CPU、GPU或其他加速器和功能块的设计人员都需要想法设法尽量将数据留在芯片上。实际上,在功能块内保存的数据越多,需要请求NOC传输的数据就越少。但是,片上的存储器很昂贵——CPU核心的最大缓存很少超过1MB。

如果来自传感器的数据以GB为单位,而应用程序所需的存储器也是GB级别,那么距离SoC与外部存储器通信也就不远了。

通常,外部存储器都采用DRAM(动态RAM),其容量密度是SRAM的5-6倍。然而,为了享受大容量密度带来的好处,你必须尝试请求整块数据,而不能仅仅请求单个字节。这一点与片上SRAM完全不同,后者无论随机访问何处都能提供高性能。这种以结构化的方式访问外部DRAM的需求引发了全新的复杂度:如何组织数据请求,才能最大地压榨存储器的最高数据速率。如果不考虑这一点,那么一不小心就会损失50%甚至更多的存储器带宽。

这个数字非常惊人。假设有一个单核64位CPU,其时钟为2GHz。每个周期取一条指令、读取或写入一条数据,那么就大致需要16GB/s的数据速率。即使我们假设75%的数据访问都能命中片上的L1和L2缓存,那么每个CPU需要的带宽也会高达4GB/s。如果是8个CPU组成的集群,假设集群的利用率为50%,则为16GB/s。而这只是CPU集群需要的带宽!

由于中央处理器是大多数SoC的核心,因此必须为CPU和GPU集群提供充裕的存储器带宽。否则它们的速度很容易被拖慢,即便理论上的最高处理能力再高,大部分也会被白白浪费。因此,除非CPU的大部分时间都在访问缓存中的数据,否则外部存储器的带宽很快就会成为大问题。

GPU消耗的带宽CPU远超CPU,因为它们是并行处理器,每个时钟周期都可以执行更多工作,因为它们是并行工作的可编程ALU阵列。

HBM2存储栈是高性能解决方案,但受其过高的功耗限制,无法应用到车辆和其他嵌入式平台。

最新的存储技术(比如HBM2)可以提供高达256GB/s的惊人带宽。但这些高功率技术是专门为数据中心而设计的,不适合嵌入式车辆或移动应用。我们需要使用更现实的低功耗存储器技术——一般是LPDDR(低功耗动态RAM),它能提供的带宽只是前者的零头。

如今嵌入式或移动设备中最常用的内存是LPDDR4,其每个引脚可提供4.2Gbps的速率。且不论其他方面(例如GPU、调制解调器或视频)的使用,仅仅为CPU集群提供数据传输就可以轻松消耗掉这个带宽。

下一代LPDDR5即将推出,其每个引脚能够提供8Gbps的速率。但这将以消耗更多功率和产生更多热量为代价。因此,距离LPDDR5在车辆系统中广泛使用,我们还需要耐心地再等几年。

 

使用缓存还是使用外部数据?

 

我们需要考虑的另一个领域是,通用移动平台与嵌入式车辆应用程序之间的工作负载差异。通用移动平台有能力处理数百万种应用程序,而嵌入式车辆应用程序的工作非常有限。这意味着我们可以针对车辆应用更好地优化工作负载的情况。

对于要求苛刻的移动应用程序(比如游戏)来说,大部分数据都保存在本地。我们可以利用各种缓存方案优化片上本地保存的数据量,从而最大限度地减少外部存储器上的流量。然而,对于自动驾驶车辆等实时系统来说,它们需要以MB/s级别或更高的速率不断从传感器接收新数据。由于这些数据来自应用程序外部,因此必须通过外部存储器子系统,至少一次。实际上,数据可能会多次传入和传出外部存储器,因为应用程序需要读取并修改数据,然后再写出来。如果利用数据执行低级功能(例如数据过滤或神经网络功能),则这种现象尤为突出。

如果由主CPU预处理这些数据,那么即使是简单的循环也会迅速加重外部存储器子系统带宽的负担。如果接下来让GPU处理这些数据,则还需要读取CPU写出的数据,经过处理后输出结果。这些带宽消耗都需要考虑在内。

管理现代嵌入式SoC数据的任务已经成为SoC设计人员面临的最大挑战之一。因此,如果我们还想着添加另一个高性能、数据密集型加速器(比如神经网络加速器),那么就必须面对这种挑战。

 

为什么神经网络处理的要求如此苛刻?

 

神经网络处理是一种超大规模的并行处理任务。以前创建任何重大的神经网络加速器都是不切实际的,因为硅技术无法完成集成所需的大量计算任务。直到最近,这个问题才有所缓解。

然而,该领域的许多人都已经认识到,神经网络计算实际上是数据驱动的问题,而不是计算驱动的问题。所有神经网络加速器的性能都取决于在网络预测过程中,数据如何在数千个计算引擎之间移动。由于神经网络加速器是数据密集型,因此如何通过最佳方式利用片上和片外的存储器将是一个至关重要的架构问题。但有一件事是肯定的:在实时处理多个高清传感器输入时,系统的持续数据传输量将是巨大的。

此外,随着我们对算法的不断深入了解,神经网络也变得越来越宽、越来越深。AI从业者的担忧在于,高清摄像头的大量使用导致神经网络需要以30fps或更高的速度处理多达八个或更多的尺寸为3x1920x1024的摄像头输入。每个摄像头的流量几乎是200MB/s,那么总共是将近1.6GB/s——这还仅仅是输入数据!

自动驾驶车辆必须通过360°视图全权掌握周围的环境。为此必须使用多个高分辨率的传感器,而每个传感器都会给处理平台带来进一步的压力。

执行多次卷积的前几层很可能需要多次写入差不多大小的输出,后面的操作才能处理规模较小的输入数据。即便我们拥有10GB/s的带宽,恐怕也不容乐观。

这就是为什么我们认为,为了满足多个摄像头(或LIDAR、Radar 或其他精密传感器融合系统)所需的超大带宽,必须慎重考虑整个系统架构的环境中的神经网络计算平台。管理执行每个功能所需的系统带宽,并保证每个功能处理块尽可能高效地运行是关键。

 

这是一个数据的问题,而不是速度的问题

 

我们公司里负责创建aiDrive软件栈的研究工程师在针对他们开发的许多神经网络工作负载展开了广泛分析后,得出了这样一个结论:计算能力并非完全取决于能够同时执行多少个MAC。事实上,这完全取决于数据的移动:每个中间结果怎样通过加速器从一个计算移动到下一个计算。这说明,权重和中间结果的存储位置与相关的执行单元越近,处理效率就越高。因此,在执行期间减少中间缓存或中央共享存储对于提高性能至关重要。

这就是我们创建aiWare的原因:在硬件引擎中实现基于实际工作负载的数据流技术,这比传统的方法更有效。我们希望创建一个能够持续提供高效神经网络计算的引擎,同时管理加速器内部以及神经网络加速器和硬件平台其他部分(尤其是基于CPU的SoC)之间的数据带宽。

最近很多神经网络加速器的实现人员都发现,他们的设计依赖于使用了多少本地存储。对于aiWare来说,本地SRAM块占用了大约全部存储的80%-85%。存储的使用以及数据的传输才是最重要的因素。

 

这是实时推理的问题,与训练无关

 

在过去几年中,人们设计了很多神经网络加速器,几乎每周都有新产品涌现!但是,这些加速器大多数针对的都是在数据中心应用程序上运行的训练过程。一些小型引擎也可以用于移动应用程序,但它们仅适用于语音识别和图像分类等低带宽任务。很多设计人员从事的工作涉及车辆以及其他有功耗限制的高可靠性嵌入式应用程序的实时推理引擎,他们都面临着不同的问题,虽然市场上有很多神经网络加速器,但它们的性能最终都取决于如何解决设计人员的问题。

对于自动驾驶车辆等嵌入式应用程序中的连续性操作来说,关键在于连续几个小时一帧又一帧地不断传输数据。这类系统没有时间定期清理缓冲区、收集垃圾或以其他方式暂停维护。而这些都是数据中心主机或者非实时的移动应用程序习以为常的东西。

对于车辆嵌入式推理系统来说,其所使用的存储器策略必须经得起任何条件的考验,而且必须能够连续工作。

 

那么,为什么不能加快速度呢?

 

SoC的速度年年都在加快,而且我们还在不断缩小流程节点。如果我们能够加快现有芯片的速度,那么问题不就解决了吗?

如下限制表明这种方法并不可行:

1. 距离:尽管距离可能会随着每次流程节点的技术进步而缩短,但它们与更高层集成之间的通信所需的距离更长。发送信号所需的距离越长,所需的能量就越多。物理尺寸越小,每个信号的能量就越少,除非你放大它——而这会增加功耗。因此,即使硅工艺的物理尺寸继续缩小,我们也无法简单地通过添加更多逻辑来加快芯片速度。

2. 成本:每个更先进的硅节点都需要花费上一代技术的4倍才能制作芯片的掩模。虽然每个晶体管的成本降低了,但由于制造工艺的复杂性,最终的成本降低也没有以前那般显著。因此,先进的工艺节点花费在设计和最终设备上的成本要高得多。

3. 噪声:随着工艺节点变小,电压下降,每个比特移动的电子更少。然而,这导致每个信号更容易受到噪声的影响。如果芯片需要在每个时钟周期传输数十亿条导线,那么情况就会非常糟糕,此外车辆中的电噪声会加剧这种情况。随着我们继续缩小芯片,这些系统还能保持健壮吗?

4.摩尔定律:著名的摩尔定律表明逻辑密度每18个月就会翻一番,多年以来这项定律一直得到了应验。然而,如今就不适用了:每代芯片的逻辑密度只能增加1.2-1.4倍。但是,存储器依然遵循该规律。因此,对于未来的工艺节点,设计中存储器越是占主导地位,其扩展性就越好。

5.存储器:外部存储器带宽的扩展速度无法跟上片上存储器的扩展速度。这是因为数据从芯片上传入和传出需要很高的速度——HBM2每个引脚高达2Gbps。这需要很大的功率,而且如果数据传输集中在一个小区域也会导致很大的散热问题。加倍外部存储器带宽可不是一件易事,特别是如果有苛刻的功率限制和热力学上限(比如嵌入式车辆应用程序)时。

 

中央处理器就是中央!

 

许多行业利益相关者认为,未来的自动驾驶汽车将依赖强大的中央处理单元。事实上,越来越多的汽车电子工程师正在考虑为未来的车辆打造“车轮上的数据中心”,就像智能手机是“掌上电脑”一样。这样做有一定的意义:基于中央处理的方法具有一定灵活性,意味着我们不需要在构建处理器硬件平台时照顾到方方面面。例如,我们可以利用现代数据中心的方法,添加和替换计算服务器并虚拟化所有资源,从而实现可升级性。

车轮上的数据中心可能不是车辆生产制造商最终用户的最佳解决方案。车辆硬件平台必须小巧、高效、高性能。

然而,难点在于数据中心并不是为实时系统设计的。有时,它会自动停止并重新配置;重启某些处理器,同时将计算负载转移给其他处理器;如果发生瓶颈就会不断改变工作负载。此外,为了实现这种灵活性,它还需要消耗大量功率,这就是为什么现代数据中心面临的最大问题就是电力问题。这听起来像是理想的车辆解决方案吗?

这种方法可以用于未来车辆中的许多非关键功能。然而,对于实时的、生命攸关的功能,例如L4 / L5车辆的基本控制系统,我们必须权衡所有情况下类似数据中心方法的灵活性与可靠性和稳健性,同时还需要考虑功耗、散热以及电噪声的限制。

这意味着我们必须在中央处理器周围建立越来越智能的子系统,通过这些子系统以更分散的方式管理带宽、处理和功率限制。例如,将一些神经网络处理转移到每个传感器,就可以减少中央神经网络加速器的资源消耗,方便管理,这样就可以利用中央神经网络加速器专门处理关键性的任务,例如轨迹规划或高层对象跟踪等。

行业利益相关者将投入大量资源,为集中式和分布式解决方案寻找最佳选择。事实上,在未来几年中,车辆生产制造商和一级供应商在实现自己的自动驾驶系统时选择的硬件平台和解决方案可能会成为市场差异化的主要因素。

 

减轻中央处理器的负担

 

在了解视觉优先系统时,我们意识到距离汽车行业在最佳硬件架构上达成一致还需要等待很多年。然而,为了将基于AI的软件解决方案所需的处理能力集中到一个小盒子中,神经网络加速器必须具备一定的灵活性,并随着新解决方案的开发,适用于所有类型的硬件架构。这包括从中央处理资源到分布式边缘处理方法。

一个关键因素是如何管理系统带宽。每个摄像头都会生成高带宽的数据流。用于前端感知和分类的神经网络计算需要非常快且百分百可靠。我们的 aiWare存储器架构旨在为系统设计人员提供一套方法,可以将预处理的摄像头(或其他HD传感器)数据直接传输到aiWare的外部存储器。如此一来就可以减轻所有与传感器数据的收集和预处理相关的带宽压力,因为这些处理都脱离了主处理器SoC。接下来,aiWare子系统会将只需少量带宽的结果传送到中央处理器,以供后续功能(例如轨迹规划和控制等)使用。

这种方法可以实现更好的可扩展性,因为想法设法扩展复杂的处理器和管理巨大带宽与存储流量的难度非常大,与之相比,设计基于低级硬件且融合到前端系统的可扩展专用传感器的难度则小得多。

这也意味着中央处理器的灵活性可以发挥最大作用:灵活、复杂的启发式、可处理形形色色的应用程序。例如,AI处理管道的后续阶段大多数时候都依赖于传统计算机视觉和其他算法的综合,这些算法在通用平台上运行的效果更好。

因此,在中央处理器内提供适度的神经网络加速,通过高性能的外部神经网络处理来增强功能,就可以在尽可能低功耗的条件下实现性能可扩展的理想组合方案。此外,还可以利用更分散的方法,实现安全永远有保障的冗余方案。

 

总结

 

一想到未来世界我们将拥有自动驾驶汽车,就让人觉得激动不已。然而,为了获得世界各地人们的青睐,我们必须极力控制功耗,并在苛刻的操作环境成本预算中,提供前所未有的性能。一味地按照以往的工作方式并不能实现这些伟大的目标。

尽管在过去的10-20年间,硬件技术取得了惊人的进步,但在高性能数据中心和高度受限的移动环境中,我们不能幻想廉价的性能。尤其是汽车行业的条件尤为苛刻:极端的操作条件,高度受限的功耗和散热资源,严格的成本限制,漫长的开发时间,乃至更长的产品寿命。

硬件创新不仅可以通过使用最先进的技术来集成更多功能并加快速度,还可以帮助我们解决这些难题。我们可以另辟蹊径利用现有成熟技术下的硬件架构,发挥创新的最大优势,推进汽车行业以及其他嵌入式硬件平台的发展。通过结合这两种创新,我们将有望满足未来那个激动人心的新市场需求。

原文:https://medium.com/aimotive/offload-now-or-your-cpu-dies-ae1d9c5aec3c

本文为 CSDN 翻译,转载请注明来源出处。

【END】

90%的程序员学Python这么认为:

https://edu.csdn.net/topic/python115?utm_source=csdn_bw

 

 热 文 推 荐 

 

华为发布麒麟 990 芯片;苹果召回部分电源插头转换器;KDevelop 5.4.2 发布 | 极客头条

高级软件工程师教会小白的那些事!

我如何在 16 岁成为全栈开发者?

2亿日活,日均千万级视频上传,快手推荐系统如何应对技术挑战?

Docker容器化部署Python应用

☞给面试官讲明白:一致性Hash的原理和实践

预警,CSW的50万枚尘封BTC即将重返市场?

☞她说:行!没事别嫁程序员!

点击阅读原文,输入关键词,即可搜索您想要的 CSDN 文章。

 

 

 

 

 

你点的每个“在看”,我都认真当成了喜欢


转载:https://blog.csdn.net/csdnnews/article/details/100644421
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场