编程语言与软件工程2025arxiv.org

将大型 C++ 数学软件包迁移到 C++20 模块

Converting a large mathematical software package written in C++ to C++20 modules

进阶 · 约 35 分钟读完前置知识：C++ 基础、编译与链接、C++20 模块

141HN 得分

42条评论

导读

这篇论文报告了将大型数学软件包 deal.II（始于上世纪 90 年代的 C++ 有限元库）从传统头文件迁移到 C++20 模块的经验。结果显示模块化使编译时间降低约 10%，代码结构可能有所改善，但对下游项目编译时间的影响尚不明确，整体收益低于预期。

HN 关注点：C++20 模块是备受期待却落地缓慢的特性，HN 读者关注真实大型项目迁移的实测数据，以及模块相比预编译头文件等传统手段是否真的值得。

关键词　C++20Modules编译时间deal.II

HN 评论精选

这几条评论里：质疑 2　补充 2

质疑质疑模块的收益可能不如更省事的预编译头文件

我想看到模块与预编译头文件的对比。我怀疑用预编译头文件可以用少得多的工作量获得同样的编译提速。

Asooka查看英文原文

I would like to see a comparison between modules and precompiled headers. I have a suspicion that using precompiled headers could provide the same build time gains with much less work.

质疑批评 C++ 模块的设计本身不合理

平心而论，C++ 的模块设计毫无道理，就像跨多个翻译单元的命名空间一样。这只是为抽象而抽象的又一套笨重抽象。

KingLancelot查看英文原文

To be fair, C++’s modules make no sense, just like their namespaces that span multiple translation units. It’s just more heavy clunky abstractions for the sake of abstractions.

补充总结论文核心数据：约 10% 提速但对下游影响不明，收益不及预期

感谢作者为模块提供了扎实的数据。结论中的关键指标是：以模块方式构建确实带来了宣称的编译时间收益（约降低 10%）和可能更好的代码结构，但 5.1.2 节的数据也表明对下游项目编译时间的影响充其量不明确。所以这一轮结果令人失望，可能说明对既有代码（deal.II 源自 90 年代）做模块化改造，不如从头设计。把源码组织成模块可能还需要更多工作——我仅用预编译头、前置声明等就获得过超过 10% 的提速。不过这仍是很好的数据点和丰富分析。

npalli查看英文原文

Thanks to author for doing some solid work in providing data points for modules. For those like me looking for the headline metric, here it is in the conclusion While the evidence shown above is pretty clear that building a software package as a module provides the claimed benefits in terms of compile time (a reduction by around 10%, see Section 5.1.1) and perhaps better code structure (Section 5.1.4), the data shown in Section 5.1.2 also make clear that the effect on compile time of downstream projects is at best unclear. So, alas, underwhelming in this iteration and perhaps speaks to 'module-fication' of existing source code (deal.II, dates from the '90s I believe), rather than doing it from scratch. More work might be needed in structuring the source code into modules as I have known good speedup with just pch, forward decls etc. (more than 10%). Good data point and rich analysis, nevertheless.

补充专业解读：模块只优化解析阶段，且当前工具链支持不完善

几点：1) 模块主要只减少解析时间，而非代码生成时间；实际上它可能拖慢代码生成，因为让更多定义可用于内联/全局优化，即使在非 LTO 构建中。因此最好在两边都用 thin-LTO 来对比。2) 当依赖尚未模块化时，全局模块片段会很大，膨胀 BMI 体积和解析时间。头文件单元本应部分解决此问题，但目前几乎没有构建系统正确支持（也许 msbuild 除外）。此外 clang 在裁剪全局模块片段中未用数据方面表现很差，使问题更糟。

barchar查看英文原文

A few points 1) modules only really help address time spent parsing stuff, not time spent doing codegen. Actually they can negatively impact codegen performance because they can make more definitions available for inlining/global opts, even in non-lto builds. For this reason it's likely best to compare using thin-lto in both cases. 2) when your dependencies aren't yet modularized you tend to get pretty big global module fragments, inflating both the size of your BMIs and the parsing time. Header units are supposed to partially address this but right now they are not supported in any build systems properly (except perhaps msbuild?). Also clang is pretty bad at pruning the global module fragment of unused data, which makes this worse again.

历次讨论

2025Hacker News 讨论帖141 分 · 42 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

将大型 C++ 数学软件包迁移到 C++20 模块

导读

HN 评论精选

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木