我的MPI经验表明,加速比不会随着我们使用的节点数而线性增加(因为通信成本)。我的经验与此类似:

。
今天,一位发言者说:“神奇地(微笑),在某些情况下,我们可以得到更多的速度比理想的!”
他的意思是,理想情况下,当我们使用4个节点时,我们会得到一个4的加速比。但是在某些情况下,我们可以得到大于4的加速比,有4个节点!这一主题与MPI有关。
这是真的吗?如果是的话,有人能提供一个简单的例子吗?或者他正在考虑在应用程序中添加多线程(他没有时间,然后不得不尽快离开,因此我们无法讨论)?
发布于 2015-10-06 13:52:06
并行效率(加速/并行执行单元的数量)在统一性上并不少见。
造成这种情况的主要原因是并行程序可用的总缓存大小。有了更多的CPU(或核心),就可以访问更多的缓存内存。在某种程度上,很大一部分数据适合缓存,这大大加快了计算速度。另一种看待它的方法是,您使用的CPU /核越多,每个CPU所获得的数据的部分就越小,直到该部分真正适合单个CPU的缓存。不过,这迟早会被通信开销取消。
此外,与单个节点上的执行相比,您的数据显示了速度的提高。使用OpenMP可以消除使用MPI进行内部数据交换时的一些开销,因此与纯MPI代码相比,可以提高速度。
这个问题来自于错误使用的术语理想加速。理想情况下,可以考虑缓存效果。我宁愿使用线性代替。
发布于 2015-10-06 13:51:25
不太确定这是什么话题,但这没什么.
当您在内存中使用MPI分配数据时,当您并行处理代码时,这种速度上的超线性通常会发生。在某些情况下,通过将数据分布在多个节点/进程之间,您将得到足够小的数据块来处理适合处理器高速缓存的每个单独的进程。这种缓存效应可能会对代码的性能产生巨大的影响,从而大大加速并补偿MPI通信需求的增加.在许多情况下都可以观察到这一点,但这并不能用来补偿糟糕的可伸缩性。
另一种可以观察到这种超线性可伸缩性的情况是,当您有一种算法,在大型集合中分发查找特定元素的任务时:通过分发您的工作,您可以在几乎立即找到结果的进程/线程中结束,仅仅因为它恰好被赋予范围的索引开始非常接近答案。但是这种情况比前面提到的缓存效果更不可靠。
希望这能给你一个超线性的味道。
发布于 2015-10-06 14:21:58
有人提到了缓存,但这并不是唯一可能的原因。例如,您可以想象一个并行程序,它没有足够的内存在低节点计数时存储其所有数据结构,而在高节点上存储敌人。因此,在低节点计数时,程序员可能被迫将中间值写入磁盘,然后再读取它们,或者在需要时重新计算数据。但是,在节点计数较高的情况下,不再需要这些游戏,程序可以将所有数据存储在内存中。因此,超线性加速是可能的,因为在较高的节点计数时,代码只是通过使用额外的内存来避免I/O或计算,从而减少了工作量。
实际上,这与在其他答案中注意到的缓存效果是一样的,使用额外的资源来获得它们。这就是真正的诀窍--更多的节点不仅仅意味着更多的核心,它还意味着更多的资源,所以如果你也能使用其他额外的资源,你就能达到超线性的速度。
https://stackoverflow.com/questions/32971447
复制相似问题