isca2017_papers笔记: Stream-Dataflow Acceleration

来源:互联网 发布:水星路由器破解软件 编辑:程序博客网 时间:2024/06/03 19:19

摘要

对低功耗数据处理硬件的需求不可阻挡地继续上升。现有的可编程和“通用”解决方案(例如,SIMD,GPGPU)是不够的,这一点从机器学习,计算机视觉和大数据等重要领域的(应用程序和领域特定加速器)的(数量级改进和行业采用)中可以看出。在这两个极端:效率和普遍性之间的鲜明的权衡提出了一个棘手的问题:如果没有特定于领域的硬件解决方案,特定领域硬件的效率如何实现?

在这项工作(在这个问题中),我们依赖结论:“加速”算法具有广泛的共同特性:高阶计算强度高,简单的控制模式和依赖性,以及简单的流存储器(访问和重用)模式。我们定义了一个通用的体系结构(一个软硬件接口),可以更有效地用这些称为流数据流的属性表达程序。该体系结构的数据流组件实现了高度的并发性,而流组件则以非常低的功耗和面积开销实现了通信和协调。本文探讨硬件和软件的影响,描述其详细的微结构,并评估实施。与先进的领域专用加速器(DianNao)和MachSuite的固定功能加速器相比,Softbrain可以和它们的表现差不多而平均功率开销仅为2×(2× power)。

1引言

数据处理硬件对全球经济至关重要 - 规模从网络服务和仓库计算,到网络物联网和个人移动设备。随着这些领域的应用需求的不断发展,由于传统的VonNeumann体系结构的能耗和性能都还过得去,导致通用技术(甚至SIMD和GPGPU)还不足够充分并淡出人们的视线。

相反,专用和特定域的硬件盛行。对于大规模计算,微软已经在其数据中心部署了Catapult FPGA加速器,而Google的张量处理单元也用于分布式机器学习。物联网设备和现代移动系统芯片(SOCs)已经满载着定制硬件,在这个领域上与公司(如Movidius)继续创新开发计算机视觉专用处理器。

虽然更多狭义硬件解决方案是有效的(Whilemore narrow hardware solutions are effective),但它们提出了许多挑战。随着算法快速的变化,导致硬件必须重新设计和重新验证,加重了开发成本和时间成本。因此如果不使用灵活的硬件,算法的创新将变得更加困难。此外,可编程硬件可以跨应用程序进行时间共享,而特定领域则无法实现,从而使得芯片成本更高。最后,从学术角度来看,很难将领域特定硬件形式化或改进并应用到计算机体系结构的更广泛领域,造成了这些工作的局限性。

理想情况下,我们需要的是能够执行 高性能 数据密集型算法的硬件,其功耗比现有可编程架构低得多,同时保持广泛的适用性和适应性。

一个重要的现象,正如文献[9, 21],中提到的,典型加速的工作量?负载(typically-accelerated workloads)具有共同的特征:1. 高阶计算强度高; 2.具有简单控制流程的小型指令空间,3.简单的内存访问和重用模式。原因很简单:通过利用并发性,这些属性可以帮助他们实现非常高效的硬件实现。现有的数据并行硬件解决方案在这些工作量?负载上表现良好,但是为了追求普遍性,牺牲了太多的效率来取代域特定的硬件。例如,短向量SIMD依靠低效的通用流水线来控制和生成地址,但加速代码通常不具有复杂的控制和内存访问。 GPGPU使用大规模多线程硬件来隐藏内存延迟,但加速代码的内存访问模式通常可以在没有多线程的情况下进行简单的解耦(将关联解除,使系统内各通道相互独立)。

基于这个优势,我们的工作提出了一个加速工作量?负载的架构和执行模型,其硬件实现可以接近专用设计的功耗和面积效率,同时在各个应用领域保持灵活性。由于其组件,它被称为流数据流,并显示出这些基本的性质:

•用于重复流水线计算的数据流图。

•(用于促进跨组件和内存的高效数据移动)的基于流的命令。

•私有(便签本)地址空间,用于有效的数据重用。


图1(a)描述了程序员关于流数据流的视图,包括数据流图本身,以及用于存储器访问读取重用和循环的显式流通信。抽象图推出直观的硬件实现(The abstractions lead to an intuitive hardware implementation);图1(b)显示了我们的高级设计。它由粗粒度可重构体系结构(CGRA)和暂存器组成,与宽总线连接到存储器。它由一个简单的控制核心控制,它发送流命令,由内存控制引擎,暂存器控制引擎和粗粒度可重构体系结构同时执行。这种基于流接口的粗粒度特性使得内核非常简单,而不会牺牲执行时高度并行的特性。流访问模式和有限的内存语义也使高效的地址生成和协调硬件成为可能。

相对于特定于域的体系结构,流式数据流处理器可以重新配置其数据路径和内存流,因此具有更强的通用性和适应性。相对于GPGPU或短向量SIMD等现有解决方案而言,在适合的工作量?(负载)内,功耗和面积开销明显较低。实例可以在各种设置中灵活地部署,既可以作为独立的芯片,也可以作为SoC上的块;它可以与虚拟内存集成,并使用缓存或直接访问内存。

在本文中,我们首先定义流数据流,描述其执行模型,并解释为什么它提供了比现有体系结构更专业化的好处。然后我们在描述我们实现的微体系结构SoftBrain之前讨论ISA和可编程性。为了演示这个架构的通用性和这个实现的能力,我们比较了一个最先进的机器学习加速器,以及MachSuite工作负载的固定功能加速器。我们的评估显示,它可以实现与加速器相当的性能,与CPU相比,数量级和功耗效率都有所提高。与机器学习加速器相比,我们平均只有2×功率和面积开销。在更广泛的MachSuite工作负载中,与定制ASIC相比,平均开销是2倍功率和8倍面积.

 

2动机和概述(MOTIVATION AND OVERVIEW)

对于广泛的数据处理算法,特定于领域的硬件比起现有的通用解决方案具有数量级的性能和能源优势。根据定义,领域特定的加速器采用的策略是限制编程接口以支持适用于该领域的更加狭义的一组功能(narrowerset of functionality),并且这样做简化了硬件设计并提高了效率。我们进一步推测,特定领域和通用架构之间的效率差距是在于通用程序在指令级的表现,而不是采用的微架构机制的一个方面的基础。

