计算化学公社

标题: Windows下或WSL2中Gaussian对9950x的调度问题及解决方法 [打印本页]

作者
Author: Voidmio 时间: 2025-11-7 22:14
标题: Windows下或WSL2中Gaussian对9950x的调度问题及解决方法
本帖最后由 Voidmio 于 2025-11-8 20:25 编辑

题主在昨日求助帖购置了 9950x 计算机，成功PBO3，但计算竟远慢于 7950x ...中，提及了在 9950x 核心计算机上，使用 WSL2-RockyLinux9 进行 Gaussian 计算时，核心两个 CCD 温度和频率严重不同的问题：

观察到 9950x 两个 CCD 温度严重不同（计算任务以及 R23 下 CCD1 温度比 CCD2 稳定高出 10-20 度，但烤鸡时无此差别），进而观察到 CCD2 频率严重低于 CCD1（在 HWiNFO 中查看得）（计算过程中 CCD1 平均频率在 5.5 GHz，峰值 5.7 GHz，但 CCD2 平均频率却只有 3-4 GHz，峰值为 5.6 GHz）。我猜测过是因为我在 CCD2 核心上负压太多，但恢复默认后仍然没有区别，常常是 CCD1 撞上温度墙而 CCD2 还在 80 度左右徘徊。此事也在其他道友的机子上出现过，见 window下双CCD CPU的高斯输入设置，并非%nproc=n！，当时也没有定论。

(文中涉及所有未特别说明的计算文件都是 test0397，计算级别改为 b3lyp/def2svp force scf=novaracc g09default 的版本)
这时候进行声明 16 核心的 Gaussian 计算时（无论是%nproc=16、%cpu=0-15、%cpu=16-31 甚至 %cpu=0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30），均耗时 6m26s - 6m45s，取决于我是否有在同时运行其他程序。在任务管理器和 HWiNFO 中可见明显物理和逻辑核心各算各的，不仅占用都没有跑满，超线程分配还在被反着调用，简直是集百家之短，并且处于两个 CCD 的核心频率和温度也大相径庭：
(, 下载次数 Times of downloads: 0)
（可见 CCD1 高温都烧到 98 度，CCD2 竟然只有 85 度，真是在度假）

这是由于有些 Ryzen 9000 系 CPU 是多个 CCD 拼好核，其中如 9950x 的两个 CCD 体质并不相同，不开启 PBO 的情况下 CCD1 金银核睿频可以到 5.7 GHz，而 CCD2 在相同甚至更高的电压只能到 5.5 GHz。
虽然题主使用 Curve Optimizer 逐个调整每个核心的负压，将其拉到了同样的体质（相同的电压曲线，将在相同的电压下达到同样的频率），可是实际在 WSL2 中计算时仍然出现了前述的情况：调用全核心=更倾向于使用体质排名靠前的核心进行运算。这很不好。

有没有解决方法呢，有的有的。在 [Linux] 求助：感觉7950X计算效率较低该如何解决？一帖中，评论区的老师们提出可以使用在任务管理器中设置 WSL2 相关任务 vmmemWSL 的处理器相关性来判断逻辑核心和物理核心的对应关系，进而通过绑定相关性来强制 WSL2 仅调用物理核心上的一个逻辑核心，避免任务挤向同一个体质好的核心，反而拖慢速度。

基于这个观点，首先确定逻辑核心和物理核心的关系。参考 ahxb 老师在帖中的方法，对苯分子在 b3lyp/def2tzvp force scf=novaracc 关键词下运行计算，规定%nproc=2，同时在任务管理器中设置任务 vmmemWSL 的相关性依次为 CPU0+CPU1、CPU0+CPU16、CPU0+CPU31，以此判断是CPU0和1对应同一个物理核，还是0和n、1和n+1对应同一个物理核，还是0和31，1和30这样子对应。结果如下：
(, 下载次数 Times of downloads: 0)
可见 9950x 是 CPU0 和 CPU1 处于同一个物理核心， CPU2 和 CPU3 对应同一个物理核，依次类推。不同的处理器可能有不同的对应方式，大家有需要可自行测试，非常便捷。

接下来在任务管理器中对 vmmemWSL 进行手动奇数线程绑定后，再进入 WSL2 进行 16 核心的 Gaussian 计算，完美解决：
(, 下载次数 Times of downloads: 1)
可见程序选择性负载了一半逻辑核心，同时是所有的物理核心，此时双 ccd 运行在几乎同一个更低的温度上，频率也拉满了，整核心功耗峰值也只有220 W，最后仅耗时 6m1s 即完成运算。就算我在计算的同时在丝之歌中攻击苍白之母，也只耗时 6m10s。

此时事情似乎完美结束。但很快就发现，每次启动 WSL2 都需要手动修改核心相关性设置，使人烦不胜烦；同时我使用 WSL2 进行运算多是直接使用 Windows 中的脚本调用 WSL2，手动修改根本不现实。在一众解决方案中，我选择使用 Process Lasso 进行 CPU 亲和性调整。这是一个用于进程级别优化的老牌Windows系统工具，对于这样的调度不均问题很有帮助。

直接在Process Lasso 中搜索 vmmemWSL 进程，在 CPU 亲和性选项中选择奇数或偶数核心即可。接下来启动 WSL2 时，vmmemWSL 进程将默认绑定这些核心。
(, 下载次数 Times of downloads: 0)

到此为止，问题完美解决。这样的设置可以使计算速度达到关闭超线程的顶级速度，同时保留所有开启超线程的优势，不影响计算机的其他正常使用。同理，这种思路完全适用于window下双CCD CPU的高斯输入设置，并非%nproc=n！中描述的 G16W 调度问题以及全平台 Intel 核心的大小核调度问题，欢迎各位进行尝试。

作者
Author: lmch 时间: 2025-11-7 23:49
关了超线程解千愁（雾）

作者
Author: Voidmio 时间: 2025-11-8 19:20

lmch 发表于 2025-11-7 23:49
关了超线程解千愁（雾）

关了就不能愉快打游戏乐

作者
Author: Stardust0831 时间: 2025-12-2 12:24
apt装最新版slurm（有特殊高版本deb），配置cgroup来自动绑核，实现cpu亲和性，是否可行？

作者
Author: Voidmio 时间: 2025-12-2 13:31

Stardust0831 发表于 2025-12-2 12:24
apt装最新版slurm（有特殊高版本deb），配置cgroup来自动绑核，实现cpu亲和性，是否可行？

妹有试过，懒蛋感觉一台电脑装slurm太麻烦了

倒是可以试试

欢迎光临计算化学公社 (http://bbs.keinsci.com/)