许多内核上令人尴尬的并行工作扩展性差

Question

我正在尝试在多核系统上并行化代码。在调查扩展瓶颈时，我最终将所有内容都删除到一个（几乎）空的 for 循环中，并发现在 28 个内核时扩展仍然只有 75%。下面的示例不会导致任何错误共享、堆争用或内存带宽问题。我在许多运行 Linux 或 Mac 的机器上看到了类似或更糟的影响，物理内核数从 8 到 56，所有处理器都处于空闲状态。

该图显示了在专用 HPC Linux 节点上进行的测试。这是一个“弱缩放”测试：工作负载与工作人员的数量成正比，垂直轴显示所有线程组合完成的工作速率，缩放到硬件的理想最大值。每个线程运行 10 亿次空的 for 循环迭代。 1 到 28 之间的每个线程计数有一个试验。每个线程的运行时间约为 2 秒，因此线程创建的开销不是一个因素。

这可能是操作系统妨碍了我们吗？或者可能是功耗？谁能提供一个在高核数机器上显示 100% 扩展的计算示例（无论多么微不足道、弱或强）？

下面是要重现的 C++ 代码：

#include <vector>
#include <thread>

int main()
{
    auto work = [] ()
    {
        auto x = 0.0;

        for (auto i = 0; i < 1000000000; ++i)
        {
            // NOTE: behavior is similar whether or not work is
            // performed here (although if no work is done, you
            // cannot use an optimized build).

            x += std::exp(std::sin(x) + std::cos(x));
        }
        std::printf("-> %lf\n", x); // make sure the result is used
    };

    for (auto num_threads = 1; num_threads < 40; ++num_threads)
    {
        auto handles = std::vector<std::thread>();

        for (auto i = 0; i < num_threads; ++i)
        {
            handles.push_back(std::thread(work));
        }
        auto t0 = std::chrono::high_resolution_clock::now();

        for (auto &handle : handles)
        {
            handle.join();
        }
        auto t1 = std::chrono::high_resolution_clock::now();
        auto delta = std::chrono::duration<double, std::milli>(t1 - t0);

        std::printf("%d %0.2lf\n", num_threads, delta.count());
    }
    return 0;
}

要运行该示例，请确保编译不带 带优化：g++ -O3 -std=c++17 weak_scaling.cpp。这是重现绘图的 Python 代码（假设您将程序输出通过管道传输到 perf.dat）。

import numpy as np
import matplotlib.pyplot as plt

threads, time = np.loadtxt("perf.dat").T
a = time[0] / 28
plt.axvline(28, c='k', lw=4, alpha=0.2, label='Physical cores (28)')
plt.plot(threads, a * threads / time, 'o', mfc='none')
plt.plot(threads, a * threads / time[0], label='Ideal scaling')

plt.legend()
plt.ylim(0.0, 1.)
plt.xlabel('Number of threads')
plt.ylabel('Rate of work (relative to ideal)')
plt.grid(alpha=0.5)
plt.title('Trivial weak scaling on Intel Xeon E5-2680v4')
plt.show()

更新 -- 这是 56 核节点上的相同扩展，以及该节点的架构：

更新 -- cmets 担心构建未优化。如果在循环中完成工作，结果非常相似，不丢弃结果，使用-O3。

Answer 1

测试没有意义，因为您没有运行优化的构建并且没有提供真正的工作。

我们怎么知道呢？因为任何最近的 gcc 版本都会删除无用的 for 循环，除非你禁用优化。因此，要么您在禁用优化的情况下进行编译，要么根本不存在 for 循环。

当我向您的 work 函数添加一些实际工作并运行优化构建时，当 work 花费超过大约 10 秒时，缩放与预期完全一样。低于大约 100 毫秒的工作时，操作系统开销会使结果变得嘈杂到毫无意义的地步（在我的特定平台上）。

也许您错过了 for 循环已被优化掉的事实，并且正在对线程创建和销毁进行基准测试，而不是完成任何工作。或者您正在对没有优化的代码进行基准测试。做一些真正的工作。计算类似于级数展开的东西，并在每个线程的末尾打印出结果。您将按预期看到缩放。并查看实际的汇编输出以确保编译器不会将循环静态转换为常量结果。现代编译器很容易识别，例如对基于常量输入的算术或几何级数求和，并用最终结果替换计算。

不要对未优化的构建进行任何基准测试。这几乎没有意义，因为您正在积极禁用编译器优化提供的所有性能优势。并且不要对实际上并没有做某事的代码进行基准测试，因为您可以确定循环在执行计算工作时实际执行的次数与您想象的一样多。