libgrape-lite on GPUs：GPU助力加速图分析任务

在之前的文章中，我们介绍了 GraphScope 背后的图分析引擎原型 GRAPE 系统以及其开源实现 libgrape-lite。本文将介绍 libgrape-lite 的新功能：利用 GPU 来处理 PIE 模型下的图分析任务。这项新功能能够使用户无感地将图分析任务迁移到 GPU 上，利用其高并发高带宽的特性，来加速图分析任务以获得更高的性能。

背景

图分析任务是大数据场景下一类关键基础任务，它支撑着社交、物流、分析、通信等多个场景下的重要应用。学术界和工业现有的引擎有 PowerGraph，Pregel，Spark GraphX 等。在之前的文章中，我们介绍了 GRAPE 系统及其 C++ 的开源实现库 libgrape-lite。GRAPE 能够复用现有的单机顺序算法代码，将串行的图算法并行化。同时，它有着坚实的理论保证，能够确保自动并行化的正确性和终止性，从而降低了编写复杂图算法对用户的门槛。libgrape-lite 作为 GRAPE 的核心实现，支持着阿里集团内各种图计算相关业务，并取得了良好的效果。同时，libgrape-lite作为一站式图计算平台GraphScope图分析引擎，为GraphScope提供迭代式图分析的能力。

长久以来，图分析任务这类数据密集型的负载都在 CPU 上进行。但是随着近年来各种新兴硬件的出现，让人们逐渐意识到利用加速卡（例如 FPGA、GPU）搭建异构计算平台的潜力。这些加速卡往往有更高的并行度，例如一块 Nvidia V100 GPU 能提供 5K+ 的计算核心，同时它们也有着更高的取数能力，例如 HBM2 能提供近 1TB/s 的内存带宽。许多任务已经利用这类加速卡获得了巨大的性能提升，例如深度学习、图像处理等，图计算也不例外。近年来，学术界有不少工作研究了利用 GPU 加速图算法的潜力，例如 Cusha、Medusa、Gunrock、Groute等。这些图计算引擎将 CPU 上的成熟的图算法及其优化迁移到了 GPU 上，但是没有针对 GPU 的平台特征或是输入数据的特征进行特定的优化，因此这些图计算系统的性能往往达不到 GPU 专家编写的图算法实现的性能。另一方面，在 GPU 上进行图算法开发相比在 CPU 上更加复杂，普通用户需要花费大量的精力和时间去调优 GPU 图算法实现才能达到较好的性能。

为了进一步提升 libgrape-lite 的性能，我们在最近的更新中为其添加了 GPU 加速的新特性(本文中称之为libgrape-lite-gpu)。它和其他工作最大区别就是其灵活性，为用户提供了多种优化选项，用户只需根据输入数据进行优化选项的选择即可获得接近手工调优的图算法性能，同时它继承了 PIE 模型强大的自动并行能力，只需要用户按照 PIE 编写串行程序，libgrape-lite-gpu 就能将其部署到 GPU 平台上，完善了 libgrape-lite 对异构硬件的支持。最后，libgrape-lite (及其GPU feature) 是完全开源的。它将持续集成社区内开发的优化，不断适应更多场景并获得更高的性能。

CPU vs. GPU

上图展示了 CPU 和 GPU 在架构上的区别。CPU 上的部件相对复杂，绝大部分面积都填满了诸如预取、分支预测、缓存等用于提升 CPU 核计算效率的部件，因此 CPU 能处理复杂的逻辑。与 CPU 相比，GPU 的部件更简单，但是它堆叠了大量的核，并有着更长的流水线。GPU处理数据时，以 SIMT (Single Instruction, Multiple Threads) 的方式进行工作，它们通常是 32 个线程为一组（部分 GPU 是 64 个一组），称之为线程束（Nvidia GPU 中称为 warp，AMD GPU 中称为wave）。这些线程束会同时执行同一个指令流，且 GPU 依赖 warp 调度器来隐藏取数延迟。另一方面，GPU的内存层次更多，它需要控制数据在主存、显存、片上共享内存、向量寄存器之间移动。

展示了 CPU 和 GPU 在具体硬件参数上的区别。在计算能力上，与 CPU 相比，GPU 具有更多的核数。这意味着它能同时处理更多的数据，有着更高的并行度。而恰好图算法的并发度天生就很高，其每一个点都可以作为一个并行粒度，因此 GPU 处理图算法时有着更高的吞吐率。但是 GPU 的每个核更弱，且时钟频率更低，这使得 GPU 在面对负载不均衡时，会产生严重的长尾效应，因为此时大部分 GPU 核闲置在等待少数几个弱核完成计算。不幸的是，图数据天生具有非规则性，边的分布严重倾斜，少部分顶点却拥有绝大部分边，而大部分顶点只有少数几条边与之相连。

在内存访问能力上，GPU 有着更高的带宽。例如，Nvidia V100 搭载的 HBM2 带宽达到 1TB/s。当 GPU 内 warp 访问相邻的数据块时，可触发联合访存，即将多个访存请求合并成一个请求，这使得 GPU 在处理大量数据时比 CPU 更有优势。而图算法，尤其是并行图遍历算法，需要同时处理大量的边数据。虽然 GPU 的内存带宽要强于 CPU，但是图算法的访存模式具有不可预测性，图算法往往需要从内存中随机地存取大量的数据，且每次只触及极小的一块内存（通常是点的状态，在图分析任务中不会很大）。这使得内存带宽的效率极低，常常达不到理论峰值。GPU 的内存容量远小于 CPU，这使得 GPU 很难处理较大规模的图数据，GPU 也很难实现一些对内存要求很高的算法，尤其是一些需要存储大量中间结果的图挖掘任务。

综上所述，GPU 为图计算带来了新的机遇和挑战。虽然在 GPU 上有着诸多限制，但是 GPU 的确有着更高的潜力能带来更强的性能。而且近年来以 GPU 为代表的异构计算平台发展迅猛，作为顶尖算力代表的超级计算机也纷纷采用异构计算的设计，例如美国的 Summit 超算 就是由大量的 Nvidia V100 GPU 构成。随着技术的发展，未来异构计算会越来越灵活成熟。但是 GPU 架构与 CPU 架构的差距是巨大的，直接将 CPU 上的算法实现照搬到 GPU 上并不能获得更高的性能，反而还可能导致性能下降。为了充分探究 GPU 处理图任务的潜力，我们为 libgrape-lite 新增了 GPU 支持，使其能在有 GPU 条件时，利用硬件资源来加速图分析任务。

将 PIE 迁移到 GPU

在 libgrape-lite 的文章中，我们介绍了 GRAPE 的 PIE (PEval-IncEval-AssEmble) 模型，仅需要用户提供核心的函数：

• 用于局部计算的函数 PEval：一个单机的顺序图算法；
• 用于增量计算的函数 IncEval：一个单机版本的增量算法；

GRAPE 会根据进程的数量，将图分为数个 Fragment，并在每个 Fragment 上串行执行局部计算 PEval，再将跨Fragment 的更新通过消息传播到其他进程，并调用增量计算的 IncEval 来串行地处理更新。在 libgrape