单核心下Haskell并行版Floyd-Warshall性能反超串行版原因探究

核心问题出在GHC跨模块编译的优化行为差异上——拆分到不同模块时，编译器的优化策略（内联、循环展开、惰性求值优化等）会受模块边界限制，合并到同一模块后，这些限制消失，性能表现回归预期。具体原因可以从这几个方向看：

1. 模块隔离导致的内联差异 #

GHC的内联优化默认在单模块内更激进，跨模块的话，除非给函数加INLINE注解或者开-O2级别的跨模块优化，否则函数调用的额外开销很难被消除。如果你的多文件版本存在这种情况：

• 串行版的核心循环函数没加INLINE，编译时也没启用足够的跨模块优化，导致循环里的函数调用开销一直存在；
• 并行版依赖的monad-par库函数大多自带INLINE注解，GHC对并行相关代码也会自动启用更激进的内联，把调用开销给抹平了。
  合并到同一文件后，GHC能对两个版本的核心函数做统一的内联优化，串行版的开销消失，并行版里par/pseq带来的调度开销就显现出来，这就符合书中单核心下并行版稍慢的预期了。

2. 惰性求值的优化不一致 #

Haskell的惰性求值在跨模块场景下，串行版可能会生成大量未求值的thunk（延迟计算单元），这些thunk的创建和后续求值会额外消耗内存和CPU。而并行版里的par和pseq会强制部分表达式的求值顺序，减少了thunk积累。合并到同一模块后，GHC能通过上下文分析，对串行版的惰性求值做更有效的严格性优化，消除不必要的thunk，让串行版性能拉满，此时并行版的调度开销就凸显出来。

3. 编译优化级别不统一 #

如果多文件版本中不同模块的编译选项不一致（比如并行版模块开了-O2，串行版用了默认的-O甚至-O0），性能差距会被直接放大。就算你全局加了优化选项，GHC跨模块编译时也可能因为依赖关系，对某些模块的优化打折扣。合并到同一文件后，所有代码用同一个优化级别，性能对比自然回归正常。

4. RTS运行时的细微差异 #

虽然你加了-N1强制单核心，但多文件编译出的二进制在RTS初始化时，可能因为模块链接顺序或依赖库的初始化逻辑，导致内存分配、垃圾回收策略有细微差别。比如并行版的RTS可能默认开了某些并行场景的内存优化，在单核心下意外提升了性能；合并到同一文件后，RTS初始化逻辑统一，这种意外优化就消失了。

验证建议 #

• 检查多文件版本的编译命令，确保所有模块都用相同的优化级别（比如统一加-O2）；
• 给串行版的核心函数加INLINE注解，重新编译多文件版本，看性能是否变化；
• 用ghc -ddump-simpl或-ddump-core查看核心代码，对比多文件和单文件下的代码生成差异，重点看内联、严格性标记和循环展开的情况。

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