首先再次感谢T大和N大花时间解决我的问题 ^^ 我知道资料的传输多少会使用CPU 也不期望边传输边运算可以盖住全部传输的时间 我并不清楚Irecv会造成block? 这似乎和我的理解有所出入 不过即便是如此 我也试着写Pthread的程式 除了他有没事做的一颗CPU让我使用外 的确会完整的盖住传输时间 不过这意味我非得空着一颗CPU专作传输 非常的浪费 在使用MPI同时Run两个Job的情况下 就如同我所说的 在barrier之後 一点都没省下时间 你们的意思是 这是因为load balence的问题 不过在我的sample code里 所有的node做的事情是一模一样 会造成快慢的差异 应该只是单纯的因为多个thread抢CPU资源造成的 我的sample code的确什麽事情都没做 因为我只是想单纯的简化传输与运算是否可以并行的问题 我试着让Isend Irecv在传输时 使用sleep让CPU Idle 期望可以在CPU Idle时 能全力进行资料的传输 可是实测下 我分别对sleep和waitall两个函式计时 sleep就是五秒 而wait的时间却一丁点都没少 维持原样 意思是 在只有传输的情况下 花了4.7秒 加上了sleep 他刚好就是9.7秒 这意味着 Isene Irecv 并没有在背後进行资料的传输 直到 wait时 才开始传输资料 我也试着用繁杂无意义的运算取代 sleep 不论运算花多少时间 1~100秒的范围都试过 结果依然没省下时间 总时间就是运算加上传输 运算时间如果再长一点 运算的时间误差就跟传输时间差不多 义义似乎不太大 再者wait的时间就刚好是原来的传输时间 实在很难让人相信他在背後有传输 我知道平行运算load balance是很重要的一环 overhead主要就是资料交换与程式内不能平行运算的部分 不瞒您说 我也是试着在处理我的模拟平行化的load balance的问题 我只是想最佳化程式的效率 却注意到Isend和Irecv并没有省到时间的问题 才写出这个只有传输和无意义运算的简化的code 我的原始问题当然不是长这个样子 我现在想要了解的是 到底要如何 才可以让Isend Irecv在背後传输 替我省下一点传输的时间 谢谢 ^^ ※ 引述《neutronstars (I'm...)》之铭言： : ※ 引述《justdemon (人生的转捩点)》之铭言： : 以你的程式来看， : 即使你用的是nonblocking send， : 但是node本身接收资料就是得耗费时间，也就是在recv时， : 是blocking的状况，所以，当然是没办法同时运算， : 除非你有另一个thread另外在处理计算的问题， : 否则那个recv所在的thread就是会被blocking。 : 有些node较快、有些较慢，这是牵涉到load balance的问题， : 这问题甚至可以当个研究方向了， : 不过在你的sample code看起来是没有处理这种问题，所以会发生这种现象应属正常。 : 如果你是研究生，可以用此关键字查查paper，会找到很多相关的paper。 : : 谢谢T大的推文 : : 可是在我测试的环境相当的简单 尽量让每个process做相同的事情 : : 我最原始的测试的code如下 : : http://nopaste.csie.org/b2860 : : 经过测试之後发现 那个sleep(5) 就真的五秒都在那里睡 背後并没有继续传输 : : 我也试过用其他运算取代sleep 结果一样 : : 全部的时间 就是刚好等於 传输时间+运算时间 : : 他的行为就像是 Isend只是标示出来有个东西要传 直到wait的时候才开始传输 : : 我也试过用MPI_Init_thread取代MPI_Init 结果也一样 : : 不知道有没有板友方便帮我测试一下这个简单的程式呢? : : 谢谢 ^^ : 一般来说，平行计算第一个要考虑的问题就是「如何切割job？」， : 最简单的作法，是先把整份工作切成相等於你的运算node数量， : （这里假设有4个node，所以就是切成四份job） : 每个node就处理自己的那一份，理想上，可以获取4倍效能提昇， : 但是为了要把这些「工作资讯」传递给其他node，或是node彼此之间的小沟通， : 所以会有「communication overhead」存在，所以一般来说效能提昇只会<= 4， : 不过这个也是有例外的，这边就不多提。 : 因为从你的文中不太清楚你想要做的处理是什麽， : sample code里面似乎也没有做计算处理的部份， : 而且你的code似乎是写成每个node都拿到整分资料， : 所以你的「传输成本」应该会很高才是。 : 希望有解答你的问题。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 219.71.218.214