GraphOps: A Dataflow Library for Graph Analytics Acceleration

摘要

图形数据结构的分析和知识提取已经成为人们非常感兴趣的领域。对于频繁执行的算法，专用的硬件加速器是实现高性能的节能途径。不幸的是，在满足严格的上市时间目标的同时，设计和验证它们的工作量很大。在本文中，我们介绍了GraphOps，这是一个模块化的硬件库，可快速轻松地构建用于图形分析算法的节能型加速器。 GraphOps为硬件设计人员提供了一组可组合的特定于图形的构建块，这些构建块的范围足以针对大量的图形分析算法。该系统基于数据流执行平台构建，并以FPGA为目标，从而使供应商可以使用相同的硬件来加速不同类型的分析计算。诸如流控制，输入缓冲，速率调节以及主机/中断交互之类的底层硬件实现细节会自动处理，并内置到GraphOps的设计中，从而大大减少了设计时间。作为一个有力的贡献，我们还提出了一种新颖的局部优化图形数据结构，当访问主存储器中的图形时，该结构可改善空间局部性和存储效率。使用GraphOps系统，我们构造了六个不同的硬件加速器。结果表明，基于GraphOps的加速器能够在接近硬件平台的带宽限制的情况下运行，这是图形分析计算的限制条件。

介绍

随着图成为处理基于网络的非结构化数据的更不可或缺的工具，在图上执行的操作的能效开始变得尤为重要。专用的硬件加速器通常可提供显着的每次能源性能优势，但被认为笨重且难以编程。GraphOps为硬件设计人员提供了一组可组合的，特定于图形的构建模块，这些模块是实现各种图形分析算法所必需的。该系统建立在数据流执行平台上[17]。基于GraphOps的加速器被定义为一组块，其中图形数据流传输到内存或从内存流化，并且计算元数据通过GraphOps块流化为输入和输出。
大多数图形数据结构本质上都是稀疏的-实际上，它们通常在磁盘上表示为稀疏矩阵。当试图遍历顶点的边缘以访问其邻居时，这种稀疏表现为空间局部性的缺乏。我们通过使用修改的存储表示来增加空间局部性并在GraphOps块内启用逐元素并行性来解决此问题。基于GraphOps的加速器在主机上对图形进行预处理，并使用我们修改后的存储格式将其存储在FPGA存储空间中。 GraphOps的设计内置了诸如流控制，输入缓冲，速率调节以及主机/中断交互之类的顽固硬件实现细节，极大地减少了设计时间。

• 我们提供了一个灵活的模块化硬件模块库，可用于构建用于高性能流图分析的加速器。
• 我们描述了一种新颖的图形表示形式，该图形表示形式被优化用于合并访问图形元素的属性。此数据结构在所有交流加速器中都使用
• 我们说明了GraphOps库如何用于构造新的加速器。作为案例研究，我们将在第4节中构造一个PageRank加速器。
• 我们通过实现六个不同的硬件加速器，在FPGA平台上对硬件库进行原型设计。在第6节中，我们通过与两种不同类型的软件系统进行比较，介绍了硬件的评估结果。

背景

数据流体系结构

数据流体系结构是一种特殊的计算机体系结构，其中没有传统的程序计数器。取而代之的是，处理的执行是由数据输入到以内核处理器表示的指令的流和可用性来确定的。数据从内存流到内核，也流到内核处理器之间。该计算模型有时被称为“空间处理”模型。该架构消除了对功能的需求，例如指令解码，分支预测或乱序逻辑。它已成功用于数字信号处理，网络路由和图形处理等应用中。

局部优化图形表示

图分析代码的计算性能通常受存储带宽的限制。由于图形数据结构固有的稀疏性，缺少空间局部性加剧了存储约束。不幸的是，FPGA和其他加速器系统的存储控制器通常针对吞吐量进行了优化-具有粗粒度的宽存储通道。由于GraphOps库在很大程度上依赖于数据并行化，因此在标准图形数据结构上对GraphOps的执行会严重受此内存瓶颈的困扰。为了在使用FPGA存储器系统时解决此问题，我们提出了一种新颖的局部优化图形表示，该图形表示使用冗余权衡局部性的紧凑性。

传统图表示

对于表示计算机内存中图形的数据结构，已有大量的先验研究。图形格式是根据诸如图形的大小，其连接性，所需的紧凑性，在图形上进行的计算的性质以及图形中数据的可变性等因素设计和优化的。常见的格式包括压缩稀疏行（CSR），坐标列表（COO）和ELLPACK（ELL）。压缩稀疏行格式由顶点数组（或节点数组）和边数组组成。这些数组及其关联的图形如下显示。顶点数组由顶点ID（整数）索引。顶点数组中的数据元素充当边数组的索引，边数组存储每个边的目标顶点。

