记录一下之前读的论文，防止纸质论文丢失，回顾使用，写的很零散，没有进一步总结。
这篇论文是针对图算法的一个加速，2016MICRO最佳论文，在一堆神经网络加速器中脱颖而出。针对图算法提出了硬件流水线，并紧密结合算法进行了详细的分析和优化，读起来很有趣。
做了PPT，传到了百度文库中，突然想起来不知道下载以后还有没有备注的东西了，基本和下面的内容对应。
摘要
图是真实世界计算应用中关键的数据结构。通用处理器限制图分析的性能和功耗。以此提出本文设计的专用加速器的特点，数据计算和内存子系统，发掘内在并行性、小的重配置模块（灵活性）。
1. Introduction
介绍图分析的应用、现有技术和发展。
目前该领域软件社区设计出许多高效框架，硬件社区也设计了比通用CPU更高效的硬件来执行图分析应用。
三点问题：（1）低效的内存访问粒度；（2）低效的片上存储利用；（3）执行粒度不匹配。
这篇文章的贡献：一个使用专用数据类型和存储子系统的硬件流水线；对微架构进行深入设计，以提高性能和能源效率，发掘更多并行性，使用切片和分块支持大规模图。
2. Background And Motivation
图编程框架目的：1. 容易编程；2. 提高性能；3. 可扩展性。
接下来对图1中编程框架进行了简单的介绍，把点和边进行了定义。介绍了四种图算法，然后将他们分别映射到图编程框架中。
第一个低效原因：图2测试了GraphMat片外存储带宽的使用。其中效率指片外存储搬运与最优情况的比。另：最优->一次迭代有足够的偏上存储空间（不是指两次迭代之间存储足够）。
图2中，BFS和SSSP片外存取更多，因为这两个算法局部性差，按cache行取，但只有一小部分使用，造成带宽浪费。PageRank有更少的随机存取。
第二个低效原因：需要执行许多指令用来移动和提供数据。
解决方案：1. 应用专用内存子系统并将片上存储作为加速器一部分；2. 专用的数据结构和数据类型，并围绕图处理分析原语、顶点、边，设计了专用的数据通路。 实现了灵活性和低能耗。
3. Graphicionado overview
将图分析分为两个步骤，Processing Phase和Apply Phase。第一个对所有的活跃顶点遍历与它们相连的所有边，计算边终点的点的相关值，放入VTempProperty。第二阶段进行更新，将VTempProperty的值进一步计算，放入VProperty对点进行更新。
硬件中将图4中的每一个步骤对应实现为流水线的每一级。从图中可以看出每个阶段具体是顺序存取还是随机存取。图5中P6为原子更新，箭头所画部分的过程为原子的。自定义模块即为图编程框架中自定义函数部分，是每个不同算法中体现其不同计算内容的部分。
4. Graphicionado optimizations
A. 使用片上暂存器
改进目标顶点更新。P6-P9的3点瓶颈：1. 终点的更新中，点的读写都是随机的；2. 更新少于8byte但从片外读写都是一个cache行，浪费带宽；3. 点的更新是原子操作，会经常阻塞流水线。 使用专用大的片上嵌入DRAM暂存器。
改进边ID的存取。P2中eid只有4byte，是随机存取，将其放入片上进行存取。
B. 边的存取模式进行优化
当多有点都是活跃的，每次迭代都需要遍历所有的边的时候，P3中，边的读取是随机的，但因为所有的都要遍历，可以一次进行全部的顺序读出。同样的还有A5。
C. 预取
P1和P3因为是顺序存取，可以很容易做预取。
D. 对称图的优化
无向图处理的时候会保存为对称的有向图，但有向图增加了存取和计算的开销，P5-P9阶段重叠了流水线，只进行一遍的计算。
E. 大的顶点属性的支持
将属性数据分块，对大部分这个加速器中的流水级可以不用等全部的包直接进行处理。
5. Graphicionado parallelization
A. 扩展多条流水线
最简单的方法是将流水线直接复制多条，问题存在：读写片上相同区域。为了避免存储冲突，将源和目的分开。
B. 边的存取并行化
P3中处理边，边的存取可能是随机的，但即使不随机，边的数量也是远大于顶点的数量，别的阶段每拍处理一个顶点，这个阶段每拍处理一条边，明显会将时间变长，此处对边的处理变成并行。
C. 终点存取并行化
P4阶段是随机的存取，会变慢，类似于B中的处理。
6. Scalable on-chip memory usage
片上存储大小有限，这一节讨论的是如何合理使用内存，划分图进行处理。
A. 分割一般图
步骤：1. 根据顶点ID将其分成N份（边的保留依据终点的位置，避免写冲突）
2. 对每一个分块迭代执行之前所描述的计算步骤
B. 对称图
1.生成一个有向图，所有保留的边均为大id指向小id；2. 一共分成N(N+1)/2份，划分成为N份顶点，边的保留分别为其中每两个点集合的一个组合。
文中给了一个调度的图表，因为这样的处理，更新部分必须要在这个点的集合都计算了一遍。
C. 粗化边的ID表