Huangjian's Blog

Record


  • Home

  • About

  • Tags

  • Categories

  • Archives

  • Search

GCN hardware summary

Posted on 2021-06-10 | In Tech
Words count in article: 1.9k | Reading time ≈ 7

GCN文章总结

有没有可能出现新的数据压缩方式适配GCN的处理模式

[TOC]

UWB-GCN: Hardware Acceleration of Graph-Convolution-Network through Runtime Workload Rebalancing

最早的一篇文章,提出了GCN推理加速的一个最早的设计。主要关注点在数据稀疏以及load balance。

首先是baseline 设计:这个设计也是最早的GCN加速器,然后在baseline的基础上进行workload rebalancing.成为最终设计。

首先在计算模式上,先计算AXW的时候分为两种方式,(AX)W或者A(XW),由于不同的稀疏度,A十分稀疏,X一般稀疏,W比较密集,这里选用A(XW)的计算模式,这样两步计算中都会是SPMM(Sparse Dense Matrix Multiplication), 计算workload会比较小。

SPMM具体的计算方式:由$A\times B = C$变换得到:

$C=\left[\sum_{j=0}^{n-1} A_{j} b_{(j, 0)}, \sum_{j=0}^{n-1} A_{j} b_{(j, 1)}, \ldots, \sum_{j=0}^{n-1} A_{j} b_{(j, k-1)}\right]$

具象表示:()

workload的分配,在假设数据按照行均匀分布的前提下,每两行的数据(3个非0数据)分配到一个PE。

并行化处理的一个划分:

同时他这个一次处理一列带来的效果是:

  1. 很好地提高并行度,可以流水线操作,一次一列交替执行。
  2. 减少片上存储,不需要同时存储整个图,而只需要其中的一列。

主要的架构设计如下:

主要包含以下几个部分:

  • sparse-matrix-memory (SP-MMeM)

    SPMMeM buffers the input sparse matrix A

  • dense-column-memory (DCM)

    DCM buffers the input dense matrix B .

  • task-distributor & Queue (TDQ)

  • PE-array

  • accumulation-buffers-array (ACC).
    ACC buffers the partial results of the resulting matrix C for accumulation.

其中根据稀疏程度TDQ分为两类,在通常稀疏的时候(50%左右),为TDQ1,上图左边。在十分稀疏的时候(90%以上)为TDQ2。

TDQ2采用多级Omega路由网络,同时考虑到MAC可能需要多个周期进行计算,可能会产生RaW冒险,因此两者都配备RaW检查其和Stall Buffer,其处理思路类似于处理器中的scoreboard。

主要的处理顺序是:

  1. 首先计算$X\times W$的时候,是一个一般稀疏矩阵跟密集矩阵相乘,使用TDQ1。
  2. $X\times W$计算的结果中,每计算好一列就可以送到下一个计算序列中,也就是$A\times (X \times W)$这个时候A是极度稀疏矩阵,采用TDQ2进行分发。

由于以上处理方式是建立在load balance的基础上,现在作者主要解决的问题是load imbalance。其中有两种主要的imbalance方式,如下图所示:

  • Local imbalance 主要是相邻的两行之间会有跳跃,也就是波动。
  • Remote imbalance 或者可以说波动的特别大,集中在某些特殊行

两者的稀疏统计直方图可以显示如下:

为此作者进一步改善,提出两种方式解决这个不平衡问题:

  1. Dynamic Local Sharing

    因为这个解决的思路就是将一个比较多的区域平均分到邻域,这也是无法处理Remote Imbalance的原因,

  2. Dynamic Remote Switching

    Remote Imbalance的这个因素需要提前调整一下,加上一个switch操作也就是将特别密集的图调整到其他空白的区域,由此形成local imbalance,进而可以使用上一种方式进一步调整。

过程如下:

HyGCN: A GCN Accelerator with Hybrid Architecture

主要点是在GCN的推理阶段,分成两个阶段专门进行优化,一个是Aggregation,另一个是Combine,这两个阶段可以以流水线方式执行。

首先是在Aggregation,一个节点的邻节点(相隔k个元素,k一般为1,2.)会将他自己的feature聚集给这个节点,这一部分的数据往往是依赖于图的结构,非常irregular和dynamic。而在Combine阶段,则主要执行MLP(Multi-Layer Multiplication )操作,也就是CNN中的全连接操作。主要进行矩阵向量相乘。这部分数据模式是static和regular的,与Aggregation完全相反。

从并行度角度出发:

  1. feature vector 长度更长且多变,可以实现更好的intra-vertex parallalism.
  2. GCN中参数可以共享,进而可以在Combination阶段实现inter-vertex parallelism.

整体架构:

分为四大块:

  • Aggregation Engine
  • Combination Engine
  • Coordinator
  • Memory Access Handler

