通常，并行图处理的性能由三对关键参数决定，即同步或异步执行模式（Sync或Async），推或拉通信机制（Push或Pull），数据驱动或拓扑驱动遍历方案（DD或TD），这增加了GPU编程和系统实现的复杂性和复杂度。现有的图形处理框架主要在给定应用程序的整个执行过程中使用单一的组合，但是我们已经观察到它们的性能参差不齐和次优。
本文介绍了一个高效的图形处理软件框架SEP-Graph。HyBrid执行模式在三对参数之间自动切换，目标是在每次迭代中实现最短的执行时间。
首先，图算法的执行既可以是同步模式，也可以是异步模式。同步和异步。在同步模式下，一个程序的整个执行被分成多个迭代。需要两个连续迭代之间的显式屏障来同步执行。一个顶点只有在前一次迭代结束后才能看到来自其他顶点的更新。相反，异步模式不需要任何显式障碍。允许顶点尽快看到来自其他节点的更新。
第二，顶点之间的通信既可以用推的方式实现，也可以用拉的方式实现。一旦一个顶点对目的地顶点有更新，该顶点可以主动地将更新推送到目的地，或者被动地让目的地顶点拉出更新。
第三，顶点遍历可以使用数据驱动机制或拓扑驱动机制（DD和TD）。DD区分活动顶点和非活动顶点，并且只区分那些活动顶点，TD对活动节点和非活动节点一视同仁，所有顶点都会被遍历。
文章通过讨论Gunrock和Groute在不同图数据中各有千秋的表现，来展示了在整个执行过程中固定的组合可能是有问题的，因为在每个迭代中的执行时间可能会显著不同。这就促使我们开发一个自适应的混合图形处理软件框架，在该框架中，执行模式可以通过不同的组合自适应地自动改变，以获得最佳的整体性能。论文的核心想法并不复杂，但是
我们需要先回答以下两个关键问题，为我们的系统框架奠定基础。
• 我们能否从执行模式，通信机制和GPU上遍历方案的组合中找到导致给定图算法及其数据集执行时间可变的根本原因？
• 在我们揭示了根本原因并获得了从一种选择转换到另一种选择的观察力之后，我们能不能实现一个轻量级机制来在运行时切换解决方案，以确保系统级开销不会抵消混合的好处？
首先对于迭代算法
数据驱动或拓扑驱动:总体而言，TD的性能优于DD，因为迭代算法通常从所有顶点开始，只有少数顶点在初始阶段满足收敛条件。DD具有工作列表/队列管理开销。这样的开销不能通过在前几次迭代中删除收敛的顶点来抵消，因为只有很少的顶点可以收敛。这种观察适用于不同的数据集。图。4(a，b）显示，当执行模式和通信机制保持不变时，TD总是优先于DD
推还是拉:选择主要取决于图形结构。例如，当与同步相结合时，Push对于高直径图（如road_usa）工作得很好，而Pull对于无标度图（如kron_21)更好。对于高直径图，Push在其原子中产生较少的开销，并且表现出一贯较好的性能，这要归功于所有顶点相对较低的输入/输出度。相反，无标度图中的高in-decree顶点可能会对这种基于原子的推送机制形成瓶颈。在这种情况下，通过分配工作线程逐个主动地从邻居中拉出更新，而不会出现推送中的写-写冲突，pull（无论如何）是有利的。请注意，应同步更新日期；否则，拉将导致读写冲突。
Sync或Async:如果Sync表现出类似的性能趋势，那么Async略好于Sync。一个主要原因是异步的收敛速度更快。因此，在我们的迭代算法混合实现中，异步被赋予比同步更高的优先级。
其次对于遍历算法
数据驱动或拓扑驱动:在大多数情况下，DD的性能优于TD，因为DD匹配这类算法的遍历特性。具体地说，对于高直径图，DD只跟踪一个小的顶点分裂。
推或拉:推和拉有各自的最佳场景，特别是对于无标度图。我们必须包括推和拉作为混合解决方案的候选者。切换的直观性与当前活动顶点的数目，当前活动顶点的总外边和未触及边的数目有关。
Sync或Async:通过使用DD，Async和Sync表现出类似的性能动态趋势，而不管输入图如何。
论文在两组数据集上作实验，一组是 road_usa，它具有典型的稀疏图性质，就是0很多，另一组是kron_21，它有幂律分布的性质，就是度数大的点少，度数小的点很多。
论文实验的算法是，迭代算法pagerank，遍历算法sssp
观察pr的迭代时间变化
我们可以惊喜的发现，随着迭代的进行，图上有些点已经达到收敛，无论是同步或是异步push+DD迭代时间明显开始下降（紫色和黄色）
这也证明切换是有意义的，而切换的根据也可以设置为活跃顶点，
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
