skyssj

是的，plato在做数据映射时并没有考虑原始数据的分布情况。

目前柏拉图没有提供 java api，如果您有兴趣贡献这部分功能，我们非常欢迎。

柏拉图为了使用较小的机器资源也能完成超大图的计算，在通讯时舍弃了 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上有关...