Gemini原论文的PageRank实现比Plato快三倍？

[charlygao]

我基于twitter-2010数据集测试PageRank算法。在相同配置的机器上，Gemini论文实现比Plato的实现（0.1.1 Release）快三倍。请问可能是什么原因？官方是否可以分享一下Benchmark数据？

测试结果显示，Gemini实现和论文中的描述性能接近。而Plato实现性能差很多。

=========================

测试机器：32C64G Docker * 2

Plato运行参数：
mpiexec.hydra -hostfile hostfile -n 2 -bind-to none -map-by node plato-pagerank --threads=32 --input=hdfs://PATH_TO/twitter-2010/ --damping=0.85 --iterations=96 --eps=0.0001 --output=hdfs://PATH_TO --is_directed=false

Gemini运行参数：
mpirun --hostfile /workdir/hostfile -n 2 -bind-to none -map-by node gemini-pagerank twitter-2010.bin 41652230 96

Plato运行结果：
总耗时 190.01s | 读HDFS 18.71s | 构图 16.54s | 迭代数 96 | 平均每迭代耗时 1.57s
详细：
I0525 16:35:15.599259 6398 pagerank.cc:125] [epoch-92] init-next cost: 0.054s
I0525 16:35:16.933455 6398 pagerank.cc:145] [epoch-92] message-passing cost: 1.334s
I0525 16:35:16.947115 6398 pagerank.cc:174] [epoch-92] foreach_vertex cost: 0.014s

Gemini运行结果：
总耗时 101.2s | - | 构图 58s | 迭代数 96 | 平均每迭代耗时 0.45s

Gemini论文中的数据（Gemini: A Computation-Centric Distributed Graph Processing System，Table 3: 1-node runtime on input graph twitter-2010）：
48C128G * 1 | 迭代数 20 | 平均每迭代耗时 0.63s

[skyssj]

柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 BSP 的方式（Gemini 和大部分分布式离线计算框架所采用的方式，每轮通讯需要缓存住所有产生的消息），而是采用了类似流式的方式进行通讯，但是也会损失一定的性能。具体的，最底层的通讯代码一般会使用 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L506 这个方法，您可以通过调大 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L62 这个参数中的 global_size_ 和 local_capacity_ 来使其退化成 bsp。

[charlygao]

柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 BSP 的方式（Gemini 和大部分分布式离线计算框架所采用的方式，每轮通讯需要缓存住所有产生的消息），而是采用了类似流式的方式进行通讯，但是也会损失一定的性能。具体的，最底层的通讯代码一般会使用 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L506 这个方法，您可以通过调大 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L62 这个参数中的 global_size_ 和 local_capacity_ 来使其退化成 bsp。

你好，我尝试将https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L62 中的这两个值改大，性能反而下降了。

原始值 global_size_ = 16 * MBYTES, local_capacity_ = 4 * PAGESIZE
测试结果：1.57s / iter

修改后 global_size_ = 512 * MBYTES, local_capacity_ = 128 * PAGESIZE
测试结果：2.68s / iter

[charlygao]

柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 BSP 的方式（Gemini 和大部分分布式离线计算框架所采用的方式，每轮通讯需要缓存住所有产生的消息），而是采用了类似流式的方式进行通讯，但是也会损失一定的性能。具体的，最底层的通讯代码一般会使用 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L506 这个方法，您可以通过调大 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L62 这个参数中的 global_size_ 和 local_capacity_ 来使其退化成 bsp。

你好，如有时间麻烦看一下楼上的测试结果是否符合预期，非常感谢！

[jievince]

我觉得和plato没有把线程绑定到NUMA node上有关

[skyssj]

柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 BSP 的方式（Gemini 和大部分分布式离线计算框架所采用的方式，每轮通讯需要缓存住所有产生的消息），而是采用了类似流式的方式进行通讯，但是也会损失一定的性能。具体的，最底层的通讯代码一般会使用 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L506 这个方法，您可以通过调大 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L62 这个参数中的 global_size_ 和 local_capacity_ 来使其退化成 bsp。