到目前为止,现有的可编程体系结构(例如SIMD,SIMT,Spatial)已经显示出一些希望,但只有在提供硬件/软件接口取得了有限的成功,这些接口使得更多定制设计采用的相同的专用微架构技术成为可能(buthave only had limited success inproviding a hardware/software interface that enables the same specialized microarchitecture techniques that morecustomized designs haveemployed. )。

因此,我们的目标是发现什么样的抽象架构可以使微体系结构与定制设计的执行风格和效率相适应,至少对于具有长时间数据处理阶段和流存储行为的广泛使用和重要的应用来说。(at least for a broad and important class of applications that havelong phases of dataprocessing and streaming memory behavior. )为了深入了解当前体系结构的局限性和机遇,本节将探讨现有可编程硬件范例的专业化机制。然后我们讨论它们的局限性如何激发一套新的架构抽象。总体而言,我们认为我们提出的流式数据流抽象可以作为未来可编程加速器创新的基础。

2.1现有方法的专业化


为了实现可编程硬件专业化,已经探索了几种从基础上就不同的架构范例; 图2描述了突出的例子。我们分三个方面讨论它们的专业化能力:

1.降低每个指令的功耗和资源访问成本,

2.降低内存寻址和通信的成本

3.降低获得高执行资源利用率的成本。

表1提供了一个总结,我们在下面详细讨论。


SIMD和SIMT:SIMD和SIMT都在其ISA中提供了固定长度的向量抽象,这使得微架构能够缓冲指令调度,并使得更少,更宽的存储器访问成为可能。然而,指令级计算的规范意味着它们都不能通过大的寄存器文件来避免指令通信。

另外,这两种架构都不能实现高硬件利用率的廉价支持。由于向量长度固定且相对较短,因此短向量SIMD处理器不断依赖通用内核来动态调度并行指令。缩放问题宽度,重新排序逻辑和注册文件端口在面积和功耗上是昂贵的。 SIMT公开了大规模多线程能力,通过允许同时执行许多warp(一起发布的线程组)来实现高硬件利用率。这需要大的寄存器文件来保存实时状态,warp-scheduling硬件,并且引起来自许多独立warp的缓存压力。

无论SIMT和SIMD有一些特殊的局限性。 SIMD的通过掩蔽和合并控制流的规范引入附加指令的开销。此外,典型的短向量SIMD扩展缺少有效的数据再利用可编程暂存器。 SIMT线程被编程为对标量数据进行操作,并且warp内的线程通常执行用于空间本地访问的冗余地址生成,并且附加的逻辑结合常见的跨线程访问模式。

VectorThreads ([15, 16]):向量线程体系结构与SIMD类似,但是提供了编程能力以指定计算通道的SIMD风格和标量执行。 虽然这的确消除了控制发散处罚,它面临着许多与SIMD相同的限制。 具体来说,由于计算指令级别的规定,无法避免寄存器文件访问,有限的向量长度意味着依靠控制核心的流水线来实现高利用率

空间数据流:空间数据流体系结构通过其硬件/软件接口公开底层计算结构的通信通道。这使得分布式指令调度成为可能,并消除了实时指令之间的寄存器文件访问的需求。调度开销可以通过配置步骤进行一定程度的缓冲。这种抽象方法的分布式特性也使高利用率,无需多线程或者多issue的逻辑。

但是,这些体系结构无法将内存访问专业化到相同的程度。微架构实现通常执行冗余地址生成,并针对空间本地访问发布更多更小的缓存访问。这是因为空间上分布的存储器地址产生和访问是比聚集成向量存储器操作更难的。

总结和意见:一,能够指定向量内存访问是非常重要的,不仅对并行性和降低内存访问,同时也为减少地址生成的开销。另一方面,尽管向量化指令减少了指令调度的开销,但是将工作分离成定长指令要求通过寄存器文件进行低效率的操作数通信,并且需要高功率的机制来获得高利用率。将空间数据流基板暴露给软件解决了上述问题,但是复杂化并破坏了指定和利用向量化存储器访问的能力。

2.2流数据流的机会

以前观察的核心是向量与空间体系结构之间的基本权衡:向量体系结构揭示了一个效率更高的并行存储器接口,而空间体系结构揭示了一个效率更高的并行计算接口。可以想象,可编程体系结构可以与特定于应用程序或特定领域的体系结构相竞争,它必须同时提供这两个有效的接口。

机遇和概述:虽然在一般情况下同时实现空间和向量体系结构的好处可能是不可能的,但是我们认为在一个受限制但重要的工作负载环境中是可能的。特别地,许多数据处理算法显示出其中(可以独立指定它们的计算和存储器访问组件)的属性。 遵循解耦访问/执行的原则[30],我们提出了一个结合stream和dataflow的抽象方法 - 流数据流的体系结构。 stream组件提供了一个类似于向量的内存接口,以及dataflow组件提供了计算的空间规范。

以下是抽象方法的简要概述,如示于图3stream接口提供了一组有序的Streamcommands,其中已经被嵌入一个现有的冯·诺伊曼ISA。Stream command指定存储器访问的长的且并发的模式。 可表达的模式包括连续的,跨越式的和间接的。我们添加一个单独的“便签本”(暂存器)的地址空间,可以用来有效地收集和访问重新使用的数据。 最后,dataflow接口通过数据流图(DFG)提供指令及其相关性。 DFG的输入和输出接口被命名为具有可配置宽度的端口,即stream的源和目标。


微体系结构:标准的硬件实现包括用于计算的粗粒度可重构体系结构(CGRA),可编程暂存器,用于处理存储器或暂存器访问命令的stream引擎以及用于生成stream command的控制核心。流调度器执行stream之间的架构级的依赖关系。控制核心可以执行任意程序,但是它被编程为将尽可能多的工作卸载到stream-dataflow硬件。

