关于GHC -N（并行）标志行为及无显式并行代码性能异常的问询

你的问题核心在于：GHC的运行时系统（RTS）在启用-N标志时，会默认开启并行垃圾回收（Parallel GC），而你的代码本身没有任何并行计算逻辑，并行GC的额外开销反而拖慢了整体性能。

从GC统计数据里找线索 #

看你提供的垃圾回收日志：

• 单线程（无-N）运行时：
  • GC总耗时仅0.155s，所有GC都是串行的（Gen 0 52088 colls, 0 par）
  • 生产力高达98.7%，说明几乎所有时间都在执行你的计算逻辑
• 启用-N12时：
  • GC总耗时飙升到20.221s，所有Gen 0回收都是并行的（Gen 0 52088 colls, 52088 par）
  • 用户时间（1m14.904s）远大于真实时间（22.702s），这说明多线程在GC过程中产生了大量的调度、同步开销，这些开销完全抵消了并行GC的潜在收益（甚至反过来拖慢了程序）

另外注意到日志里的SPARKS: 0——这说明你的代码没有生成任何可以并行执行的计算任务，所以你的求和逻辑全程都是串行运行的，-N12并没有让计算本身并行化，只是让GC用了12个线程。

GHC的RTS决策机制 #

GHC的-N<N>标志本质是设置RTS可用的OS工作线程数量，而RTS会默认利用这些线程做两件事：

1. 执行你代码中生成的并行任务（通过par/pseq或并行库生成的sparks）
2. 运行并行垃圾回收

对于没有任何并行逻辑的串行代码，RTS只会用这些线程来做并行GC。而并行GC并不是在所有场景下都能提升性能：当GC本身的开销不大时（比如你的程序，单线程GC只占总时间的1.3%），并行GC带来的线程同步、调度成本会远超过它能节省的时间，最终导致整体性能下降。

相关文档和解决方案 #

你可以在GHC官方文档中找到这些机制的详细说明：

• 并行垃圾回收：GHC用户指南中专门有章节讲解并行GC的行为、开销和调优选项
• -N标志细节：在RTS选项文档里，明确说明了-N会默认启用并行GC，同时可以用-qg选项强制禁用并行GC（即使开启了-N）

如果你只是想测试多线程对计算的影响，但代码本身没有并行逻辑，可以试试：

./test +RTS -s -N12 -qg

这个命令会开启12个工作线程，但强制用串行GC，你会发现性能会回到接近单线程的水平，验证并行GC是性能下降的元凶。

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