你好，如有时间麻烦看一下楼上的测试结果是否符合预期，非常感谢！

唔，不符合预期，还有一个参数可以调大 flying_send_per_node_ 。plato 开发完毕后是有同 gemini 做过对比的，但是比您使用的图要大得多，大概是亿级节点，百亿边，在 pagerank 等基础图算法上，性能是差不多的，但是因为时间久远，原始对比结果遗失了。

我觉得和plato没有把线程绑定到NUMA node上有关

嗯，的确这也是一个可能的原因，但因为我们的测试环境都是云环境，绑核操作都是由资源调度程序代劳了，所以在我们的测试结果中程序中显示的绑核收益并不明显。

[charlygao]

柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 BSP 的方式（Gemini 和大部分分布式离线计算框架所采用的方式，每轮通讯需要缓存住所有产生的消息），而是采用了类似流式的方式进行通讯，但是也会损失一定的性能。具体的，最底层的通讯代码一般会使用 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L506 这个方法，您可以通过调大 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L62 这个参数中的 global_size_ 和 local_capacity_ 来使其退化成 bsp。

你好，如有时间麻烦看一下楼上的测试结果是否符合预期，非常感谢！

唔，不符合预期，还有一个参数可以调大 flying_send_per_node_ 。plato 开发完毕后是有同 gemini 做过对比的，但是比您使用的图要大得多，大概是亿级节点，百亿边，在 pagerank 等基础图算法上，性能是差不多的，但是因为时间久远，原始对比结果遗失了。

我觉得和plato没有把线程绑定到NUMA node上有关

嗯，的确这也是一个可能的原因，但因为我们的测试环境都是云环境，绑核操作都是由资源调度程序代劳了，所以在我们的测试结果中程序中显示的绑核收益并不明显。

您好，我做了进一步的测试，定位Plato迭代运行速度缓慢的原因在于一个SuperStep中，存在明显的长尾线程。其根因是twitter-2010数据集中，vid 23934021~23934210 区段存在大量的百万出度顶点，导致处理这个区段的单线程运行缓慢。

Gemini通过线程工作窃取机制来解决这个问题，而我在Plato代码中没有找到相关实现，请问Plato是否有对这种情况有解决方案？

[lidong19941207]

柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 BSP 的方式（Gemini 和大部分分布式离线计算框架所采用的方式，每轮通讯需要缓存住所有产生的消息），而是采用了类似流式的方式进行通讯，但是也会损失一定的性能。具体的，最底层的通讯代码一般会使用 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L506 这个方法，您可以通过调大 https://github.com/Tencent/plato/blob/master/plato/parallel/bsp.hpp#L62 这个参数中的 global_size_ 和 local_capacity_ 来使其退化成 bsp。

你好，如有时间麻烦看一下楼上的测试结果是否符合预期，非常感谢！

唔，不符合预期，还有一个参数可以调大 flying_send_per_node_ 。plato 开发完毕后是有同 gemini 做过对比的，但是比您使用的图要大得多，大概是亿级节点，百亿边，在 pagerank 等基础图算法上，性能是差不多的，但是因为时间久远，原始对比结果遗失了。

我觉得和plato没有把线程绑定到NUMA node上有关

嗯，的确这也是一个可能的原因，但因为我们的测试环境都是云环境，绑核操作都是由资源调度程序代劳了，所以在我们的测试结果中程序中显示的绑核收益并不明显。

您好，我做了进一步的测试，定位Plato迭代运行速度缓慢的原因在于一个SuperStep中，存在明显的长尾线程。其根因是twitter-2010数据集中，vid 23934021~23934210 区段存在大量的百万出度顶点，导致处理这个区段的单线程运行缓慢。

Gemini通过线程工作窃取机制来解决这个问题，而我在Plato代码中没有找到相关实现，请问Plato是否有对这种情况有解决方案？

你好，gemini的测试是自己实现的吗，有开源吗。