功能和比较:Stream-dataflow实施方案可以实现coalescedmemory access,并通过将流式访问分解为内存接口大小的请求来避免冗余地址生成。 灵活长度(通常很长)的流命令意味着控制核心可以非常简单,因为只需要生成stream(不管它们的执行)。 通过使用数据流计算基板,而不使用多线程或多issue pipeline提供了高利用率,这也避免了访问大的寄存器文件来传递值。 缺点是细粒度控制依赖于预测(功率开销),粗粒度控制需要重新配置(性能开销)。幸运的是,它们在通常加速码中都比较少见。

3流式数据流架构

在本节中,我们通过其编程抽象,执行模型和ISA来描述stream-dataflow体系结构。

3.1概念

Stream-dataflow将计算抽象为数据流图和带有流和障碍的数据移动(图3)。表达这些抽象概念的命令被嵌入到一个通用程序中。下面介绍这些抽象概念和相关的命令。

数据流图(DFG):DFG是一个包含指令和依赖关系的非循环图,最终映射到计算基板。请注意,我们支持直接累加的循环,其中一条指令产生一个值,它可以被其后一个本身实例累加。我们将在后面介绍的“recurrence streams”介绍更一般的循环依赖关系。

DFG输入和输出被命名为具有显式向量宽度的端口,用作数据流的输入和输出,便于通信。对于每一组到达输入端口的输入,产生一组输出。 通过输入端口,计算节点和输出端口执行整个数据流图的一次迭代是一个计算实例。数据流图可以通过配置命令进行切换。

streams:streams是由源体系结构位置,目标和访问模式定义的。由于私有暂存区地址空间被提供,位置可能是寄存器 或 可编程暂存器地址 或 已命名端口之一。端口既可以代表DFG输入或输出的通信通道,也可以是间接端口,用于高效间接存储器访问。从DFG输出到输入的流提供了循环。 DFG端口的访问模式只是先入先出(FIFO),而暂存器和存储器的访问模式可能更复杂(线性,跨步,重复,间接,散列表等),但是模式的有限子集可能会以牺牲一般性为代价来被选择。

流通常并发执行,但具有相同的DFG端口必须在逻辑上按照程序顺序执行,并且从输出端口DFG写入的stream将等待直到数据可用。另外,从DFG输出到DFG输入的流可以被用来表示迭代间依赖关系。

障碍和并发:障碍指令序列化 某些类型命令的执行。 它们包括一个位置(暂存区或内存),以及一个方向(读或写)。语义是任何后续的流命令都必须在逻辑上强制执行 它自己 和 障碍指令中之前描述的任何命令  之间的前后关系。例如, 从头读 障碍指令 将强制,一个访问了地址A的从头写操作  必须发生在  一个访问了地址A的从头读操作之后,障碍指令结束之前。 障碍指令还可以选择性地序列化控制核心,以便在数据可用于主机时进行协调。

请注意,在没有障碍的情况下,所有流都可以同时执行。因此,如果两个stream-dataflow命令读写相同的暂存器或存储器地址,而在它们之间没有障碍,则该操作的语义是未知的。主机内核存储器指令和stream-dataflow命令之间也是如此。程序员或编译器负责执行内存依赖关系。

3.2编程和执行模型

流数据流程序由一组配置,流和屏障命令组成,它们与一般程序的指令相互作用并被排序。


图4(a)示出了转换前和转换到stream-dataflow体系结构后的向量点积代码区域。对于a,b和r的存储器访问流现在明确地被示出,并且计算已被完全除去(图3中的DFG)。 还要注意,循环也被完全删除(因为循环控制现在与流长度隐含地耦合),表明控制核心上所需的动态指令的总数量大大减少。

执行模型:Stream-dataflow程序分阶段执行,每个程序通过一个流命令发起数据移动开始并在该同步控制核心的一个最终障碍指令结束。阶段具有许多计算实例组成的任意长度。 图4(b)中的一个简单示例演示了执行模型如何提供并发性。流命令,CGRA和控制核心的状态随着时间显示。 对于每个流,我们注意到从控制核心入队的地方,调度并行执行,完成,并且标记它拥有源数据传输所有权的持续过程。红色箭头显示事件之间的依赖关系。

为了解释,前两个命令是在控制核心上生成的。 他们排队等待执行并按顺序调度,因为他们之间没有资源依赖关系。两个流共享内存获取带宽。 只要端口A和端口B有3个项目的数据(3是端口宽度),计算开始。 同时,最后两个指令生成和入队。只要一个计算实例完成,计算的数据就开始流式传输到内存。 当所有数据被释放到存储器系统中,障碍命令的条件被满足,控制核心恢复工作。

性能:抽象概念和执行模型推出更高性能的直观实现。首先,DFG大小应尽可能的大,以最大限度地提高指令并行。其次,流应尽可能“长”,以避免控制核心上的指令开销。 第三,重复使用的数据应该推到暂存器,以减少到内存的带宽。

3.3 stream-dataflow ISA

由于大部分stream-dataflow处理器都是提供给软件的,因此必须仔细考虑将体系结构抽象概念的编码转化为为特定的ISA。 我们在这里讨论的一个stream-dataflowISA的实例,其流命令汇总表2.这些命令将被嵌入到控制核心的ISA,通常是在固定宽度RISC ISA 1-3的说明。


DFG规范:ISA提供了 底层计算基板的可配置网络以及 数据流和计算基板之间的可用通信通道(称为向量端口)。 这两个特征对应于DFG规范的指令映射 和向量端口映射组件。 相反,提出具体的DFG编码的,我们在这里讨论两个映射规范的基本要求,以及对可编程性的影响。

对于指令映射,大多数硬件实现将使用基于配置的基板,这意味着将会有每种配置每种类型的允许指令的最大数目。硬件也可能会限制输入或输出的数量,以及操作数的带宽。

对于向量端口映射,ISA定义:1.向量端口的数量,2.它们的宽度(每个周期可传输的最大数据字),3.它们的深度(相关的缓冲区大小)以及4.它们与计算基板的连接。所有这些影响可编程性; 例如,如果没有向量端口足够宽可以用于DFG的端口,则该DFG不能被映射到硬件。此外,程序中的最大重复长度不得超过向量端口的缓冲能力(深度),否则会发生死锁1。然而,应该注意的是,暂存器或存储器可用于较长的依赖性链与使用的障碍。

 

