加载含__thread TLS的共享库致OpenMP程序性能下降的原因及解决问询

我用pybind11为一款基于OpenMP实现多线程的大型Fortran仿真程序开发Python封装模块。初始阶段，Python调用Fortran程序的性能与原生执行完全一致，但新增功能后，程序运行时间延长了50%至100%。

经排查，性能下降的根源在于pybind11的PYBIND11_NUMPY_DTYPE宏会加载numpy.core._multiarray_umath库，该库中定义了两个以__thread修饰的线程本地存储（TLS）变量。

我制作了最小复现示例：

• 含OpenMP threadprivate变量的Fortran程序（work.f90）编译为共享库后，首次调用性能正常；
• 加载仅定义__thread变量的共享库（tl.c编译生成）后，再次调用该Fortran程序性能显著下降。

现提出两个问题：

1. 为何加载含__thread TLS的共享库会导致OpenMP程序性能下降？
2. 如何避免该问题？（无法规避numpy库的加载）

1. 性能下降的原因 #

这是因为动态加载含__thread TLS的共享库会破坏OpenMP运行时的线程本地存储布局。

OpenMP的threadprivate变量依赖编译器和运行时实现的高效TLS机制，通常在程序启动时就为所有线程预分配固定的TLS内存区域，访问时直接通过偏移量快速寻址。而__thread类型的TLS变量属于POSIX TLS范畴，当动态加载这类共享库时，系统需要为每个现有线程重新调整TLS段的布局，新增的TLS变量会导致OpenMP原有的TLS访问路径失效，迫使运行时改用更慢的TLS访问方式（比如通过线程控制块TCB间接查找）。

这种切换会让原本高效的threadprivate变量访问变成高开销操作，在多线程频繁访问这类变量的仿真程序中，性能下滑会被显著放大。

2. 解决方案（不规避numpy加载） #

有几种可行的方案：

• 提前加载numpy库：在启动Python进程后、第一次调用Fortran程序之前，主动导入numpy或numpy.core._multiarray_umath。让numpy的TLS变量在OpenMP运行时初始化前完成加载，OpenMP的TLS布局不会被后续动态加载操作破坏，两者的TLS区域可和谐共存，避免访问路径切换。
• 替换PYBIND11_NUMPY_DTYPE的使用方式：如果不需要在bind代码中直接定义numpy dtype，可改用pybind11的array_t结合显式类型声明处理数组，避免触发PYBIND11_NUMPY_DTYPE宏加载numpy的TLS依赖。
• 调整编译器链接选项：针对Fortran程序，尝试编译时指定-ftls-model=initial-exec（GCC）或类似选项，强制OpenMP的threadprivate变量使用静态TLS模型，确保后续加载新TLS变量时，原有访问路径依然有效。需注意验证该选项在目标环境的兼容性。
• 使用OpenMP显式TLS替代threadprivate：若代码修改成本可控，将threadprivate变量替换为OpenMP 4.5+支持的!$omp allocate(threadprivate)动态TLS，这种实现对后续加载的TLS变量兼容性更好，不会因布局变化导致性能下降。

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