MPI并行程序实现并行计算后未提速反而耗时增加问题

你这个代码进程越多跑的越慢，和阿姆达尔定律没有关系，全是代码逻辑错误导致的，共有三个致命问题：

• 把MPI集合通信塞到了内层热循环里
  你把MPI_Reduce写在了执行1000万次的外层循环内部，每跑一次迭代就要做一次全进程同步+数据归约。MPI集合通信的开销是随进程数上涨的：多一个进程就要多做一次进程间数据拷贝、多等一个进程的同步信号，通信延迟是线性甚至超线性增长的。你单次循环里的计算量也就几十条CPU指令，耗时几纳秒，而一次进程间通信至少要几微秒，开销差了三个数量级。进程加的越多，花在通信等同步上的时间就越长，直接把并行省的那点计算时间全吞了还倒贴。
• 总计算量随进程数线性上涨，根本没做并行拆分
  你用来拉长运行时间的1000万次外层循环，是每个进程都独立跑满1000万次的，根本没把循环迭代拆分给不同进程。单进程时总计算量是1000万次迭代，4进程时总计算量是4000万次，总工作量翻了四倍，就算没有任何通信开销，跑的慢都是必然的。你真正拆分的只有斐波那契序列33个位置的计算，这部分工作量小到可以忽略，完全抵不上总工作量的上涨。
• 负载严重不均衡，存在大量无效等待
  你给0号进程写的是整数递推算斐波那契，其他进程用的是pow、sqrt这类慢得多的浮点超越函数，非0进程单步计算耗时是0号进程的好几倍；同时你用整数除法给计算分块的时候没处理余数，最后一个进程的计算量和其他进程不一致，同步的时候快的进程要等慢的进程，白白浪费CPU时间。

1. 把MPI_Reduce挪到1000万次外层循环的外面，所有进程先跑完本地的全部计算，最后只做一次结果汇总就行，绝对不要在高频执行的热循环里放集合通信操作。
2. 如果要靠外层循环压测并行性能，必须把外层循环的迭代范围按进程rank拆分：比如总共1000万次迭代，2进程就每个跑500万次，4进程每个跑250万次，保证不管开多少进程，全局总计算量和单进程时一致，而不是每个进程都跑全量迭代。
3. 统一所有进程的计算逻辑，不要给0号进程单独写“快速路径”，保证每个进程单步计算的耗时基本一致，减少同步等待的空耗。
4. 斐波那契偶项求和本身计算量极小，单进程跑也就几纳秒的事，根本测不出来并行加速效果。要测加速比至少要把单进程计算耗时拉到秒级，且通信开销占总耗时的比例低于10%，测出来的数据才有参考意义。

内容的提问来源于stack exchange，提问作者Ammons_k