注1这是因为重发流将永远不能保留相应的向量端口。 在实际中,16-64个标量值的长度似乎是足够的。

 

虽然以上介绍了相当复杂的工作,但我们的实现表明,编译器可以自动执行指令和向量端口映射。程序员使用简单的配置命令SD_Config从内存中加载DFG配置。

流规范:为了效率和通用性之间平衡,我们专注于提供可以构建高效硬件的通用地址模式。一种这样的模式是二维仿射访问,由access size访问大小(最低级别访问的大小),stride跨度(连续访问之间的大小)和number of strides跨度数量定义。这个抽象方案以及它可以产生的不同的例子模式如图5所示。更正式地说,这些访问形式为[C * i +j],其中变量i和j从0递增到上限。


我们提供的另一种模式是间接的。 用于间接流的源是另一个流的目的端口,它用来产生存储器地址。原始流的数据可以作为从起始地址的偏移量,或作为指针值。 可以链接间接流以创建多种间接访问模式(例如a [b [c [i]]])。 我们强调的是,只有一个数据结构访问的最低水平(最小access size)应符合这些模式之一。 控制核心可以自由生成任意的起始地址,以允许更复杂的整体模式。

最后,为了支持控制和软件流水线,我们添加了用于发送常量(SD_Const_Port)和从端口清除不需要的值(SD_Clean)的流。

在定义了可能的源和目的地以及可能的访问模式的情况下,指定这些流的命令自然会出现(见表2)。流命令具有源,目标,模式和长度的参数。

障碍规格:该ISA提供三个障碍命令。 前两个同步暂存存储器的读写,最后一个保证阶段完成,数据在存储系统中可见。

示例程序:图6是一个示例神经网络分类器,实质上是突触和输入神经元的密集矩阵 - 向量乘法。 该图显示了原始程序,流数据流版本和执行行为。数据流版本的转换使用长流命令(第4-7行)将整个神经元和突触的加载拉出循环。这里,输入的神经元被加载到暂存器,而同时读出突触插入端口中。 单循环内部(第10-13行)是协调累加器复位的流,然后将每个输出神经元的最终值发送到内存。 请注意,由控制核心执行的指令数是由Ni的大致的因子减小。


4流式数据流微结构

我们构建stream-dataflow ISA微架构的目标是尽可能地提供效率与应用程序或特定领域专门设计的效率 相近。因此,我们采用两个主要的设计原则:避免引入大型或耗电的结构,特别是多端口存储器,并充分利用ISA提供的并发性。在这里,我们描述微体系结构的实现,Softbrain,以及如何通过利用stream-dataflow体系结构基元来实现上述目标。

4.1概述

在较高的层面上,我们将 生成流命令的低功耗控制核心,能高效地接合存储器和移动数据的一组流引擎,以及一个用于高效并行计算的深流水的可重构数据流的基板(见图7)结合起来。有五种主要组件类型:


核心控制——一个低功耗的单任务指令核心,为流调度程序生成stream-dataflow命令。它具有可编程性并且功耗和面积成本都很低。

流调度器——该单元通过跟踪流资源的依赖关系 并向 流引擎发出命令 来管理流引擎的并发执行。

流引擎——数据访问和移动是通过三个“流引擎”来实现的,一个用于内存(有利于增加访问内存宽度),一个用于暂存器(有利于数据重用),一个用于DFG重复(即时重用,不需要内存存储)。流引擎通过分配给它们的流来仲裁其各自内存和暂存器资源的访问。

向量端口——向量端口是CGRA执行的计算与输入/输出数据流之间的接口。另外,未连接到CGRA的一组向量端口用于存储间接 加载/存储 的流式地址。

CGRA——粗粒度可重构架构实现了数据流图的流水线计算。 CGRA的空间特性避免了为活动的值访问寄存器文件或存储器的开销。

流命令生命周期:流命令的生命周期如下。首先,控制核心生成命令并将其发送到流调度器。一旦任何关联的资源(向量端口和流引擎表项)是空闲的,流调度器就会将命令发布到适当的流引擎。每个流的数据传输由流引擎执行,它跟踪流的运行状态。当流完成时,流引擎通知调度器相应的资源是空闲的,使得下一个流命令被发出。

4.2流调度和控制核心

流调度器的作用是实现流(和障碍命令)对资源依赖关系,并通过发送命令来协调流引擎的执行。图9显示了流调度器的设计和内部资源管理机制。来自控制核心的流请求是需要排队的,直到它们可以被命令解码器处理。这个单元咨询资源的状态检查逻辑,以确定是否可以发出一个命令,如果是的话,它将被出队。障碍命令阻止核心发出进一步的流命令,直到障碍条件解决。我们在下面更详细地解释。


资源管理:具有相同源或目标端口的后续流必须按照程序顺序执行,即控制核心上的流的动态顺序。流调度单元负责维护这个顺序,并且通过跟踪记分板中的向量端口和流引擎状态来实现。在发布流之前,它会检查这些记分板的状态。

向量端口的状态可以是taken, free, or all-requests-inflight。当被资源分配器issue时,端口从free转移到taken,并且该流在运行时在逻辑上拥有该资源。完成后,关联的流引擎通知调度器将向量端口的记分板条目更新为free状态。all-requests-inflight的状态表示对存储流的所有请求都被完全发送给存储系统(但还没有到达)。这种状态作为一种优化来存在,使得使用相同端口的两个存储器能够同时在存储系统中请求它。

障碍:流调度器还必须协调被障碍指令指出的流的顺序。我们简单的微体系结构只实现了暂存器的障碍,并且只是阻止命令超越障碍直到条件满足(例如没有未完成的暂存器写入)。其他活动流可以在流调度器等待时继续执行有用的工作,这是正确的程序如何保证过程向前推进的方法。

与控制核心的接口:调度器和控制核心之间的接口是命令总线,并且这些命令是排队的直到被执行。调度器可以停止核心,如果命令队列已满,或SD_Barrier_All命令位于命令队列中,则会发生这种情况。

4.3流引擎

