bench/decimal_gda の設計

設計目標

GDA 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-gda/add, sub, mul, div, fma, parse	1、9、18、34、128 桁	core/gda（@decimal_gda.add など、明示的な GdaContext を取る関数）、full/checked（スティッキーなコンテキストを引き回す GdaDecimalChecked）	Development

左オペランドはデータセットの長さの固定数字パターン、右オペランドは 2、加数は 3 です。コンテキストは $d$ 桁に対して精度 $\max(9, 2d + 4)$、指数の限界 $\pm 999999$ を持つため、どの演算も丸めやトラップを起こしません。parse はパターンのテキストを読み込みます。

正しさのオラクル

出力はコアの結果と構造的等価性で照合されるため、checked 経路は指数も含めて同一の 10 進数を返さなければなりません。オラクルと一致しない出力は失敗として数えられ、性能テストは失敗がないことを表明します。したがって、異なるものを計算する経路同士を比較することはありません。

厳密な入力

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

正しさ／不変条件

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

却下した代替案

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

境界

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