不同多线程方案下oneAPI/MKL/BLAS嵌套调用的线程控制问题

线程控制方法 #

MKL_THREAD_MODEL=OMP场景下TBB嵌套BLAS的线程控制 #

mkl_set_num_threads_local是线程私有接口，仅对调用该接口的线程后续发起的MKL调用生效，配置不会自动传播到TBB、std::thread创建的工作线程。在并行区域外调用该接口时，仅主线程拿到配置，工作线程仍使用全局默认线程数，自然出现控制失效的问题。
正确用法是将mkl_set_num_threads_local(1)放到TBB parallel_for的lambda内部、工作线程进入循环的首行调用，每个工作线程自行设置局部线程数即可生效。

MKL_THREAD_MODEL=TBB场景下的BLAS线程控制 #

该模型下MKL内部与外层并行逻辑共享同一个TBB线程池，默认开启嵌套并行，domain、local类接口的跨线程传播逻辑与OMP模型不兼容，因此控制失效。

• 若要强制BLAS单线程执行：在所有并行区域启动前，全局调用mkl_set_num_threads(1)，同时设置环境变量MKL_DYNAMIC=false关闭MKL动态线程调整即可，不要使用local或domain接口。
• 若要控制BLAS调用的线程数：不要开启嵌套并行，按配额分配线程即可：外层单元计算用N个线程时，BLAS线程数设为1；若BLAS需要M个线程，就将外层并行线程数设为总核心数/M，避免线程池超额订阅。

mkl_set_num_threads_local优先级未达预期的原因 #

该接口“优先级高于domain/全局设置”的规则仅在同一线程上下文内生效，不会跨线程传递配置。主线程设置的local参数不会被TBB、std::thread创建的工作线程继承，工作线程默认读取全局MKL配置，自然体现不出文档描述的优先级。只有在每个工作线程内部、调用BLAS前主动执行mkl_set_num_threads_local，优先级规则才会生效。

运行时超线程启用状态检测方法 #

不要通过top的总CPU占用判断，用以下两种方式直接检测：

• 用perf stat -e cpu_clk_unhalted.thread,cpu_clk_unhalted.ref_tsc 可执行程序路径采集运行数据，跑完后如果cpu_clk_unhalted.thread与cpu_clk_unhalted.ref_tsc的比值接近2，说明同物理核心的两个超线程都处于运行状态；比值接近1则说明仅用到物理核心，未启用超线程。
• 绑核对比测试：第一次将程序绑定到16个跨物理核的逻辑核（如编号0,2,4...30，每个物理核仅绑1个逻辑核），第二次绑定到16个连续逻辑核（如0-15，覆盖8个物理核的超线程对），如果两次性能差超过15%，说明无绑核时程序实际用到了超线程。

更精准的CPU运行状态检测工具 #

比top适配性更好的工具如下：

• htop：开启自定义线程名显示、按核高亮占用功能后，可直接看到每个逻辑核的实时占用，同一个物理核心对应的两个逻辑核同时跑满即为用到超线程。
• likwid-topology搭配likwid-perfctr：可直接识别物理核心、超线程的拓扑关系，运行时统计每个物理核、逻辑核的利用率，还能拆分MKL函数的调用耗时占比，直接区分时间消耗在外层计算还是BLAS调用上。
• Intel VTune Profiler：线程分析功能可直接抓取每个线程的调用栈，明确区分外层并行线程和MKL内部拉起的工作线程，直接定位是否存在超额订阅、线程运行在物理核还是超线程上的问题。

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