流引擎管理许多活动流对各种资源(存储器接口,暂存器,输出向量端口)的并发访问。通过仲裁流访问充分利用相关资源,对于以低功耗开销实现高并行性是至关重要的。

流引擎是通过从流调度器接收命令来初始化的。然后在流的生命周期中协调地址生成和数据传输,并最终在相应的向量端口被释放时(流完成时)通知调度器。每个流引擎都有自己到输入输出向量端口的512位宽的总线。流调度器确保流具有对向量端口的专用访问。未连接到CGRA的向量端口实现了间接访问,这些端口在使用时可以缓冲地址。下面我们描述每个流引擎中的中央控制单元,流请求通道,其次是每个流的具体设计方面。


流请求通道:每个流引擎需要相似的硬件来仲裁对底层资源的访问,我们称之为流请求通道。在每个循环中,该单元选择多个活动流中的一个并实现其地址生成和数据传送。图8显示了流请求通道的模板,对每种类型的流引擎可以稍微修改该模板。当一个命令被发送到一个流引擎时,它首先被解码并且将相关的状态被放置在流表中。流表维护了一组活动流,其中每行包含了流的相关数据。准备逻辑观察流的有效性,并且将连接到外部反压信号(例如,输入向量端口中的剩余空间)以确定哪些流准备好发出。如果流的目的地未满并且其来源具有数据,则流准备就绪。选择器优先考虑准备好的流。

所选流的状态将被发送到适当的地址生成单元(AGU)(仿射或间接),计算下一个64字节的对齐地址。这些单位还会生成一个掩码来指示与流相关的字。仿射AGU通过检查访问大小access size,,步长大小stride size和步数number-of-strides参数来生成存储器请求的最小数量。间接AGU从间接端口获取地址值。该单元将试图在当前的64字节线中合并最多四个增加的地址。

内存流引擎:这个单元提供来自或去往内存系统的数据,在Softbrain的情况下是宽接口缓存。读写引擎有自己独立的流请求通道。内存读取引擎可以缓冲 未解决的请求 ,并使用一个平衡仲裁单元来选择流的优先级(在4.5节中描述)。到CGRA的存储器读取背压信号是与向量端口相关联的缓冲器中空闲的条目的数量。为了处理暂存器写操作中的背压,有一个缓冲器设置在MSE和SSE之间。这个缓冲区被到内存的请求 分配,以确保存在空间。内存写入引擎使用 来自向量端口的数据可用信号 来进行优先级选择。

暂存器流引擎:除了索引暂存器外,这个单元与上述类似。单写单读端口的SRAM是足够的,其宽度的大小与CGRA的最大数据消耗率成正比。类似于内存流引擎,背压信号是向量端口上的空闲缓冲器条目的数量。如果没有可用的条目(即存在背压),则不会选择相应的流来加载数据。

减少/循环流引擎:减少/循环流引擎将数据从输出向量端口传递到输入向量端口,以便高效地传递依赖关系。它也用于从核心提供“常量”。它不需要AGU,但是使用与上述单元类似的背压机制。

4.4计算和数据流触发

向量端口接口:向量端口是CGRA和流引擎之间的接口,实质上是512位宽的FIFO,其持有CGRA等待被消耗的值。每个向量端口每个周期可以接受或发送可变数量的字,最多可达8个64位字。在CGRA方面,向量端口连接到一组异构的CGRA端口,这组CGRA端口被选择传播传入/传出值到CGRA周围以最大限度地减少争用。该映射被馈送到DFG调度器以将程序DFG的端口映射到硬件向量端口。数据流触发以粗粒度方式发生,当所有相关向量端口上有一个实例的数据可用时,所有的相关数据同时释放到CGRA中。

CGRA:CGRA是一个深度流水线执行基板类似于以前的设计[7,29]。它具有处理单元的电路交换网格,每个网格包含一组流水线功能单元。每个FU的预测支持允许 本地独立数据控制流 的映射,并且FU存储重用的常数和累加器。它与参考设计的不同之处在于网内没有流量控制(我们发现这减少了一半的网络面积)。这是通过输入向量的同步数据流触发来实现的。流量控制的缺乏还要求DFG编译器能确保沿所有计算路径(包括输出向量端口)的延迟匹配。 CGRA的数据路径在我们的实现中是64位的,功能单元可以执行多个子字操作,包括32位和16位。

CGRA(数据路径和常量)和向量端口的配置由内存流引擎处理的SD_Config命令进行初始化。如果数据被缓存,配置可以在少于10个周期内完成。

4.5横切设计问题

缓冲和死锁:Softbrain单元必须通过将流请求平衡到不同的向量端口来避免死锁。对于流引擎,这可以是本地的,因为每个流引擎拥有单独的资源。例如,当单个端口的许多长时间延迟操作将请求管道填充到内存时,可能发生死锁,但是在另一个端口上需要数据用于CGRA计算以实现前进。如果其中一个数据流被跨越,会导致较低的相对内存带宽。我们通过向内存加载流引擎添加一个平衡单元来解决这个问题。它跟踪每个活动向量端口的不平衡量,严重不平衡的端口被降低优先级。

内存一致性:由于Softbrain的内存接口直接访问二级缓存,控制内核L1和L2之间可能存在不一致性。为了避免从L2到流引擎的非连贯读取,控制核心的L1是连续写入的。为了避免在L1上进行不连贯的读取,Softbrain在处理流时发送L1标签失效。

编译器和编程人员的角色:在这项工作中,我们直接使用数据流命令的内在函数表示程序。因此,主编译器任务是为DFG和向量端口映射生成适当的CGRA配置。 DFG是用一种简单的图形语言来指定的,我们扩展了一个基于整数线性优化的调度方法[22]。

虽然编程是低级的,但是原语比SIMD对应的更灵活。编译来自更高级别语言(OpenCL / OpenMP / OpenAcc)的stream-dataflow ISA似乎是实用而且相当有用的,特别是将设计扩展到更复杂的工作负载范围中。这是未来的工作。

集成:Softbrain可以通过多种方式集成到更广泛的系统中,包括,通过统一的虚拟内存作为SoC中的一个单元,或者作为独立的芯片。在这项工作中,由于评估目的我们假设有一个独立的设备。可以支持集成到具有连贯缓存的统一虚拟内存。如果假定有专门的加速器访问,或者通过在存储器流引擎中集成TLB,那么地址转换可以在L2级支持(使L1和L2虚拟)。