Aggregation Engine

  • interval shade graph partitioning

    通过数据复用来减少数据的不规律性。

  • window sliding-shrinking methods

    利用稀疏特性来减少数据访存。

这一部分主要是因为Aggregation阶段数据极度不规律已经动态变化,在DRAM中的读取比较杂乱,数据读取耗能大。

  • 使用了gather-based methods

    相比scatter-based methods,这一方法主要是在同步耗能更少。然后结合Edge-Centric PM来增加并行度处理。

  • vertex-disperse processing mode

    相比vertex-concentrated,一个顶点的工作负载都分配给单独的SIMD core。这样的方式延迟大同时负载不均衡,效率低以及浪费了并行度。因此选用vertex disperse。

  • 图划分和稀疏减少

这一部分主要是包括图a的划分,然后进行滑窗操作(顶行对应有数据的地方)然后进行window shrinking(底行回缩到有数据的地方)

Combine Engine

  • Multi granular systolic array
  • 复用参数

这一部分数据比较规律,主要问题是不同线程之间数据复用和同步耗时长。

  • 然后使用MVM-Centric PM 来并行处理MVM计算。

提出了两种模式:

  • Independent Working Mode

    图a这种方式对应了低延时,

  • Cooperative Working Mode

    图b这种方式对应了低能耗

Coordinator

这一设计主要在优化从DRAM中的读取,最开始是混乱的读取,数据地址不规律,不利用cache等发挥作用。

​ 将顺序更改为:

edges > input features > weights > output features

不过这个不跨越batch,也就是后面的batch里高优先级数据不比当前batch里低优先级的数据提前。

GraphACT: Accelerating GCN Training on CPU-FPGA Heterogeneous Platforms

这文章的专注点不同于上两篇文章,这个是在进行训练加速,以上两者是在推理阶段的加速。

核心思想是:

  1. 算法

    算法选择上是在选择合适的算法,其能够得到合适的minibatch, 资源上能够适配BRAM,作者总结了三类算法:

    • Minibatch by sampling GCN layers

      最后一层抽取b个nodes,前一层抽取a·b个nodes,第一层抽取 $a^L \times b$个nodes

    • Minibatch by sampling training graph

      直接从图中抽样,抽样的图更小

    • Remark on notation

    最后通过比较computation to communication ratio得到一个合适的训练算法:

    H. Zeng, H. Zhou, A. Srivastava, R. Kannan, and V. Prasanna. 2019. Accurate, Efficient and Scalable Graph Embedding. In 2019 IEEE International Parallel and Distributed Processing Symposium (IPDPS). 462–471. https://doi.org/10.1109/IPDPS.2019.00056

  2. 消除冗余(有点类似VLSI课程里算法强度缩减)

    消除冗余核心思想是提前计算后面复用较高的单元,根据图的特性有一些具体的算法,这里没有细看。

  3. 并行化加速

架构设计:

  • CPU performs graph sampling, and then converts Gs to Gs,softmax loss ; FPGA performs the forward and backward pass.
  • 通过合适的参数配置,一些图数据在读取到BRAM之后就能够供FPGA一直使用从第一层计算到最后一层。
  • 分为两大块,Feature Aggregation Module & Weight Transformation Module

CPU和FPGA之间的调度:

Eyeriss Notes

Posted on 2020-04-24 | In Tech
Words count in article: 1.5k | Reading time ≈ 5

Eyeriss

system architecture

image-20210605100246725

工作流程:

​ Eyeriss只运行的DNN的推理(inference)阶段,不做训练。

  1. 接受配置流(图中Configuration Bits,1794 b),配置计算模式(卷积核大小,步长;输入大小与维度;输出大小与维度)
  2. 从DRAM中读取数据,计算一层结果,(一层都计算完之后)将结果写回到DRAM
  3. 回到1,重新配置下一层结果

on-chip

两个时钟域,分开独立工作:

  1. Core Clock

    核心的计算单元,在这里运行计算部分,主要包含以下几个部分:

    1. 数据编码解码

      Eyeriss-v1采用RLC编码(游程编码),V2采用CSR编码。这种数据压缩表示能够1. 减少存储空间 2. 降低传输数据量,提升传输速度。特别是数据在ReLU之后,数据中有比较多的0,这种编码方式能极大提升效率。

    2. Global Buffer(108 KB)

      Eyeriss片上一次能够计算一层,因此需要这些一个比较大的存储空间,当filter,ifmap等数据从DRAM中读取之后,先存储到Global Buffer(存储介质为SRAM)中,SRAM相比DRAM,数据读取能耗更小。

    3. PE array(计算单元阵列)

      这里是1214的计算阵列,一个PE中完成一个1-D的卷积运算,PE之间通过*NoC** communicate,每一个PE还有一个local的存储叫spads(scratch pads)。详细信息见后。

  2. Link Clock

    这一部分主要就是控制数据的传输,时钟独立于计算单元。

off-chip

