basalt

工場出荷時のオーバークロックは測定結果を動かしません。ここでのすべてのレイテンシはサイクル単位であり、これはクロックではなくパイプラインの特性です。ブースト値がその横に記録されているのは、ウォールクロック比較を可能にするためだけです。ボードが影響するのは再現性であり、そのため basalt measure --board がそれを記録します。

そのレイアウトは、実際に使うとすぐに正しさが裏付けられる。単純なカーネルでは、S2R は write_barrier=0 を設定し、その結果を消費する IMAD は wait_mask=0x01 を持つ。LDCU.64 は write_barrier=1 を設定し、それに依存する STG.E は wait_mask=0x02 を持つ。すべてのプロデューサとコンシューマのペアが一致し、nvdisasm が .reuse と注釈する命令には、対応する reuse ビットが設定されている。

クイックスタート

CUDA のインストールも GPU も不要です。ツールチェーンスクリプトが固定版の再配布物（約45 MB）を取得します。管理者権限は不要で、PATH にも何も追加されません。```bash git clone https://github.com/sunnypatell/basalt.git cd basalt python -m venv .venv && source .venv/bin/activate # Windows: ..venv\Scripts\Activate.ps1 pip install -e ".[dev]"

python scripts/fetch_toolchain.py # pinned ptxas + nvdisasm python -m basalt.cli doctor # verify both oracles end to end python scripts/verify_all.py # every control in this README, in order

またはパッケージとして

pip install basalt-sass は、CLI、ライブラリ、および3つの測定済みテーブルをすべてインストールし、 実行時の依存関係はありません。マシンに既にCUDAがある場合はこれを使用してください。上記のチェックアウトは、 CUDAがない場合や、測定値を再現したい場合に適しています。```bash pip install basalt-sass basalt doctor basalt verify kernel.cubin

命令データベースをゼロから再構築するか、コミット済みのものを照会してください：```bash python -m basalt.cli build-isa # harvest, probe, write src/basalt/data/isa/sm_120a.json python -m basalt.cli isa --stats python -m basalt.cli isa IMAD.WIDE.U32 # one form, with its measured field layout python -m basalt.cli isa --opcode QMMA # every form of one opcode

The input content for this chunk is empty. No text was provided to translate. Please supply the actual Markdown content for chunk 17 of 29.```console $ python -m basalt.cli verify nvjpeg.sm_120.cubin 25 kernels, 0 with an error 7984 instructions in 789 blocks, 11580 dependencies checked across blocks: 0 errors, 3 warnings pair data: 3957 pairings from 25634 kernels, 427 producers with enough observations to use latency model: measured on NVIDIA GeForce RTX 5070 Ti

CLIが行うすべての処理はインポート可能で、実行可能な例を含むライブラリのインターフェースは docs/API.md にあります。