对于某些设置和系统,还有其他一些设计方面是关键的,比如支持精确的例子,向后兼容性,安全性和虚拟化。这些是推迟到未来的工作。

5实施

这里我们讨论在评估中使用的硬件,软件堆栈和模拟器的实现。我们还讨论了如何在实际的硬件/软件工作流程中使用这个设置。图10显示了一个概述。

硬件:我们在第四节中实现了这个设计。该设计是可参数化的(eg. CGRA size, FU types, port widths,scratchpad size, etc),,并且使用与软件堆栈和模拟器共享的体系结构描述文件。

软件堆栈:对于编程,我们创建一个简单的包装API,它被映射到流数据流ISA的RISCV编码中。我们用流数据流ISA扩展修改了RISCV的GCC交叉编译器,并实现了我们自己的DFG编译器。 DFG到CGRA的映射器扩展了以前的工作[22]。

模拟器:我们为控制核心和Softbrain实施基于循环级别的RISC-V模拟器。 Softbrain模拟器是一个简单的模块,它采用流数据流命令,并与内核的缓存接口集成,用于加载/存储请求。

硬件/软件工作流程:实际上,硬件将在每个芯片系列中提供一次。例如,如果事先知道特定市场的所有数据类型最多为16位(例如,用于机器学习),则可将其并入CGRA的功能单元组成中。在这里,架构师要么使用现有知识,要么使用来自相关领域的概要文件应用程序。然后他们只调整FU mix和暂存器大小,在硬件参数模型文件中记录下来。即使在这种情况下,也不需要修改Chisel或硬件接口。

对于每个应用程序,开发人员构造计算组件的DFG,并写入流协调程序(将流命令嵌入到C程序中)。

6实验方法

工作负载:为了与领域特定的加速器进行比较,我们使用DianNao加速器工作的深度神经网络(DNN)工作负载[3],包括分类器,卷积和池化层。它们具有高度的数据并行性和存储规律性,并且在其重用行为(以及因此的存储器带宽)上有所不同。

为了更广泛地理解效率和一般性的权衡,我们考虑MachSuite[26],这是一组典型的加速工作负载。与DNN工作负载不同的是,它们可以捕获更广泛的程序行为,如常规和不规则的内存访问模式,数据依赖关系的控制以及不同的计算强度。我们将这些设计与应用程序特定的版本进行比较。

功耗与面积:对于我们Softbrain实现的功耗和面积,我们用SynopsisDC和ARM 55nm技术库合成了CHISEL生成的硬件描述语言,这个库符合1GHz的时序。我们使用Cacti [19]进行SRAM和缓存估计。

比较方法:对于DNN工作负载,我们使用简单的性能模型与DianNao加速器进行比较。这种模式乐观地假设完美的硬件流水线和暂存器重用;在神经网络拓扑结构和存储器带宽中,它只受到并行性的约束。我们从相关出版物[3]中提取功率/面积数字。对于比较点,我们考虑了单线程CPU实现,是在i7 2600K SandyBridge机器上运行的。我们还比较了用CUDA编写的这些工作负载的GPGPU实现,它们运行在Kepler-based GTX750上。它有4个SM和512个完整的CUDA内核。

为了与MachSuite加速器进行比较,我们使用了Aladdin [28],一种RTL之前的加速器建模工具。 Aladdin根据一系列规定的硬件转换来确定固定功能加速器的性能,功耗和面积。(如循环展开,循环展平,存储器阵列分区和软件流水线,这会影响数据通路和暂存器/缓存大小)。

7评估

在本节中,我们将介绍评估Softbrain的五个重要问题,我们在这里列出他们的简要答案:

(1)其功耗和面积开销的来源是什么?

•CGRA网络和控制核心。

(2)它可以与领域特定的加速器的加速性能差不多吗?

•是

(3)stream-dataflow范例是否一般?

•是的,所有DNN和大多数MachSuite都可以使用stream-dataflow抽象概念来实现。

(4)在通用性上有什么限制?

•不适合的代码属性是任意的内存间接和别名,控制相关的加载和位级操作。

(5)stream-dataflow与应用特定的比较起来如何?

•只有2倍功率和8倍面积开销。

7.1领域特定的加速器比较

在这里,我们探索Softbrain的功耗和面积与深层神经网络领域特定的加速器相比较。我们的方法是将设计与同等性能进行比较,并检查Softbrain的面积和功率开销。

面积和功率比较:为了直观比较,我们配置了Softbrain的功能单元以满足DNN工作负载的需求。在这里,我们需要四路16位子字SIMD乘法器和ALU,以及一个16位sigmoid。我们还包括8个total tiles(Softbrain单元),这使得Softbrain可以达到与DianNao相同数量的功能单位。

表3显示了面积和功率的细分。所有的分析都被规格化到55纳米工艺技术。对于这里的功耗计算,我们使用DNN工作负载的最大活动因子。该区域的大部分来自CGRA网络,占总面积和功率的四分之一左右。另一个重要因素是控制核心,占用三分之一的功率和面积。与DianNao加速器相比,Softbrain只有1.75倍左右的功率,稍大一点。

性能:图11显示了三种DNN工作负载的Kepler GPU,DianNao和Softbrain的加速。总体而言,对比GPU可以获得高达20倍的性能提升,而DianNao 和 Softbrain则达到相似的性能,在一些工作负载上可达到100倍或更多。原因很直观:两种体系结构都使用相同的基本算法,通过将内存访问从深度流水计算中解耦,可以在每个周期内保持100个FU活动。 Softbrain确实在集中工作负载方面有一些优势,因为它更灵活的网络允许它在邻近的计算中重用许多后续的部分和,而不是从内存中重新获取它们。这可以减少带宽并提高速度。

7.2 Stream-Dataflow通用性

在这里,我们试图根据其一般性来提炼Stream-Dataflow处理器的局限性。为此,我们从MachSuite中学习了更广泛的典型加速工作负载,并为他们提供了一个单独的设计。我们首先描述这些工作负载的实现以及我们发现的局限。