主要就是DRAM,从DRAM中读取数据,一层都计算完之后将结果写回到DRAM,与片上之间有一个异步的FIFO中间层。

整个系统的4级存储hierarchy((由大到小):

DRAM, GLB,inter-PE communication,spads

Eyeriss的主要两部分工作:

  1. 通过数据复用(data reuse)来减少数据流动。
  2. 压缩数据,减少存储与传输。

对应图中结构就是,PE来实现数据复用,编解码部分来压缩数据。

PE array

1-D Convolution Primitive in a PE

每一个PE计算1-D卷积,filter,ifmap,和psum都可以存储在PE中的spads,不需要数据流动:需要存储的大小为:

type size
filter S(卷积核一行中的元素个数)
ifmap S
psum 1

1-D卷积如下所示:

image-20210605100316253

这里图示只是在说明一般的1-D卷积。图示计算模式会分给3个PE来计算,也就是按照右边的划分方式分成3组。

Row-Stationary

在2-D的计算模式中:一个卷积核行数为3,ifmap行数为5的计算过程如下:

image-20210605100342808

运算模式如下:

cycle filter ifmap compute
0 row1-> PE1,1 PE1,2 PE1,3 row1->PE1,1 PE1,1
1 row2-> PE2,1 PE2,2 PE2,3 row2->PE2,1 PE1,2 PE2,1 PE1,2
2 row3-> PE3,1 PE3,2 PE3,3 row3 -> PE3,1 PE2,2 PE1,3 PE3,1 PE,2,2 PE1,3
3 row4 -> PE3,2 PE2,3 PE3,2 PE2,3
4 row5-> PE3,3 PE3,3

按照这样理解,感觉PSUM箭头的方向是反的?在cycle 0是计算PE1,1,然后结果给PE2,1?

PE sets(logical mapping)

在PE sets设计中,一个卷积核大小和R S,ofmap大小为E F,需要的PE sets为$R\times E$

也就是PE sets的行数为卷积核大小,列数为ofmap的行数。

physical mapping

由于PE array的大小固定,不一定适配PE sets的大小,因此需要调整PE sets,进而能够放到PE array中进行计算。

  • PE sets大小超过168(12*14的)

    就将分割行数,一次处理e行,e < E。

  • PE sets宽度大于12的,长度大于14,但是总大小不超过168的

    调整合并到一个PE array中。

举例如下:

image-20210605100405768

AlexNet 信息如下:

image-20210605100429795

  • CONV1 PE sets为11*55,拆解成11*7,图中有两组,每组对应不同的filter channel,使用相同的ifmap channel。同时 Stride为4。并行处理两个channel。
  • CONV2 PE sets为5*27,拆解成5*13和5*14,这两组使用相同的filter channel,因此不是并行处理。
  • CONV3 PE sets为3*13,可以放到PE array中,还可以多并行处理,也就是这里对应4个filter channel。
  • CONV4-CONV5 PE sets也为3*13,但是这里做了另外一种并行化处理。1,2(3,4)组内是同一filter内的channel并行;3,4组与1,2组之间是在对相同的ifmap使用不同的filter。

进一步,如果需要增加并行度:可以考虑增大PE的计算能力:

image-20210605100452681

  • a 相当于将ifmap中的两行存到spad中,PE计算一行之后结果放到相应的PSUM中,然后再开始计算另外一行。

  • b 文章中只讲到了time interleaving,没有过多的细节,我猜测是在PE中有更多的控制细节,控制计算filter 1中的第一个元素再来计算filter 2中的第一个元素,(ifmap)保持不动。

  • c感觉跟b类似,filter和ifmap都交替着来,最后的psum还是将两者相加起来。

    最后实现的大小是:

    type ifmap spad filter spad psum spad
    size 12 * 16b 224 * 16b 24 * 16b

RLC (Run length Coding)

编码示意图如下:5b表示0的数目,16bit表示非零值。

image-20210605100525561

每3组run和level打包成一个64bit的集合,其中最后一位表示是否是编码的最后值。

system modules

GLB

  • 100KB存储ifmap和psum,分成25个bank,根据ifmap和psum需要动态调整。
  • 8KB存储filter,本来大部分都是存储在DRAM中,但是考虑到带宽需求,部分filter存储到GLB中,在计算其他部分的时候预先存储到GLB中。

Network on Chip

  • Global Input Network

    根据ID(row, col)来进行匹配multicast

image-20210605100544979

  • Global Output Network

    基本是Input的反向传输

  • Local Network

    主要是方便psum的流动

PE and Data Gating

针对零元素,不需要计算,因此可以跳过,PE结构如下:

image-20210605100610583

Results

  • 工作频率200MHz
  • 16 bit 定点
  • Alexnet 34.7 frame/s,278mW, VGG16 0.7 frame/s
Jian Huang

Jian Huang

2 posts
1 categories
1 tags
0%
© 2021 Jian Huang | Site words total count: 3.3k