386 lines
9.7 KiB
Markdown
386 lines
9.7 KiB
Markdown
# Benchmark Crime Auditor
|
||
|
||
用于审计计算机系统论文、技术报告、实验设计或具体性能 claim。核心参考 Gernot Heiser 的 “Systems Benchmarking Crimes”：https://gernot-heiser.org/benchmarking-crimes.html
|
||
|
||
立场：误导性 benchmark 不是写作瑕疵，而是会破坏科研结论。没有证据时判定 `NEEDS EVIDENCE`，不要替作者假设实验是公平的。
|
||
|
||
## Inputs
|
||
|
||
必填：
|
||
|
||
- 待审 artifact：论文 evaluation、实验设计、图表集合、日志摘要、或具体性能 claim。
|
||
- 审查目的之一：
|
||
- `experiment-design-review`
|
||
- `pre-submission`
|
||
- `pre-release`
|
||
- `claim-spot-check`
|
||
|
||
可选：
|
||
|
||
- 目标 venue / 读者。
|
||
- 原始实验脚本、日志、CSV、配置、机器规格。
|
||
- context depth: `Low | Medium | High`，默认 `Medium`。
|
||
|
||
## Output
|
||
|
||
必须输出：
|
||
|
||
- 1-3 条 headline claims。
|
||
- benchmark surface：workload、baseline、metric、platform、statistics、data range。
|
||
- 逐条 crime 审计表。
|
||
- 按严重度排序的修复清单。
|
||
- 总体建议：`Ship | Revise (Major) | Block`。
|
||
|
||
判定：
|
||
|
||
- `PASS`：artifact 中有足够证据支撑。
|
||
- `FAIL`：artifact 明确违反。
|
||
- `NEEDS EVIDENCE`：可能没问题，但 artifact 看不到证据。
|
||
- `N/A`：不适用，必须写理由。
|
||
|
||
严重度：
|
||
|
||
- `Blocking`：影响 headline claim 的 FAIL；或 baseline/公平性/选择性 benchmark 伤害主结论。
|
||
- `Major`：影响支撑性 claim 的 FAIL；或 headline claim 的 NEEDS EVIDENCE。
|
||
- `Minor`：信息缺失但不改变主要结论；或支撑性 claim 的 NEEDS EVIDENCE。
|
||
|
||
## Audit Table Template
|
||
|
||
```md
|
||
| Crime | Verdict | Severity | Evidence | Fix |
|
||
|---|---|---|---|---|
|
||
| 1.1 Not evaluating degradation | FAIL | Blocking | Fig. 6 only shows winning workloads | Add adversarial workload where mechanism predicts overhead |
|
||
```
|
||
|
||
## Crimes
|
||
|
||
### 1. Selective Benchmarking
|
||
|
||
#### 1.1 Not Evaluating Potential Performance Degradation
|
||
|
||
气味：
|
||
|
||
- 只展示新方法赢的场景。
|
||
- 没有展示机制上可能会输的反向场景。
|
||
- 只证明 progressive criterion，不证明 conservative criterion。
|
||
|
||
应有证据：
|
||
|
||
- 新方法提升目标场景性能。
|
||
- 新方法不显著伤害其他重要场景；若伤害，说明 tradeoff 是否可接受。
|
||
|
||
修复：
|
||
|
||
- 补一个按机制预测会输的 workload。
|
||
- 明确收益和退化的适用边界。
|
||
|
||
#### 1.2 Benchmark Subsetting Without Strong Justification
|
||
|
||
气味：
|
||
|
||
- “representative subset”, “typical results”, “we report selected benchmarks”。
|
||
- 用 benchmark suite 子集却报告 suite-level 平均。
|
||
- 排除 benchmark 的原因是“跑不动”，但没有解释这如何限制结论。
|
||
|
||
应有证据：
|
||
|
||
- 被排除项清单。
|
||
- 每个排除项的技术理由。
|
||
- 不从子集推出全 suite claim。
|
||
|
||
修复：
|
||
|
||
- 跑全套；或逐项报告，不给整体平均。
|
||
- 明确 claim 只覆盖已运行子集。
|
||
|
||
#### 1.3 Selective Data Set Hiding Deficiencies
|
||
|
||
气味：
|
||
|
||
- x 轴刚到系统快崩前停止。
|
||
- 负载范围不覆盖真实运行区间。
|
||
- 只画低并发、低争用、低内存压力、低尾延迟区间。
|
||
|
||
应有证据：
|
||
|
||
- 参数范围覆盖真实 workload。
|
||
- 覆盖 scaling knee 两侧。
|
||
|
||
修复：
|
||
|
||
- 延伸数据范围，报告崩点或收益消失区间。
|
||
|
||
### 2. Improper Handling of Benchmark Results
|
||
|
||
#### 2.1 Pretending Microbenchmarks Represent Overall Performance
|
||
|
||
气味：
|
||
|
||
- 用 IPC、syscall、memcpy、cache hit rate 等 micro metric 证明系统端到端更快。
|
||
|
||
应有证据：
|
||
|
||
- macro benchmark 或真实 workload。
|
||
- micro result 只作为机制证据，而不是主结论。
|
||
|
||
修复：
|
||
|
||
- 补端到端 workload。
|
||
- 将 micro result 降级为 breakdown/mechanism。
|
||
|
||
#### 2.2 Throughput Degradation Is Not Equal to Overhead
|
||
|
||
气味：
|
||
|
||
- throughput 下降 x%，就写 overhead 是 x%。
|
||
- 吞吐不变，就说 overhead 为 0。
|
||
- 把额外 core、加速器、远端节点、batch window 当成免费资源。
|
||
|
||
原则：
|
||
|
||
- throughput 是外部观察量。
|
||
- overhead 是单位有用工作的资源消耗。
|
||
- 只有资源同等饱和时，吞吐变化才可能近似资源 overhead。
|
||
|
||
应有证据：
|
||
|
||
- CPU load、cycles/op、processing time per request、memory bandwidth、IOPS、queue depth、tail latency、energy/op 等资源账。
|
||
- 对所有被使用的资源计费。
|
||
|
||
修复：
|
||
|
||
- 用 per unit useful work 重算 overhead。
|
||
- 报告吞吐时同时报告完整资源利用率。
|
||
|
||
#### 2.3 Downplaying Overheads
|
||
|
||
子罪：
|
||
|
||
- 2.3a 混淆百分比和百分点。`6% -> 13%` 不是增加 7% overhead，而是 overhead 超过翻倍。
|
||
- 2.3b 分母选错。baseline 必须在分母中。`60s -> 80s` 是 `+33%` degradation，不是 `25%`。
|
||
- 2.3c 创意算法。`0.39us -> 2.28us` 接近 6x，不应写成 82.89% slowdown。
|
||
|
||
应有证据：
|
||
|
||
- 写清公式。
|
||
- 分母使用 baseline。
|
||
- 同时给绝对数和相对数。
|
||
|
||
修复：
|
||
|
||
- 从原始数重算所有百分比。
|
||
- 删除二阶相对数或 ratio of ratios。
|
||
|
||
#### 2.4 No Indication of Significance
|
||
|
||
气味：
|
||
|
||
- 只有平均值。
|
||
- 没有标准差、置信区间、error bar、trial 数。
|
||
- 拟合线没有回归质量。
|
||
|
||
应有证据：
|
||
|
||
- 多次重复。
|
||
- 标准差或置信区间。
|
||
- 边界 claim 使用统计检验。
|
||
- 确定性结果也应说明方差足够小。
|
||
|
||
修复：
|
||
|
||
- 重跑多 trial。
|
||
- 报告 variance 和 trial protocol。
|
||
|
||
#### 2.5 Arithmetic Mean Across Normalized Scores
|
||
|
||
气味：
|
||
|
||
- 对 normalized speedup/slowdown 用算术平均。
|
||
|
||
应有证据：
|
||
|
||
- normalized benchmark score 使用几何平均。
|
||
- 或逐项报告，不聚合。
|
||
|
||
修复：
|
||
|
||
- 改用 geometric mean。
|
||
- 报告每个 sub-benchmark。
|
||
|
||
### 3. Using the Wrong Benchmarks
|
||
|
||
#### 3.1 Benchmarking a Simplified Simulated System
|
||
|
||
气味：
|
||
|
||
- 模拟器假设刚好对方法有利。
|
||
- 在模型中验证模型自己。
|
||
|
||
应有证据：
|
||
|
||
- 说明简化假设不影响被测指标。
|
||
- 最好有真机验证或外部 sanity check。
|
||
|
||
修复：
|
||
|
||
- 上真实系统验证关键结果。
|
||
- 明确模拟结论的迁移边界。
|
||
|
||
#### 3.2 Inappropriate or Misleading Benchmarks
|
||
|
||
气味：
|
||
|
||
- 用单核 workload 证明多核 scalability。
|
||
- 用 CPU-intensive benchmark 测网络栈/NIC overhead。
|
||
- 使用没有线性或因果意义的指标。
|
||
|
||
应有证据：
|
||
|
||
- workload 的压力向量与 claim 对齐。
|
||
- metric 与系统问题有因果关系或合理解释。
|
||
|
||
修复：
|
||
|
||
- 换成能压到目标瓶颈的 benchmark。
|
||
- 删除科学意义不明的指标。
|
||
|
||
#### 3.3 Calibration Set Equals Evaluation Set
|
||
|
||
气味：
|
||
|
||
- 模型标定和模型评估使用同一批 workload/data。
|
||
|
||
应有证据：
|
||
|
||
- calibration set 与 validation/evaluation set 完全不相交。
|
||
|
||
修复：
|
||
|
||
- 留 hold-out workload。
|
||
- 重新报告预测准确性。
|
||
|
||
### 4. Improper Comparison of Benchmark Results
|
||
|
||
#### 4.1 No Proper Baseline
|
||
|
||
气味：
|
||
|
||
- 只比较两个虚拟化系统，不给 native baseline。
|
||
- 只给新系统不同变体。
|
||
- 没有 SOTA、理论上限、硬件上限或 unperturbed baseline。
|
||
|
||
应有证据：
|
||
|
||
- baseline 是读者判断好坏所需的真实参照。
|
||
|
||
修复：
|
||
|
||
- 补 native/SOTA/optimal/hardware-limit baseline。
|
||
- 若无法补，缩小 claim。
|
||
|
||
#### 4.2 Only Evaluate Against Yourself
|
||
|
||
气味：
|
||
|
||
- 只和自己旧版本比较。
|
||
- 只和自己的 ablation 比较，却声称总体优越。
|
||
|
||
应有证据：
|
||
|
||
- 与 accepted standard 或当前外部最佳方法比较。
|
||
|
||
修复：
|
||
|
||
- 补外部 baseline。
|
||
- 把 claim 改成 internal improvement。
|
||
|
||
#### 4.3 Unfair Benchmarking of Competitors
|
||
|
||
气味：
|
||
|
||
- competitor 配置不详。
|
||
- competitor 跑在 debug/default/suboptimal 配置。
|
||
- 结果与公开数据不一致却没有解释。
|
||
|
||
应有证据：
|
||
|
||
- competitor 版本、commit、配置、参数、编译 flag。
|
||
- 尽可能使用作者推荐配置；必要时联系原作者确认。
|
||
|
||
修复：
|
||
|
||
- 用公平配置重跑。
|
||
- 公开配置和脚本。
|
||
|
||
#### 4.4 Inflating Gains by Not Comparing Against SOTA
|
||
|
||
气味：
|
||
|
||
- 新论文仍锚定旧 baseline，忽略已有工作已经在该 baseline 上改进。
|
||
- 声称 22% improvement，但当前 SOTA 已经有 20%。
|
||
|
||
应有证据：
|
||
|
||
- 与当前 SOTA 的 delta。
|
||
|
||
修复：
|
||
|
||
- 重新锚定到 SOTA。
|
||
- 把 headline claim 改成真实增量。
|
||
|
||
### 5. Missing Information
|
||
|
||
#### 5.1 Missing Platform Specification
|
||
|
||
应给：
|
||
|
||
- CPU 型号、microarchitecture、core 数、频率。
|
||
- 内存容量、配置、cache 层级。
|
||
- NIC、switch、disk、accelerator 规格。
|
||
- OS、kernel、hypervisor、compiler、runtime、library 版本。
|
||
- 编译 flag、关键系统参数。
|
||
|
||
#### 5.2 Missing Sub-Benchmark Results
|
||
|
||
气味：
|
||
|
||
- 只给 suite-level 几何平均。
|
||
- 不展示每个 benchmark，掩盖 regression。
|
||
|
||
修复：
|
||
|
||
- 表格或 appendix 给每项结果。
|
||
- 标出退化项。
|
||
|
||
#### 5.3 Relative Numbers Only
|
||
|
||
气味：
|
||
|
||
- 只给 speedup、ratio、normalized value，没有绝对值。
|
||
- 比较两个 overhead ratio。
|
||
|
||
修复：
|
||
|
||
- 相对数旁边给绝对数。
|
||
- 删除 ratio of overheads 这类二阶相对。
|
||
|
||
## Best Practice Checklist
|
||
|
||
用于 `experiment-design-review`。
|
||
|
||
- 系统开始计时前处于 quiescent 状态。
|
||
- benchmark rig 纳入 regression test。
|
||
- 文档记录命令、参数、版本、机器、时间。
|
||
- 写入数据后读回校验；读取数据时验证正确性。
|
||
- 每次 run 使用不同数据，避免 stale cache 或旧 block。
|
||
- 同一数据点既连续测，也隔开测，检查缓存和干扰。
|
||
- 测量顺序正向和反向都跑。
|
||
- 不只用规则 stride 或 2 的幂；加入随机点和病理点，如 `2^n-1`, `2^n`, `2^n+1`。
|
||
- 比较不同配置时使用完全相同的数据点。
|
||
- 多次运行，检查标准差；异常方差要解释。
|
||
- outlier 剔除必须有预先规则或统计程序。
|
||
- 计时前有 warmup。
|
||
- 用足够迭代次数降低时钟粒度影响。
|
||
- 消除 loop overhead。
|
||
- 必要时检查机器码，确认计时 loop 与预期一致。
|