局部优化图形表示

边缘数组是一种用于读取邻居列表的有效数据结构。但是，当访问邻居集的关联属性时，系统必须对属性数组执行随机访问。通过访问图1中的属性数组可以直观地看到这种散射效果。不幸的是，访问邻居属性是图形算法中的常见范例-许多重要的计算都与顶点邻居的数据元素有关。我们建议添加图中也显示了一个新的数据结构，称为局部性优化阵列。该数组存储边缘邻居的属性，而不是边缘列表。现在可以在没有随机访问的情况下读取邻居属性，从而大大提高了空间分辨率。仍然对原始属性数组执行更新。

一个例子

在详细介绍GraphOps块及其体系结构之前，让我们首先激励该库，并说明如何使用这些组件来构成实际的应用程序。我们将专注于一种众所周知的算法PageRank [15]。我们假设加速器与主机系统上的主应用程序一起运行。我们以三种类别介绍应用程序的构建：块选择，块参数化和块组成。在详细介绍GraphOps块及其体系结构之前，让我们首先激励该库，并说明如何使用这些组件来构成实际的应用程序。我们将专注于一种众所周知的算法PageRank。我们假设加速器与主机系统上的主应用程序一起运行。我们以三种类别介绍应用程序的构建：块选择，块参数化和块组成。

块选择

PageRank加速器需要执行三个功能：
1.为每个顶点获取必要的数据属性集（在本例中为相邻顶点的PageRankscores）
2.执行核心算法描述的算术归约运算
3.通过在每次迭代后更新数据结构来存储更新后的值。
对于PageRank，使用的高级块为ForAllPropRdr，NbrPropRed和ElemUpdate。

块参数化

一旦选择了一组块，则必须正确配置它们以对内存中的正确图形执行特定的计算。参数被实现为静态输入，由主机系统通过PCIe总线驱动。每个模块都需要一些本地参数，这些参数是定制所需的。还可以修改全局加速器级别的参数。几个不同块使用的一个常见参数是属性数组的内存地址。发出存储请求的任何块都必须具有该基址，从中可以确定特定图形元素的存储位置。

块组合

块组成构建加速器的最后一步是将所有块组合在一起以形成功能系统。每个块的元数据输出被路由到下游块上的随附输入。存储器请求信号通过存储器接口单元路由。图3显示了PageRank算法中使用的块的详细框图。

硬件设计

PageRank GraphOps的枚举

GraphOps库可分为三类：数据块，控制块和实用程序块。我们枚举PageRank中使用的每个类别的块。

数据处理块数据块

是主要的GraphOps组件。它们处理传入的数据流，执行算术运算，并将输出路由到内存或后续块。
ForAllPropRdr
向图中的所有neighbor属性集发出内存请求。为此，它首先读取图形中的所有行指针。传入的行指针数据用于为每组邻居属性发出单独的内存请求。
NbrPropRed
对顶点的邻域集进行归约。该单元从存储器接收邻居属性数据作为数据流。每组邻居属性都伴随有一个元数据包，作为前一个块（例如ForAllPropRdr）对内核的输入。
ElemUpdate
用于更新图形数据结构中的属性值。该单元接收顶点参考和更新的值作为输入。它发出对必需的存储器位置的存储器读取请求，以及对更新后的值的存储器更新请求。

控制块

在GraphOps中，大多数逻辑适用于数据流。其主要原因之一是反馈控制很少。但是，在某些情况下，需要没有状态机就很难表达更为复杂的控制。 PageRank应用程序的关键控制块有：
QRdrPktCntSM
处理数据块中输入缓冲区的控制逻辑。常见的用例发生在以下情况中：元数据输入数据指示显示许多内存包属于给定的邻居集。 QRdrPktCntSM处理内存数据输入上的数据包计数，并指示数据块何时移至下一个邻居集。
UpdQueueSM
处理控制逻辑以更新所有节点的agraph属性。该单元假定属性是按顺序更新的，并利用大量合并来最大程度地减少发送到内存的最新请求的数量。

实用程序块

需要附加逻辑才能正确连接主题系统和主机平台。这些是通过实用程序块实现的：
EndSignal
监视所有数据块的完成信号，并在所有单元完成后发出特殊的中断请求以中止执行。
MemUnit
为数据块提供了简化的内存接口。它编译内存配置信息，监视执行结束中断请求，并包括用于处理非常大的内存请求的控制逻辑。

应用

我们使用GraphOps块为六种分析算法实现加速器。表1细分了每个加速器的资源使用情况，并列出了其实现中使用的GraphOps组件。 Xilinx Virtex-6 FPGA上的片上资源均未绑定任何加速器。

