高性能计算的艺术
高性能计算在这里既是成熟的技艺，也是混乱的生态系统：MPI、OpenMP 和 BLAS 等强大抽象，与原始的调度器、脆弱的批处理工具以及常常监控不足或被误用的集群并存。评论者称赞 Victor Eijkhout 的免费《Art of HPC》书系以及 UT Austin 在数值软件方面的贡献，同时强调真正的性能仍然需要对硬件、热力学和可扩展性有深刻理解，而不仅仅是编程模型。除了关于 GPU、互连和液冷的技术细节外，许多人还指出教育上的缺口、研究软件工程这一岗位的兴起，以及 HPC 职位中存在的文化门槛。
书籍与教育价值
- 许多读者称赞这套 HPC 书籍系列异常全面且可免费获取，即使超出 HPC 范畴也很有用（例如 C++ 和 Unix 工具）。
- 几位评论者表示，这样的资源本可以显著改善或重塑他们过去在教学/学习上的决策。
- 一些人将其与泛泛的“科学计算”课程作对比，认为后者只是浅尝辄止地讲了些 HPC 主题；他们认为这套内容适合作为一门专门的、为期一学期的并行计算课程。
HPC 编程抽象与对硬件的认知
- MPI 和 OpenMP 被描述为主要抽象；对于许多工作负载，人们可以在这个层面编程，而无需深入了解硬件细节。
- 也有人认为，仅靠抽象不足以获得峰值性能或良好扩展：理解内存层次结构、NUMA、互连、GPU 和拓扑被视为必不可少。
- 对于线性代数，库（BLAS、LAPACK、Eigen、厂商调优的内核）掩盖了大部分底层优化，但并非所有问题都能归结为这些库。
工具、调度器与用户体验
- 工作负载管理器（Slurm、PBS、UGE、LSF）受到批评，被认为陈旧、脆弱、文档不足，尤其是通过 shell 脚本注释进行配置这一点。
- 反方观点：shell 是常见的跨学科通用语言；一些人认为 Slurm 直观、文档完善，并且通过 REST API 正在改进。
- 人们对几十年过去后作业管理 API/协议仍然碎片化感到失望；此前的标准化尝试（例如 DRMAA）采纳范围有限。
真实世界中的 HPC 实践与职业
- 许多学术岗位其实是“尴尬并行”的脚本农场：通过 Slurm 运行成百上千个彼此独立的作业，不用 MPI，也几乎不做调优。
- HPC 管理员报告说，他们的大量时间都花在用户支持、修正超额申请资源以及基础监控上，而不是深入剖析性能。
- 一些人对管理员岗位要求硕士学位的门槛以及研究组产出的代码质量感到遗憾，并主张设立专门的研究软件工程师角色。
硬件、散热与数据中心约束
- 热力学和功率密度主导了现代 HPC 设计；超级计算机和重 GPU 节点通常需要液冷或浸没式冷却。
- 商用数据中心通常无法承受 HPC 级别的功率密度；尝试将 GPU 集群同址部署可能会让机架功率预算超出一个数量级。
- 讨论强调了液冷的复杂性和风险（CDU、泄漏、冷却液管理）与简单粗暴的风冷之间的对比，但共识是：到了一定规模，液冷会变成必需。
HPC 的 C++ 与 Python
- C++ 卷被认为是扎实的现代入门；有人建议增加关于移动语义、RVO 和尾调用优化的内容。
- 推荐的下一步包括：面向科学家的现代 C++、侧重架构/CI 的 C++ 书籍，以及智能指针、ranges、并发等关键主题。
- 一些人指出，Python 的 HPC 越来越多地通过 Dask 和 GPU 支持的库来做，而不只是 MPI 绑定。
集群管理与排队论
- 其中一条讨论将硬件管理视为一个复杂系统：层级马尔可夫链、维修流程、物流以及工作负载之间的相互作用。
- 排队论被引用为基础但仍不完整的框架；现实系统远比标准的 M/G/k 模型复杂。