跨NUMA节点OpenMP高斯消元程序加速比异常问题咨询

1. 对NUMA性能规律的认知前提错误 #

所有资料提到「跨NUMA节点运行性能更低」，都有一个默认前置条件：线程间存在共享数据访问，或线程需要读取其他NUMA节点的远程内存。
你的测试程序属于典型的易并行（pleasingly parallel）负载，完全不满足跨NUMA变慢的前提：

• 并行粒度是循环级的独立高斯消元任务，每个线程全程处理自己的任务，没有任何跨线程共享数据
• 每个任务的矩阵内存由执行线程自行申请、初始化写入、计算、释放，配合Linux默认的first-touch内存分配规则，内存页会自动分配在当前线程所在的NUMA节点，全程是本地内存访问
  这种场景下把线程分散到两个socket上，UPI跨互连链路没有任何业务流量，根本不会产生跨NUMA通信开销。

2. 单socket绑定20个物理核性能最差的原因 #

你使用的Intel Xeon Gold 6148单socket正好是20个物理核，把20个核全部占满时会触发两个非常明显的性能瓶颈：

• 睿频频率上不去：这颗处理器的睿频策略和核心负载强相关：单核心负载最高睿频3.7GHz，单socket跑10个核时全核睿频约3.1_{3.2GHz，单socket20个核拉满时，全核频率只有2.5}2.6GHz，单核性能差了近20%，总理论算力差距明显。
• 共享资源争抢严重：单socket的内存控制器、L3缓存带宽、片上环形总线带宽是固定配额，20个核同时争抢这一份资源，就算每个线程的工作集能放进私有L2缓存，malloc/free的ptmalloc锁竞争、缓存一致性流量、内核调度元数据访问的开销都会被放大。
  而跨socket各绑定10个物理核的场景下，20个线程的资源开销被平摊到两个socket上：每个socket只跑10个核能跑到更高睿频，共享资源的争抢压力直接减半，又没有任何跨NUMA通信成本，性能自然远高于单socket拉满20核的场景。你测到的18.3~18.6的加速比属于非常优秀的线性加速结果，剩余损耗是OpenMP并行的固有开销，完全正常。

3. 跨socket超线程组加速比15.9的原因 #

这组测试绑定的40_{49是node0上物理核0}9的第二个超线程逻辑核，60_{69是node1上物理核20}29的第二个超线程逻辑核，看起来占了20个计算单元，实际性能受超线程硬件特性限制：

• 同一物理核的两个逻辑核共享执行单元、L1/L2缓存、TLB资源，就算只给其中一个逻辑核绑定线程，CPU的电源管理、资源调度策略也不会给第二个逻辑核分配和独立物理核同等的资源配额，实际性能约为物理核的70%~80%
• 系统的外设中断默认亲和性优先绑定到物理核的第一个逻辑核，会产生少量中断抢占开销
  折算下来20个超线程逻辑核的实际算力约等于14~16个物理核，跑出15.9的加速比完全符合预期，甚至比单socket拉满20个物理核的性能更高，刚好反过来印证了单socket全核负载时睿频下降、资源争抢的损耗，已经超过了超线程本身的性能损耗。

可选验证方案 #

可以补充三组测试坐实上述结论：

• 测试单socket只绑定10个物理核的加速比，结果应该在9左右，和跨socket20核的18呈线性关系
• 在BIOS中锁死全核最高频率、关闭动态睿频，单socket20核的性能会有明显提升
• 把代码中循环内反复malloc/free的逻辑改成启动时预分配内存，单socket场景下的锁竞争开销会显著下降

内容的提问来源于stack exchange，提问作者Sriram G