SoftBrain配置:为了配置Softbrain的FU资源,我们实现了MachSuite工作负载的stream-dataflow版本,最多可以有20个DFG指令(与我们用于DianNao比较的大小相同)。然后,我们将Softbrain的FU混合配置到不同工作负载所需的最大值。请注意,为了保持一致性,我们使用了64位整数/定点数据类型2。此后,我们将其称为广泛提供的SoftBrain。

 

注2:使用浮点运算可以减少Softbrain相对于ASIC的相对开销,但也会略微降低加速的面积/功耗优势。

SoftBrain通用性:表4总结了在流数据流程序实现中使用的体系结构抽象。它描述了流模式和数据路径结构3

 

注3:还有4个额外的工作负载,我们还没有实现,但符合stream-dataflow范例:fft,md(网格版本),nw和backprop

我们发现每个架构特性在多个工作负载中都是有用的。 gemm和stencil代码使用仿射访问来减少访问惩罚。在四个工作负载中需要间接装载或存储。循环模式在大多数工作负载中都是有用的,主要用于减少变量。数据路径的大小和配置差异很大,从简化树,SIMD风格的数据路径到更不规则的数据路径,表明灵活的CGRA是有用的。

我们发现有四个工作负载无法在stream-dataflow中高效实施。 aes加密工作负载需要太多的字节级操作(访问小于16位的字),这使得很难证明卸载到粗粒度的结构上是合理的。 kmp字符串匹配代码需要任意方式的间接加载,而体系结构只能以有效的方式支持有限的间接加载。归并排序代码包含细粒度的数据相关加载和控制指令,用于决定从下一个读取哪个列表。基数排序工作负载有几个阶段,在这个阶段读取或写入可能是到相同的地址(我们不提供硬件支持隐式存储负载转发)。

总体而言,SoftBrain是具有相当普适性的,适用于许多数据处理任务,甚至一些具有显著的不规则性。它的局限性在未来的工作中可能会变为可行的。

7.3特定应用的比较

在本节中,我们将一般配置的Softbrain与针对每个应用生成的定制ASIC进行比较,从功耗,性能,能量和面积等方面进行比较。

ASIC设计点选择:为了将一般配置的Softbrain与工作负载特定的ASIC进行比较,我们选择进行iso性能分析,其次是最小化ASIC面积和功耗。详细解释 - 对于每个工作负载,我们通过修改硬件优化参数来探索一个大的ASIC设计空间,并且在一定的Softbrain性能阈值(尽可能在10%以内)内找到一组ASIC设计。在这些要点中,我们选择了功率,面积和执行时间的Pareto最优ASIC设计,其中功率优先于面积。

性能:对于Softbrain到ASIC的性能评估,将从我们Softbrain中的基于 RISC-V的仿真器获得的执行周期与Aladdin生成的特定于基准的自定义加速器的执行周期进行比较。图12显示了SoftBrain与特定基准Pareto最优ASIC相比的性能。对于ASIC和Softbrain,执行周期均标准化为SandyBridge OOO4(4-wide)内核,两者的执行表现均达到1-7x加速。在大多数情况下,我们发现与Softbrain具有相似性能的ASIC设计。

功耗,面积和能量与ASIC设计的比较:如上所述,我们选择Softbrain启动器到ASIC的功率,能量和面积比较的iso性能设计点。

对于功耗分析,我们认为只有特定的基准测试的FU在Softbrain的CGRA的执行期间上与其他支持结构(包括控制核心,流引擎,暂存器和向量端口)一起处于活动状态。软件的静态功率和面积是从综合设计得到的,所报告的动态功率估计是基于每个模块的活动因子。能量估计从执行周期和动态功率估计中直接获得。 ASIC面积和功耗从Aladdin获得,采用40nm技术,规格化为55nm。

图13显示了基于Sandybridge OOO4核心5的功率存储(效率)。由于OOO4内核支持通用性的功率和面积,所以ASIC和Softbrain的功率节省高达300x,相比于OOO4内核。 ASIC的整体功耗比Softbrain要好,但在所有基准测试中只有2倍。在一些工作负载下,ASIC几乎与Softbrain的功率相同,这是由于Aladdin为了循环展开而实例化较大的存储器结构(暂存器,缓冲区等),从而基本上扁平化了数组数据结构为了腾出设计空间使性能分接近Softbrain。请注意,我们将ASIC的本地存储器结构包括在其功率估计中,因为Softbrain也具有可编程暂存器。Softbrain的大部分额外功耗是由于通用性支持结构,如CGRA网络,它能够映射各种各样的可能的DFG。

注5:我们考虑32纳米1核心的动态功耗,并将其规模化到55纳米。

图14显示了Softbrain和ASIC的能效比较,与基线OOO4核心相比,两者显示出高效率优势。Softbrain的能耗在ASIC的2倍以内,这主要是由于功耗的差异。

图15显示了面积比较。由于Softbrain的面积是固定的基准,结果显示ASIC面积与Softbrain的面积有关系。我们在他们的估算中没有包含ASIC设计的存储器结构区域,因为大多数时候这些工作负载具有流式传输行为,ASIC可以通过更多的并行FU而不是更大的存储结构来实现相同的性能。Softbrain平均面积是ASIC的8倍,因为Softbrain是可编程的,必须运行所有工作负载。从另一个角度来看,Softbrain是一个区域高效的,因为包括所有八个MachSuite加速器,它所需要的面积只有Softbrain的2.54倍。

总的来说,Softbrain在性能,功耗,能量和面积方面与ASIC相比具有竞争力,即使是支持显著的可编程性的硬件也是如此。这表明通过利用通常加速的工作负载的算法属性与支持流数据执行的微体系结构机制之间的正确协同,可以开发可编程体系结构。

8相关工作

