计算机架构师找不到“平均”：关于平均值的缺陷
Computer Architects Can't Find the Average
Or, Why All Means Are Bad
By dgsq Posted on April 27, 2025
计算机架构师们在如何找到“平均”这件事上无法达成一致。
多年来，该领域的学术从业者一直在争论总结他们设计的平均性能的适当方法。1 也就是说：给定 \(n\) 个工作负载，如果系统 \(A\) 在每个工作负载上比系统 \(B\) 快 \(S_1, S_2, \ldots, S_n\)，那么平均来说，应该说系统 \(A\) 快多少？ 我认为这个争论有点毫无意义。
在大多数情况下，人们倾向于使用算术平均值 \(\left(\frac{1}{n} \sum_{i=1}^n S_i\right)\) 或几何平均值 \(\left(\sqrt[n]{\prod_{i=1}^n S_i}\right)\)。 Henessey 和 Patterson 著名的 Computer Architecture: A Quantitative Approach 提倡后者：
使用几何平均值可确保两个重要属性：
- 比率的几何平均值与几何平均值的比率相同。
- 几何平均值的比率等于性能比率的几何平均值，这意味着参考计算机的选择是无关紧要的。
因此，使用几何平均值的动机是充分的，尤其是在我们使用性能比率进行比较时。
其他人不同意 H&P 的推理，但我认为它已经足够好了。
All Means are Bad
最近（嗯，现在已经一年多了），一篇论文 paper 发表在 IEEE Computer Architecture Letters 上，标题为 R.I.P. Geomean Speedup Use Equal-Work (Or Equal-Time) Harmonic Mean Speedup Instead。 其作者 Eeckhout 认为 geomean 不好，人们应该使用他所谓的 Equal-Work Harmonic Speedup 或 Equal-Time Harmonic Speedup。 Eeckhout 也在 HPCA 2025 上展示了这项工作，作为 Best of Computer Architecture Letters 会议的一部分。
Eeckhout 似乎对几何平均值的主要不满是它“缺乏物理意义”。 他声称使用他的替代方案之一更好，因为它们具有物理意义。 他提出的替代方案之一是 Equal-Time Harmonic Speedup (\(ETS\))，它只是在每个工作负载上观察到的加速的调和平均值。
\[ETS = \frac{n}{\sum_{i=1}^n \frac{1}{S_i}}\]
为什么要使用调和平均值而不是几何平均值？ 好吧，如果每个工作负载在基线系统上运行的时间相同，则 ETS 等于按顺序运行每个工作负载时观察到的总加速。2 Eeckhout 说，这种物理意义为我们提供了一个令人信服的理由来使用类似的东西而不是几何平均值。
但是这个物理意义并不重要！ 当我报告 SPEC 的分数时，我并不_真正_关心以顺序方式运行该基准测试中的每个工作负载需要多长时间！ 我并不期望运行一个数独求解器 (exchange2)，然后立即编译 gcc，然后执行视频压缩 (x264)。 我的意思是，我可能会在某个时候运行所有这些，但肯定不是在完全相同的时间内。3 虽然调和平均值具有明确的物理意义，但对于许多基准测试套件来说，它并不是一个真正重要的意义。
诚然，我也不_真正_关心这些工作负载的几何平均值。 我同意 Eeckhout 的说法，即 geomean 没有明确的物理意义。 但归根结底，这是在没有明确物理意义的平均值和物理意义在大多数情况下都不相关的平均值之间做出选择。
So is there actually a good number to report?
除非你真正知道在真实系统中运行的工作负载的精确组合，否则你报告的任何数字都无法准确预测你的设计对该系统的影响。 像 SPEC 这样的基准测试在显示一般性能模式方面是有用的，但无论你如何处理，当使用通用基准测试套件时，单个数字总是无法提供机器之间的完美比较。
如果你确实知道你关心的特定应用程序，并且你知道它们的相关重要性，那么请务必采用它们的加权平均值，你就可以确定了。
否则，我建议只使用 geomean。 它易于比较，并且其他人都很熟悉它。 使用其他平均值需要你自担风险：它们都会以不同的方式出错。
Why are people still talking about this?
我真的不知道。 似乎这场争论现在应该结束了。
我以前的一位导师曾经告诉我，他从不看学术论文的评估部分。 如果论文其余部分提出的想法听起来合理，也许他会尝试将其创新应用于生产设计。 如果这个想法听起来很可笑，或者解决了另一个他已经解决的问题，那么它就没有任何用处，无论作者声称有多少加速。4
还有其他问题导致了行业对学术评估的看法。 但我分享这个轶事只是想说：学术计算机架构师应该花更多的时间提出新的、本质上有趣的想法，而不是花更少的时间讨论哪种平均方法最没有意义。
Footnotes
- 这场争论至少可以追溯到 1986 年的论文 How not to lie with statistics: The correct way to summarize benchmark results。 Eeckhout 在 他的论文 中很好地描述了这段历史。↩
- 有趣的是，即使我们可以为
ETS分配一个物理意义，它仍然可以提供非直观的结果。 例如，如果机器 \(A\) 运行工作负载 1 的速度是机器 \(B\) 的两倍 (\(S_1=2\))，但工作负载 2 的速度仅为一半 (\(S_2 = 0.5\))，那么计算 \(A\) 相对于 \(B\) 的ETS得到 0.8（意味着总体减速）。 但通过对称性，\(B\) 相对于 \(A\) 的ETS也是 0.8。 两台机器怎么可能都比另一台“慢”？ 因为与几何平均值不同，参考机器对ETS确实很重要！ 我们根据我们的起点为工作负载分配不同的权重！ ↩ - 就个人而言，我的机器可能花费更多的时间运行
x264，而不是编译gcc或解决数独问题。 谢谢 YouTube。↩ - 除了平均工作负载结果这个相对不重要的问题之外，还有其他问题导致了这种对学术评估的看法。 特别是，学术微架构模拟器通常不准确，并且基线系统通常是不良的比较点。↩