# 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 与预期一致。