【发布时间】：2012-11-28 00:41:03
【问题描述】：
我们目前正在使用 TBB 流程图，其中 a) 并行过滤器处理数组（与偏移量并行）并将处理后的结果放入中间向量（在堆上分配；大多数向量将增长到 8MB） .然后将这些向量传递给节点，然后节点根据它们的特征（在 a) 中确定）对这些结果进行后处理。由于资源同步，每个特征只能有一个这样的节点。我们编写的原型在 UMA 架构上运行良好（在单 CPU Ivy Bridge 和 Sandy Bridge 架构上进行了测试）。但是，该应用程序无法在我们的 NUMA 架构（4 CPU Nehalem-EX）上扩展。我们将问题归结为内存分配，并创建了一个最小示例，其中我们有一个并行管道，它只从堆中分配内存（通过 8MB 块的 malloc，然后 memset 8MB 区域；类似于初始原型的操作）达到一定的内存量。我们的发现是：
-
在 UMA 架构上，应用程序随着管道使用的线程数线性扩展（通过 task_scheduler_init 设置）
-
在 NUMA 架构上，当我们将应用程序固定到一个套接字（使用 numactl）时，我们会看到相同的线性扩展
-
在 NUMA 架构上，当我们使用多个套接字时，我们的应用程序运行时间会随着套接字数量的增加而增加（负线性比例-“向上”）
对我们来说，这听起来像是堆争用。到目前为止，我们尝试的是用 Intel 的 TBB 可扩展分配器代替 glibc 分配器。但是，在单个套接字上的初始性能比使用 glibc 更差，在多个套接字上的性能没有变差，但也没有变得更好。我们使用 tcmalloc、hoard 分配器和 TBB 的缓存对齐分配器获得了相同的效果。
问题是是否有人遇到过类似的问题。堆栈分配对我们来说不是一个选项，因为我们希望即使在管道运行之后也保留堆分配的向量。一个堆如何在 NUMA 架构上从多个线程有效地分配 MB 大小的内存区域？我们真的很想保持动态分配方法，而不是预先分配内存并在应用程序中管理它。
我使用 numactl 附加了各种执行的性能统计信息。 Interleaving/localalloc 没有任何效果（QPI 总线不是瓶颈；我们验证了使用 PCM，QPI 链路负载为 1%）。我还添加了一个图表，描述了 glibc、tbbmalloc 和 tcmalloc 的结果。
性能统计 bin/原型 598.867
“bin/prototype”的性能计数器统计：
12965,118733 task-clock # 7,779 CPUs utilized
10.973 context-switches # 0,846 K/sec
1.045 CPU-migrations # 0,081 K/sec
284.210 page-faults # 0,022 M/sec
17.266.521.878 cycles # 1,332 GHz [82,84%]
15.286.104.871 stalled-cycles-frontend # 88,53% frontend cycles idle [82,84%]
10.719.958.132 stalled-cycles-backend # 62,09% backend cycles idle [67,65%]
3.744.397.009 instructions # 0,22 insns per cycle
# 4,08 stalled cycles per insn [84,40%]
745.386.453 branches # 57,492 M/sec [83,50%]
26.058.804 branch-misses # 3,50% of all branches [83,33%]
1,666595682 seconds time elapsed
perf stat numactl --cpunodebind=0 bin/prototype 272.614
“numactl --cpunodebind=0 bin/prototype”的性能计数器统计数据：
3887,450198 task-clock # 3,345 CPUs utilized
2.360 context-switches # 0,607 K/sec
208 CPU-migrations # 0,054 K/sec
282.794 page-faults # 0,073 M/sec
8.472.475.622 cycles # 2,179 GHz [83,66%]
7.405.805.964 stalled-cycles-frontend # 87,41% frontend cycles idle [83,80%]
6.380.684.207 stalled-cycles-backend # 75,31% backend cycles idle [66,90%]
2.170.702.546 instructions # 0,26 insns per cycle
# 3,41 stalled cycles per insn [85,07%]
430.561.957 branches # 110,757 M/sec [82,72%]
16.758.653 branch-misses # 3,89% of all branches [83,06%]
1,162185180 seconds time elapsed
perf stat numactl --cpunodebind=0-1 bin/prototype 356.726
“numactl --cpunodebind=0-1 bin/prototype”的性能计数器统计信息：
6127,077466 task-clock # 4,648 CPUs utilized
4.926 context-switches # 0,804 K/sec
469 CPU-migrations # 0,077 K/sec
283.291 page-faults # 0,046 M/sec
10.217.787.787 cycles # 1,668 GHz [82,26%]
8.944.310.671 stalled-cycles-frontend # 87,54% frontend cycles idle [82,54%]
7.077.541.651 stalled-cycles-backend # 69,27% backend cycles idle [68,59%]
2.394.846.569 instructions # 0,23 insns per cycle
# 3,73 stalled cycles per insn [84,96%]
471.191.796 branches # 76,903 M/sec [83,73%]
19.007.439 branch-misses # 4,03% of all branches [83,03%]
1,318087487 seconds time elapsed
perf stat numactl --cpunodebind=0-2 bin/protoype 472.794
“numactl --cpunodebind=0-2 bin/prototype”的性能计数器统计信息：
9671,244269 task-clock # 6,490 CPUs utilized
7.698 context-switches # 0,796 K/sec
716 CPU-migrations # 0,074 K/sec
283.933 page-faults # 0,029 M/sec
14.050.655.421 cycles # 1,453 GHz [83,16%]
12.498.787.039 stalled-cycles-frontend # 88,96% frontend cycles idle [83,08%]
9.386.588.858 stalled-cycles-backend # 66,81% backend cycles idle [66,25%]
2.834.408.038 instructions # 0,20 insns per cycle
# 4,41 stalled cycles per insn [83,44%]
570.440.458 branches # 58,983 M/sec [83,72%]
22.158.938 branch-misses # 3,88% of all branches [83,92%]
1,490160954 seconds time elapsed
最小示例：使用 g++-4.7 std=c++11 -O3 -march=native 编译；使用 numactl --cpunodebind=0 ... numactl --cpunodebind=0-3 执行 - 使用 CPU 绑定我们有以下发现：1 个 CPU（速度 x）、2 个 CPU（速度 ~ x/2）、3 个 CPU（速度~ x/3) [速度=越高越好]。所以我们看到的是性能随着 CPU 数量的增加而恶化。内存绑定、交错 (--interleave=all) 和 --localalloc 在这里不起作用（我们监控了所有 QPI 链接，并且每个链接的链接负载低于 1%）。
#include <tbb/pipeline.h>
#include <tbb/task_scheduler_init.h>
#include <chrono>
#include <stdint.h>
#include <iostream>
#include <fcntl.h>
#include <sstream>
#include <sys/mman.h>
#include <tbb/scalable_allocator.h>
#include <tuple>
namespace {
// 8 MB
size_t chunkSize = 8 * 1024 * 1024;
// Number of threads (0 = automatic)
uint64_t threads=0;
}
using namespace std;
typedef chrono::duration<double, milli> milliseconds;
int main(int /* argc */, char** /* argv */)
{
chrono::time_point<chrono::high_resolution_clock> startLoadTime = chrono::high_resolution_clock::now();
tbb::task_scheduler_init init(threads==0?tbb::task_scheduler_init::automatic:threads);
const uint64_t chunks=128;
uint64_t nextChunk=0;
tbb::parallel_pipeline(128,tbb::make_filter<void,uint64_t>(
tbb::filter::serial,[&](tbb::flow_control& fc)->uint64_t
{
uint64_t chunk=nextChunk++;
if(chunk==chunks)
fc.stop();
return chunk;
}) & tbb::make_filter<uint64_t,void>(
tbb::filter::parallel,[&](uint64_t /* item */)->void
{
void* buffer=scalable_malloc(chunkSize);
memset(buffer,0,chunkSize);
}));
chrono::time_point<chrono::high_resolution_clock> endLoadTime = chrono::high_resolution_clock::now();
milliseconds loadTime = endLoadTime - startLoadTime;
cout << loadTime.count()<<endl;
}
英特尔 TBB 论坛讨论：http://software.intel.com/en-us/forums/topic/346334
【问题讨论】：
-
后处理的标准是什么？是否所有线程都在原地修改，或者是否可以为它们提供源数据和向量的副本。在多套接字机器上，如果存在争用，采用共享内存/多处理方法而不是线程通常更快/更容易。对于多个进程，您可以设置 CPU 亲和性以将争用降至最低。
-
这里的问题与源数组无关（甚至是后处理；它只是为了给出我们需要堆分配的上下文）。我创建了一个最小的示例，其中 8MB 块在堆上分配到一定大小（并行）。我们看到的是，使用一个 CPU 需要 x ms，使用 2 个 CPU 大约需要 2*x ms，....所以它不会随着 NUMA 架构上的套接字数量而扩展。但是，它确实可以根据线程数在一个套接字上进行扩展。
-
您能否提供一个最小的伪代码示例，说明如何分配此内存、用数据填充它，然后进行处理和后处理？您一直在监控哪些 QPI 链接？一个 4 插槽系统将通过 6 个双向链路完全连接。此外，您还有许多 CPU 迁移 - 将每个线程绑定到不同的 CPU 内核，并观察远程（在 NUMA 意义上）内存访问的数量。
-
我添加了重现问题的代码。我们监控了所有 QPI 链接，所有链接负载均低于 1%。我还没有完全验证，但认为线程绑定在这里没有效果。这更多是堆争用的问题，或者更好地说是在堆上分配大（此处为 8MiB）内存区域所需的同步问题。
-
两个系统都有 256 GiB RAM 均匀分布在所有 NUMA 节点之间。我可以在具有高达 2 TiB RAM 的系统上进行测试，但它们的时间紧迫，需要时间。
标签： c++ memory-management parallel-processing tbb numa