对论坛上一篇文章的Comments

Entropy.S.I

对论坛上一篇文章的Comments——

《GROMACS2023 Windows原生系统下编译超详细解析》（原文作者：@Huschein）

[本文首发于计算化学公社 | 文 熵增焓减 | yult-entropy@qq.com | 2023-05]

许多讨论明显不准确，故特意花2小时为此文撰写Comments。具体地说：

1  关于第2节“具体分析”的第一小节

“这个主要就是因为GPU算力的问题，我具体没有详细的去了解，但是nVidia是有一套标准的，对于我的1050来说，算力就是86，而对于现在性能优异的4090可能就是90的架构，所以关于这个的帖子说多不多，说少不少，也算是比较好解决的，但是一定要注意，必须得要改gmxManageNvccConfig.cmake，因为这是控制文件，他控制了一系列build文件的生成，曾经我很长一段时间去改build文件的compute架构参数，总是反复报错，每次报错后查看build文件内容，发现86又被自动改回了90，当时真的见了鬼了，所以说，了解Cmake的工作机制是多么的重要。”

"compute_xx"和"sm_xx"中的"xx"后缀是Compute Capability，其可以理解为和GPU架构的版本号。"Compute Capability"应当译为“计算能力”而非易令人误解的“算力”，相同架构的不同GPU核心具有相同的“计算能力”和不同的“算力”。GPU与计算能力/架构版本号的对应关系可在https://developer.nvidia.com/cuda-gpus查询。例如：

• 作者的GeForce GTX 1050为Pascal GP10x架构，计算能力/架构版本号为6.1；
• GeForce RTX 2080Ti为Turing架构，计算能力/架构版本号为7.5；
• GeForce RTX 3090为Ampere GA10x架构，计算能力/架构版本号为8.6；
• GeForce RTX 4090为Ada Lovelace架构，计算能力/架构版本号为8.9（Ada架构相对于Ampere GA10x架构改进很小，性能提升主要依靠增大GPU核心规模和升级制造工艺，所以NVIDIA没有增加第一位数字）；
• Tesla P100为Pascal GP100架构，计算能力/架构版本号为6.0；
• Tesla V100为Volta架构，计算能力/架构版本号为7.0；
• A100为Ampere GA100架构，计算能力/架构版本号为8.0；
• H100为Hopper架构，计算能力/架构版本号为9.0。
  

编译时指定NVCC编译器flags的目的是让编译器启用针对相应GPU架构的优化，这在我3月份的文章中有所提及：http://bbs.keinsci.com/thread-35960-1-1.html。在GMX的编译中，NVCC编译器flags通过CMake脚本来指定，而作者最初修改的是CMake执行完毕后生成的Makefile，当然不起作用。

2  关于第3节“性能测试”部分

1)    “体系是3.3w原子的常规体系，跑常规MD任务”。作为一篇正经文章中的测试，应写明所用体系中与性能密切相关的模拟参数以及运行测试所用的命令或脚本，最好再给出运行测试所用的[.tpr]文件，参照我去年10月的文章（http://bbs.keinsci.com/thread-33296-1-1.html）。

2)    “根据官方的说法，2023在大体系上表现性能会更好，而且体系越大效率比以前越高”。我不知道作者从哪里获得了此消息。GMX2023 Release notes中介绍了性能方面的改进，没有提到“体系越大效率比以前越高”，反而提到了在启用最新引入的CUDA Graph功能后，GMX 2023模拟小体系的并行效率有所提升。GPU update从2020版开始就已支持，且在2021.6及以后的版本中修复了计算可靠性方面的Bug。至于CUDA PME decomposition，这只对使用多GPU运行模拟有用，这种情况下或许“体系越大效率比以前越高”，但目前还没有系统性测试。我在GMX 2023发布后第一时间编译了基于heFFTe + CUDA-aware MPI的支持CUDA PME decomposition的GMX，对双GeForce GPU的工作站做了测试，结果是性能稍差于传统thread-MPI版GMX的单PME Rank方案。虽然还有NVIDIA官方的cuFFTMp可用，且根据NVIDIA博客，cuFFTMp比heFFTe快，但cuFFTMp对GeForce GPU的支持还不清楚（cuFFTMp文档中说其仅支持Volta、Ampere和Hopper架构的数据中心GPU）。关于Release notes中所说的“Increased default T- and P-coupling intervals”和“The global communication frequency is independent of nstlist”，可以看我3月文章的图2，具体关注相同软硬件环境、不同体系下GMX 2023相较于GMX 2022.5的性能提升，可以推断出这2项改进并不会导致“体系越大效率比以前越高”。

