Tencent
Gemini原论文的PageRank实现比Plato快三倍？
我基于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
柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 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。
柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 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
柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 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。
你好，如有时间麻烦看一下楼上的测试结果是否符合预期，非常感谢！
柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 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上有关
嗯，的确这也是一个可能的原因，但因为我们的测试环境都是云环境，绑核操作都是由资源调度程序代劳了，所以在我们的测试结果中程序中显示的绑核收益并不明显。
柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 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是否有对这种情况有解决方案？