我倾向于解决这个问题的一种方法是在内存控制器级别有效地分解线程和（MPI）任务。即，通过为每个 CPU 插槽或内存控制器设置一个任务，然后在每个任务下执行线程，从代码中删除 NUMA 方面。如果您这样做，那么无论哪个线程实际执行分配或初始化工作，您都应该能够通过首次触摸或可用 API 之一安全地将所有内存绑定到该套接字/控制器。套接字之间的消息传递通常得到了很好的优化，至少在 MPI 中是这样。你总是可以有比这更多的 MPI 任务，但由于你提出的问题，我很少建议人们少做。

这个答案是对问题中两个与 C++ 相关的误解的回应。

1. “这同样适用于坚持初始化新分配（包括 POD）的 C++ new 运算符”
2. “C++ operator new 只接受一个参数”

这不是您提到的多核问题的直接答案。只是回应将 C++ 程序员归类为 C++ 狂热者的评论，以便维护声誉；）。

要点 1. C++“新”或堆栈分配不坚持初始化新对象，无论是否 POD。由用户定义的类的默认构造函数具有该责任。下面的第一个代码显示了无论该类是否为 POD 打印的垃圾。

第 2 点。C++ 允许使用多个参数重载“new”。下面的第二个代码显示了分配单个对象的这种情况。它应该提供一个想法，并且可能对您的情况有用。operator new[] 也可以适当修改。

// 第 1 点的代码。

#include <iostream>

struct A
{
    // int/double/char/etc not inited with 0
    // with or without this constructor
    // If present, the class is not POD, else it is.
    A() { }

    int i;
    double d;
    char c[20];
};

int main()
{
    A* a = new A;
    std::cout << a->i << ' ' << a->d << '\n';
    for(int i = 0; i < 20; ++i)
        std::cout << (int) a->c[i] << '\n';
}

Intel 的 11.1 编译器显示了这个输出（当然是“a”指向的未初始化内存）。

993001483 6.50751e+029
105
108
... // skipped
97
108

// 第 2 点的代码。

#include <cstddef>
#include <iostream>
#include <new>

// Just to use two different classes.
class arena { };
class policy { };

struct A
{
    void* operator new(std::size_t, arena& arena_obj, policy& policy_obj)
    {
        std::cout << "special operator new\n";
        return (void*)0x1234; //Just to test
    }
};

void* operator new(std::size_t, arena& arena_obj, policy& policy_obj)
{
    std::cout << "special operator new (global)\n";
    return (void*)0x5678; //Just to test
}

int main ()
{
    arena arena_obj;
    policy policy_obj;
    A* ptr = new(arena_obj, policy_obj) A;
    int* iptr = new(arena_obj, policy_obj) int;
    std::cout << ptr << "\n";
    std::cout << iptr << "\n";
}

在 deal.II 中，我们拥有软件基础架构，可以使用线程构建块将每个单元上的组装并行化到多个内核上（本质上，每个单元有一个任务，并且需要将这些任务安排到可用的处理器上——这不是它的方式实施，但这是一般的想法）。问题是，对于本地集成，您需要许多临时（临时）对象，并且您需要提供至少与可以并行运行的任务一样多的任务。我们看到加速很差，大概是因为当一个任务被放到处理器上时，它会抓取一个临时对象，这些对象通常会在其他内核的缓存中。我们有两个问题：

(i) 这真的是原因吗？当我们在 cachegrind 下运行程序时，我发现我使用的指令数量与在单线程上运行程序时基本相同，但所有线程累积的总运行时间远大于单线程运行时间。真的是因为我不断地故障缓存吗？

(ii) 我怎样才能知道我在哪里，每个暂存对象在哪里，以及我需要使用哪个暂存对象来访问当前核心缓存中的热对象？

最终，我们都没有找到这些解决方案的答案，并且经过几项工作后，我们决定我们缺乏调查和解决这些问题的工具。我确实知道如何至少在原则上解决问题（ii）（即，使用线程本地对象，假设线程仍然固定在处理器内核上——另一个不容易测试的猜想），但我没有工具来测试问题（一世）。

因此，从我们的角度来看，处理 NUMA 仍然是一个未解决的问题。

除了 hwloc 之外，还有一些工具可以报告 HPC 集群的内存环境，并可用于设置各种 NUMA 配置。

我会推荐 LIKWID 作为这样的工具之一，因为它避免了基于代码的方法，例如允许您将进程固定到核心。这种解决机器特定内存配置的工具方法将有助于确保您的代码跨集群的可移植性。

您可以在 ISC'13“ LIKWID - 轻量级性能工具”中找到一个简短的演示文稿，作者在 Arxiv 上发表了一篇论文“现代多核处理器上 HPM 辅助性能工程的最佳实践”。本文描述了一种解释来自硬件计数器的数据以开发特定于您的机器架构和内存拓扑的高性能代码的方法。