bench/decimal の設計

設計目標

IEEE 10 進スタックの各層のコストを、すべての層が同じ結果を出さなければならない入力上で個別に計測します。これにより、ある層の変更が報告される 1 つの百分率の変化として現れます。

数学的背景

あるデータセットについて、$k_j$、$c_j$、$f_j$ をブロック $j$ におけるカーネル、コア、checked の各経路の呼び出しあたりの時間とします（カーネル経路のないケースは 2 番目の量のみを報告します）。報告される量は

$$\text{core\_pct} = 100\,\frac{\operatorname{med}_j (c_j - k_j)}{\operatorname{med}_j k_j}, \qquad \text{full\_pct} = 100\,\frac{\operatorname{med}_j (f_j - c_j)}{\operatorname{med}_j c_j},$$

すなわち、ある層のその下の層に対する相対的な中央値対応オーバーヘッドです。推定量、対応付け、ブートストラップ区間は bench の設計で導出されています。

設計上の判断

ワークロード

ケース	データセット	実装	プロトコル
decimal/add, decimal/mul, decimal/div	9、34、128、512 桁	kernel/coefficient (BigInt), core/decimal (Decimal::add_ctx, mul_ctx, div_ctx), full/checked (DecimalChecked)	Development

入力は固定の数字パターンです。コンテキストの精度はオペランドの桁数の和に 4 を加えたもので、div の被除数は 2 つのパターンの積です。したがってすべての結果は厳密な整数になります。

正しさのオラクル

出力は厳密な BigInt の結果と（compare により数値として）照合されます。オラクルと一致しない出力は失敗として数えられ、性能テストは失敗がないことを表明します。したがって、異なるものを計算する経路同士を比較することはありません。

厳密な入力

結果が厳密なので、算術演算の作業量は経路間で同一になります。早く丸めることで勝てる経路はなく、計測される差は表現、コンテキスト処理、検査のコストです。

正しさ／不変条件

• プランテストは通常のテスト実行ですべての仕様をコンパイルするため、ベンチマークが気づかれないまま壊れることはありません。
• 性能テストは failed_count == 0 を表明します。すべての出力がオラクルと一致したということです。
• シードは固定（20260715）されているため、計測順序とブートストラップの再標本は再現可能です。

却下した代替案

• サンプルごとのランダム入力。 入力の分散が計時の分散に混ざってしまいます。データセットごとに固定パターンを使えば、コードのコストを分離できます。
• エンドツーエンドの計時のみ。 単一の数値では、リグレッションがカーネル、コア、checked ラッパーのどこにあるのか判別できません。

境界

• native ターゲットのみ。他のターゲットについての主張はしません。
• 公開 API はありません。このパッケージは tools/benchmark.py のために存在します。
• 計測は性能ページの根拠であり、正しさの根拠には決してなりません。