流对比

通过与称为X-Stream的图形处理框架进行比较，我们继续对GraphOps库进行评估。 X-Stream框架是一个合适的选择，因为与GraphOps中使用的局部优化存储表示类似，X-Stream的构建是围绕最大化图数据的顺序流，同时最大程度地减少随机访问。潜在的观察结果是顺序内存带宽通常比随机访问带宽高得多，尤其是对于不适合主内存且需要磁盘访问的图形。

我们从Stanford SNAP项目中选择了各种不同的数据集用于此比较研究。使用的数据集为：amazon0601，cit-Patents，Wiki-Talk，web-BerkStan和soc-Pokec。我们为读者提供有关数据集的详细特性的参考。图6比较了GraphOps和X-Stream框架针对所讨论的工作负载的执行时间。指标是执行运行时间，因此越低越好。这两个框架都在同一台机器上执行，如本节开头所述。 X-Stream是纯软件框架，使用了主机系统CPU和内存资源，忽略了FPGA。该图提供了三个基于GraphOps的加速器的总执行时间的细分。 尽管GraphOps加速器的可用总带宽略逊一筹，但相关工作与X-Stream应用程序比较更有利。读者应首先注意，LO阵列的准备和维护开销（表示为graphops（散点图））是每种实现的总运行时间的一小部分。spmv和pager最具问题的数据集-ank加速器是Wiki-Talk和cit-Patents。这两个加速器都依赖于对顶点邻居属性的有效访问。 Wiki-Talk和cit-Patents次优，因为它们的平均度相对较小，分别为Wiki-Talk和cit-Patents的2.1和4.3。回想一下我们对目标硬件系统的讨论，内存访问被限制为相当大的数据块。确实，我们考虑到了这一点，在第3节中设计了局部优化存储表示。因为我们的系统基本上是使用大数据块来获取邻居属性集而设计的，所以小程度的数据集（例如Wiki-Talk和cit-Patents）会浪费大量为此目的指定的带宽。鉴于GraphOps在soc-pokec-relationships数据集上的平均性能为19.1，该性能也得到了证实。

相关工作

有几种方法使用FPGA作为加速图形分析的工具。 Betkaoui等人使用优化的交叉开关和自定义存储库在FPGA上加速了小图计数算法。他们的工作不同于GraphOps，因为他们的框架要求最终用户将其算法表示为以顶点为中心的内核，类似于Pregel 。他们进行将其映射到Convey硬件系统的工作。 Nurvitadhi，Weisz等人为称为GraphGen的图算法编译器创建了一个FPGA后端。它们还只关注以顶点为中心的图形描述，这与GraphOps的重要区别在于GraphOps的设计更为笼统。 DeLorimier等人提出了Graph-Step，这是一种适合于FPGA的块存储器的稀疏图的系统架构。尽管总体上来说，它们的体系结构在可能的数据集大小上受到了严格的限制，特别是在数据集大小和DRAM组迅速扩展的时代。在使用流式范式处理图形的领域也有一些工作。 Ediger等人使用称为STINGER的动态图形表示来提取并行性并启用流处理。 Roy等人提出了X-stream，我们在第6节中介绍过。GraphOps与这些方法不同，因为它们都是以软件为重点的工作。另一个主要区别是，这些方法试图更好地利用内存层次结构，而GraphOps则依赖于主内存带宽。

总结

在本文中，我们介绍了GraphOps硬件库，这是一组可组合的硬件模块，使设计人员可以快速创建节能的图形分析加速器。使用著名的计算PageRank作为驱动示例，我们解释了GraphOps如何解决设计师原本会花费宝贵时间来解决和验证的问题。我们通过组合六个不同的加速器并使用它们来处理各种工作负载来评估GraphOps库。我们将其与纯软件实现以及软件流框架进行比较。结果表明，基于GraphOps的加速器能够在FPGA系统的带宽极限附近运行。总体而言，本文证明，如果给硬件设计人员一组有用的构建块，则可以通过大幅减少设计时间来实现图形专用的FPGA加速。在本文中，我们介绍了GraphOps硬件库，这是一组可组合的硬件模块，使设计人员可以快速创建节能的图形分析加速器。使用著名的计算PageRank作为驱动示例，我们解释了GraphOps如何解决设计师原本会花费宝贵时间来解决和验证的问题。我们通过组合六个不同的加速器并使用它们来处理各种工作负载来评估GraphOps库。我们将其与纯软件实现以及软件流框架进行比较。结果表明，基于GraphOps的加速器能够在FPGA系统的带宽极限附近运行。总体而言，本文证明，如果给硬件设计人员一组有用的构建块，则可以通过大幅减少设计时间来实现图形专用的FPGA加速。