検索エンジンのスレッド数スケーリングを実測したときの話です。本編の結果は別記事に書きました。今回はその裏側——最初の計測結果を丸ごと捨てた話をします。ベンチマークを取る人には他人事ではないはずです。
最初の計測は、きれいで、間違っていた
1スレッドから順に10スレッドまで、順番に計測しました。結果はきれいな曲線を描き、「11スレッドが最速5.2秒」という数字も出ました。グラフにして、さあ記事に——という段階で、念のため同じ条件を測り直したんです。
同一条件で、結果が最大54%ブレました。 4スレッドは11.0秒だったのが9.0秒に。11スレッドは5.2秒だったのが8.0秒に。5.2秒という「最速記録」は、再現しませんでした。
計測クジラを引いたわけでも、バックグラウンドプロセスの仕業でもありません。犯人はマシンの筐体でした。
犯人: ファンのないMacの熱履歴
計測機は MacBook Air（Apple M4）。ファンレスです。連続して負荷をかけると本体が熱を持ち、サーマルスロットリング（熱によるクロック制限）がかかります。つまり、計測結果が「直前に何を測っていたか」に依存する。
これが厄介なのは、ランダムなノイズではなく系統誤差になることです。1→2→…→10スレッドと順に掃引すると、後半のスレッド数ほど「前の計測で温まった状態」で測ることになる。多スレッド側が不当に不利になり、しかもそれが毎回同じ向きに働くので、何回測って平均しても消えません。ブレではなく偏りです。
最初の「11スレッドが最速5.2秒」は、たまたま冷えた状態で走った1回でした。きれいなグラフほど疑うべきでした。
是正: ラウンドロビン
対策はシンプルです。スレッド数ごとにまとめて測るのをやめて、1〜16スレッドを1周する掃引を4ラウンド繰り返し、各スレッド数はラウンド間の中央値を取る。 こうすると、どのスレッド数も「冷えた状態」と「熱い状態」を均等に経験します。熱履歴の偏りが特定のスレッド数に集中しない。
是正後の計測（128回）で出た結論が、本編の「8スレッドで頭打ち・3.0倍」です。5.2秒という数字は消え、7.4秒が再現可能な床になりました。
是正が効いたことを、どう確かめるか
「新しい計測は正しい」と言うには根拠が要ります。今回は、ヒット件数が十数倍違う2つの検索語（10,967件と722件）で曲線がほぼ完全に一致したことを妥当性の裏づけにしました。もし熱や他の外乱が残っていれば、独立した2系列がここまで揃う理由がありません。
初報のCSVは捨てずに参考として保存してありますが、記事には使わないと決めました。撤回した数字を「参考値」として載せ続けると、いつか誰かがそれを引用します。
教訓
- ファンレス機のベンチは、測定順序が結果に乗る。 順に掃引した曲線は後半が系統的に不利
- きれいな単発記録ほど再現確認を。 冷えた1回は最速記録に化ける
- 是正はラウンドロビン＋中央値。 冷熱を全条件に均等配分する
- 妥当性は独立系列の一致で確かめる。 同じ計測の繰り返しだけでは偏りは見えない
ベンチマークの敵はライバル製品ではなく、自分の筐体の熱でした。
そして、ストレージを専有している巨大ログを圧縮して保管し、さらに高速に検索したいなら UwView Pro をどうぞ。永続索引・圧縮キャッシュ検索・約1/9保管で、開き直しも検索も一段速くなります（全OS対応・買い切り $129／月額 $9）。
開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。
お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。機能の有無は各バージョン時点の確認であり、今後のアップデートで変わる可能性があります。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。
コメント