そして、他のすべての結果の信頼性を支える2つのコントロールがあります。1つ目はカード（GPU）が必要で、2つ目は同梱のライブラリが必要で、ハードウェアは一切不要です：```bash python scripts/roundtrip_corpus.py # reschedule all 441 corpus kernels, run both on the GPU

python scripts/fetch_toolchain.py --libs # ~1.2 GB, no admin, nothing on PATH python scripts/audit_shipped.py --libs third_party/cuda/13.3.1/libs

測定されたものであり、推測ではありません

ここに示す数値はツールによって出力され、クリーンチェックアウトから再生成されます。上記のコマンドが真実の源であり、以下の表はスナップショットです。

命令データベース。 すべてのエントリには、実際にアセンブルされたエンコーディングと、それを生成したコンパイラビルドが記載されています。

低精度ハードウェアはテンソル命令カバレッジに存在します:具体的には、HMMA と IMMA、非対称オペランドペアを含む FP8・FP6・FP4 型にわたる QMMA、ブロック単位の指数を保持するスケールファクタ形式 QMMA.SF と OMMA.SF、スパースな IMMA.SP、そして転置バリアントを含むすべての形状の行列移動命令 LDSM、STSM、MOVM です。

レイテンシ(RTX 5070 Ti 上)。 70 SM、すべてのフィットで R² ≥ 0.9998。依存チェーンのタイミングを計測して傾きを取ることで測定。チェーン長は推測ではなく、コンパイル済みの SASS から読み戻されています。

そのうちの 3 つは、basalt が同梱していた推測モデルと矛盾しています:DADD は 48 と想定され、POPC は 4 と想定され、各変換は 6 と想定されていましたが、往復では 24 と測定されました。

推測されたレイテンシモデルは、測定されたモデルの小さな近似ではありません。それが測定する根拠のすべてです。

そして、ゼロの stall はゼロサイクルではありません。 これは、未解決の結果を待つ明確に安全なエンコーディングであり、スケジュールされた命令が 4 サイクルかかるのに対し、約 37 サイクルを要します。そのため、ptxas -O0 は完全にゼロ化された制御ワードを出力し、コードは依然として正しく計算されますが、おおよそ 9 倍遅くなります。

コーパス内のすべてのカーネルについて、ベンダーコンパイラと一致します。 ptxas がコーパスからビルドするすべてのカーネルは、スケジューリングを行うすべての最適化レベルで、独自のスケジューリングと照合して検証されます:30,421 の依存関係、ゼロエラー。そのスイープはプッシュのたびに CI で実行され、このプロジェクトがこれまでに犯したすべてのモデリングエラーは、推論ではなくこのスイープによって捕捉されました。

判定はシリコンと一致します。 依存プロデューサー上のエンコード可能なすべての stall について、basalt の静的答えとハードウェアが実際に計算する結果は、ゼロの場合も含めて一致します。これはここで断言されるのではなく、テストとして保持されています。必要な stall を求める 3 つの独立した方法と、その過程で行われた修正を含む完全な証拠は、findings にあります。

そして、スケジュールが安全でないと判断した場合、シリコンも同意します。 233 個のカーネルに対するベンダー自身の動作スケジュールを取り、それぞれの実際の依存関係を 1 つ短縮し、basalt の判定を GPU が計算する結果と比較します:壊れていると判定された 79 個は壊れており、安全と判定されたものはどれも誤った答えを計算しませんでした。その数はゼロではなく 34 の見逃しから始まり、findings には原因と、修正にどれだけの誤報がかかったかが説明されています。なぜなら、最終結果だけを報告するスイープは、最初の結果を報告するスイープよりも価値が低いからです。

制御ビットも割り当てることができます

検証器は、スケジュールが安全かどうかに答えます。スケジューラは、同じ測定結果から、安全なスケジュールがどのようなものになるかに答えます:ptxas が生成したすべての制御ビットを破棄し、独自のものを計算し、その結果を検証器に渡し、GPU 上で同じカーネルのベンダーバージョンの隣で実行します。

カード上でコーパス全体に対して、スケジュールを生成するすべての最適化レベルで実行すると、比較可能な 439 個のカーネルすべてが、basalt 自身が割り出した制御ビットから、ベンダーのスケジュールとバイト単位で同一の結果を計算することがわかります。除外された 2 つはクロックとグリッド ID を読み取るため、それらは自分自身とも一致しません。findings は、それらをパーセンテージに含めるのではなく、その旨を述べています。

その制御こそが、他のすべてが信頼できる理由です。チェッカーとスケジューラは同じレイテンシモデルを読み取るため、モデル内の誤ったエントリは両方を同時に満たし、両方が間違っていながら互いに一致します。議論に利害関係を持たないのはシリコンだけです。手書きの 7 個のカーネルに対してスケジューラを実行したときは、長い間 7 個中 7 個が合格しました。300 個に対して実行したところ、41 個の誤りが見つかり、それ以降のすべてのモデル修正は、その数字が動くのを見ることから生まれました。

実際のバグはそのループから生まれました。プロデューサーとコンシューマーの間のウィンドウの外で費やされた stall は何の効果もなく、そこで費やすと、まだ短いプログラムで探索が終了します。安全なエンコーディングに固定された stall は、後のパスによって上書きされ、保証が小さな数に置き換えられていました。fp64 オペランドはレジスタペアを占有しますが、ニーモニックにはそれを示すものがないため、fp64 の依存関係の半分はチェッカーとスケジューラの両方から見えませんでした。命令のガードとして使用される述語は 13 サイクルを必要としますが、同じ述語をデータとして読み取る場合は 5 サイクルで済みます。ガードは命令が発行される前に解決されなければならないからです。さらに、スコアボードを待っても依存関係は完全には解決されません。プロデューサーはまだ独自の小さな stall を負っており、fp64 加算では 2 サイクルで、1 サイクル少ないと静かに間違った結果になります。これらのいずれも推論では見つかりませんでした。すべて、出力を実行して誤った数値を得ることで見つかりました。

[!NOTE] 1.0、その意味を具体的に。 完了していること:両方のオラクル、フィールドが書き込み可能であることが証明された命令データベース、実際の制御フローグラフに対するハザードチェッカー、3 つの独立した方法による 1 つの SKU でのレイテンシ測定、比較可能なすべてのコーパスカーネルをハードウェアにバイト単位で往復させるスケジューラ、そしてチェッカーが読み取るすべてのテーブルから除外された 2,762 個の出荷済みカーネルの監査。完了していないこと:構造上実行不可能な 12 個のコーパスカーネルと、ベンダー出力が決定的でない 2 個(すべて findings に記載)、10 個のオペコードは依然として測定値ではなく推測のレイテンシを保持しており、そのいずれも両コード群のプロデューサーになったことはありません。そして測定された GPU は 1 つだけで、finding 28 は、それが聞こえるほど重要ではないことを示しています。測定ではなく推測されたものがある場合、ツールはそれを事実に丸めるのではなく、その旨を明示します。roadmap と method を参照してください。

リポジトリ構成