3)    “我们也可以看出来，2023版本的GPU使用效率是更高的”。“GMX2023_CLANG_86_Win”与“GMX2020_CLANG_80_Win”的性能差异主要来自于update的区别，从GMX2023开始，update默认即在GPU上计算，而GMX2020~2022需手动启用此功能，这在GMX 2023 Release notes中有明确说明，且我在3月份的文章中也有提及。此外，如Comments的第一节和我3月份的文章中所说，作者的GeForce GTX 1050为Pascal架构，只要确认gmx -version命令输出内容的“CUDA compiler flags”条目中存在“arch=compute_61,code=sm_61”，则针对作者所用GPU的优化已启用。

4)    “在2023四月份，gmx官方和nVidia达成了合作”。我不知道作者从哪里获得了此消息，但GMX开发团队在许多年前就与NVIDIA建立了深度合作，至少在NVIDIA开发者社区2020年初的博客中就提到了：“The new version includes exciting new performance improvements resulting from a long-term collaboration between NVIDIA and the core GROMACS developers.”

5)    “之所以Linux一直到57600步才停，完全是因为它完成时间降得太快了，而win降的比较慢”。Mdrun刚开始运行时性能具有不稳定性，且默认会执行PME tuning，所以做性能测试时应当在mdrun运行一段时间后重置性能计时器，具体操作是在mdrun命令中添加-resetstep [步数]。

6)    “在纯GPU运行的情况下，虽然未做测试，但我仍旧看好Linux”。GMX当前并不支持“纯GPU模式”，GMX手册中所谓的GPU-resident模式不是“纯GPU模式”，这在我去年10月的文章中有提及。作为补充，下图的E即为GPU-resident模式（图源https://www.gromacs.org/topic/heterogeneous_parallelization.html）：

7)    只使用“nvidia-smi”命令并不能完整反映出NVIDIA GPU的性能状态，甚至使用最近流行的nvitop工具也不够，应当使用“nvidia-smi dmon”工具以查看功率、温度、占用率、频率、VRAM带宽占用率、VRAM使用量、PCIe数据传输速率等信息，一般使用”nvidia-smi dmon -s pucvmt -o T -f nvidia-smi.log &”命令，这在我去年10月的文章中就有提及。顺带一提，在GPU负载较低时也可能看到较高的GPU占用率，这是因为此时GPU处于低频、低功耗状态（因为整体负载未能满足切换到高频状态的条件），这也是查看完整的GPU性能信息的一个理由。

---

补充：撰写此篇Comments并无针对原文作者的意图，仅仅是因为本人上网冲浪时强迫症发作，一时激动……希望不会给原文作者造成困扰

Entropy.S.I

wypkdhd 发表于 2023-5-15 08:56
技术层面不评价。别的不说，这个帖子的排版我觉得无可挑剔。

从小就是强迫症……

wypkdhd

技术层面不评价。别的不说，这个帖子的排版我觉得无可挑剔。

Entropy.S.I

Daniel_Arndt 发表于 2023-5-13 12:56
“NVIDIA博客”对应的网址中多了一个“zh-cn/blog/”。

没有多“zh-cn/blog/”，网页自己重定向到了多一个“zh-cn/blog/”的URL，刚刚研究了一下发现在URL末尾加上“/”就不会错误重定向了，奇怪的是上午都还没有这个问题……

Daniel_Arndt

“NVIDIA博客”对应的网址中多了一个“zh-cn/blog/”。