数据流并行架构:在可重构流向量处理器(RSVP)[5]中提出了在核心的ISA中提供流以便与可重构硬件通信的概念。 RSVP使用仿射流和数据流图的类似描述,但是具有几个基本限制。任何给定计算的RSVP通信模式在执行阶段都不能改变。这降低了可以表达的模式类型的灵活性(例如,用于减少并且有时写入存储器的输出)。它也妨碍了跨不同阶段预取数据的能力 - 在获取另一个阶段的数据之前,必须完成一个阶段,这对短期阶段来说是一个很高的开销。接下来,RSVP中的迭代间相关距离只能是1,这限制了可编程性。最后,RSVP的“暂存存储器”的地址空间没有提供给编程人员,编程人员只映射地址空间的线性部分。这不允许在稀疏数据表示压缩到暂存区并多次读取的情况下进行一些优化。

Imagine [13]是这个领域的一个早期基础性工作,它是一个用于媒体处理的可伸缩数据并行体系结构。 Imagine使用流的概念在内存和一个所谓的流寄存器文件之间进行显式通信,该文件充当内存和执行单元之间以及后续内核之间通信的暂存器。流被限制为线性,并且具有相对较小的最大尺寸。在下层接口中,流也不会提供在控制执行资源的地方:一个VLIW流水线集群由单片机以SIMD方式激活。在这种情况下基于ISA的流可以降低控制VLIW核心的复杂性。从一个高层次来看,Imagine可以被看作是一组流数据处理器,它通过暂存器读取所有的内存,并且可重构结构被更刚性的SIMD + VLIW执行单元取代。

触发指令[23]是一种空间架构,具有一些流式内存功能来支持其数据流结构的特点。计算结构在控制流程和总指令容量方面更加灵活,但可能是更高的功率和面积。

在FPGA计算卸载环境中也会出现与可重构硬件有效连接的问题。 CoRAM ++ [36]支持数据结构特定的API接口,用于将数据传输到FPGA综合数据路径,这些数据路径通过专门的软逻辑为每个支持的数据结构实现。这个接口主要基于流。

消除数据并行体系结构效率低下:一些工作尝试专门化现有的数据并行体系结构。 SIMT的一个例子是利用价值结构来消除冗余仿射地址和值计算[14]。 SGMF架构将数据流扩展添加到GPGPU中 [34]。另一项工作探讨了一套数据并行执行的机制,并对TRIPS空间体系结构进行了评估[27]。他们定义的许多数据并行程序属性都是针对这里的,但是我们使用了一组不同的机制。我们以前讨论过与向量线程架构如Maven VT [16]的关系。

Softbrain可以被看作是我们在之前的工作中定义的原型加速器的一个实例[21],称为LSSD。它利用SIMD内核中的多重问题将数据带到可重构阵列(而不是流引擎),由于核心的问题宽度,这需要更高的能量,并且由于所需的模调度而更难编程或编译。

异构内核:将通用内核和可重新配置的引擎或其他专用引擎相结合是一个大量的工作。一些这样的设计针对的是不规则的工作负载,比如复合内核[18]用于低ILP代码阶段,或者XLOOPS [31]用于循环间迭代依赖模式,或者SEED[20]用于非关键控制阶段。我们认为这些设计大部分与数据流ISA正交。

针对数据并行性的可编程加速器(例如,DySER [7]或Libra [24])可以从我们提出的架构接口中受益,如果编译器可以自动定位这样的架构,可能通过扩展现有的SIMD风格的向量化方法[ 8]。

一个高度相关的工作是内存访问数据流[10],这是另一种访问执行风格的体系结构。它由一个通用核心,计算加速器和可重构的地址结构组成。我们考虑了一种类似的地址生成方法,但是发现我们需要支持的访问模式,面积开销会超过多个因素。

资源提供架构的一个反复出现的问题是二进制兼容性。 VEAL使用动态编译将基线ISA中的循环转换为模板循环加速器,其具有简单的地址生成器和模调度可编程引擎[6]。已经提出了类似的技术来动态编译CGRAs[35],并适用于流数据流。

在域特定加速器中进行流式传输:许多特定域的加速器都使用流式传输和数据流抽象。 Eyeriss是卷积神经网络领域特定的加速器,使用流式访问来引入数据,以及用于计算的数据流基板[4]。最近的一项工作,Cambricon [17]提出了SIMD指令集扩展,它可以执行在DNN中找到的类似于流的访问模式。在机器学习领域之外,Q100 [37]是用于执行流数据库查询的加速器。它使用基于流的抽象来访问数据库列,以及用于执行计算的数据流抽象。

9讨论和结论

本文提出了一种新的执行模型和体系结构,即stream-dataflow,它提供了平衡向量和空间体系结构之间权衡的抽象方法,并获得了对重要类别工作负载数据处理的专业级能力。我们展示了这些原语足够来表达各种深度学习工作负载以及来自MachSuite(ASIC可以考虑的工作负载的代理)的许多工作负载的执行。在我们的硬件实现方面,我们开发了一个高效的微架构,我们的评估表明它的功耗和面积只是领域特定和ASIC设计的一小部分。

我们设想这种架构范式可以通过减少专业化模块的数量来对未来的芯片产生根本的简化效应。相反,stream-dataflow类型结构可以与CPU和GPU处理器一起使用,并且随着程序遇到合适的阶段可以随时合成功能进行高效降载。这不仅减少了大量专业加速器 的面积和复杂性,而且还可以减缓设计和验证成本的增长。在如此广泛的背景下,开发有效的编译工具是非常重要的,这些工具可以平衡这些体系结构提供的并行性和数据重用之间的复杂权衡,为stream-dataflow体系结构提供动态编译支持可以为大众带来专业化的架构效率。

总的来说,我们认为stream-dataflow在未来扮演着重要的角色。正如RISCISA定义并推动了流水线时代以及通用处理器数十年的统治地位一样,在专业化时代,我们需要新的架构和符合新兴工作负载性质的ISA抽象。 stream-dataflow可以作为这一代的ISA来推动进一步的微体系结构和架构级别的加速器创新。

10致谢

我们首先要感谢匿名审稿人提出的具体问题和建议,这些都有助于我们澄清介绍。我们要感谢Preyas Shah为区域功耗分析设计自动化的Synopsys工具集。我们还要感谢Sophia Shao和MichaelPellauer在修订过程中给予的深思熟虑的建议。这项工作得到了国家科学基金会的支持,授予CCF-1618234。

 

原创粉丝点击