【问题标题】:Which are the common causes for non scalability of shared memory programs?共享内存程序不可扩展的常见原因有哪些?
【发布时间】:2015-07-23 13:37:35
【问题描述】:

每当有人并行化应用程序时,预期的结果是一个不错的加速,但并非总是如此。

通常情况下,在x 秒内运行的程序并行使用 8 个内核将无法达到x/8 秒(最佳加速)。在某些极端情况下,它甚至比原来的顺序程序需要更多的时间。

为什么?最重要的是,我如何提高可扩展性?

【问题讨论】:

    标签: parallel-processing scalability shared-memory


    【解决方案1】:

    不可扩展性有几个常见的原因:

    1. 同步过多:一些问题(有时是过于保守的程序员)需要在并行任务之间进行大量同步,这会消除算法中的大部分并行性,使其变慢。

    1.1。确保为您的算法使用尽可能少的同步。以openmp 为例,从synchronizedatomic 的简单更改可能会导致相关差异。

    1.2 有时,更差的顺序算法可能会提供更好的并行机会,如果您有机会尝试其他方法,可能值得一试。

    1. 内存带宽限制:最“琐碎”的算法实现没有针对局部性进行优化是很常见的,这意味着处理器和主内存之间的通信成本很高。

    2.1 优化局部性:这意味着了解您的应用程序将在哪里运行、可用的缓存内存有哪些以及如何更改数据结构以最大限度地利用缓存。

    1. 并行化开销过多:有时并行任务太“小”,以至于线程/进程创建的开销与并行区域总时间相比太大,导致加速不佳甚至减速.

    【讨论】:

      【解决方案2】:

      RSFalcon7 的所有建议都可以组合成一条“超级规则”:尽可能多地使用非共享资源(L1 和 L2 缓存)——这意味着节省代码和数据需求——如果您需要使用共享资源,请执行在进入磁盘之前,在进入 RAM 之前尽可能在 L3 中进行(同步所需的 CPU 周期是可变的,但比访问 RAM 慢 - 或慢得多)。

      如果您打算使用超线程,我发现使用 gcc 编译的代码在优化级别为 O1 时会比使用 O2 或 O3 时更好地使用超线程。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-08-09
        • 2013-12-18
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多