エクスレラ8

シミュレーションのための推測。 検証の革新

これは興味深いアイデアで、ハードウェアがサポートする投機的並列処理を使用してシミュレーションを高速化しますが、ひねりを加えてカスタム ハードウェアを必要とします。 Paul Cunningham (Senior VP/GM、Cadence の Verification)、Raúl Camposano (Silicon Catalyst、起業家、元 Synopsys CTO、現在 Silvaco CTO) と私は研究アイデアに関するシリーズを続けます。 いつものように、フィードバックを歓迎します。

シミュレーションの推測

イノベーション

今月のおすすめは Chronos: アクセラレータの効率的な投機的並列処理. 著者は、2020 Conference on Architectural Support for Programming Languages and Operating Systems で論文を発表し、MIT 出身です。

マルチコア プロセッサを使用して並列処理を利用することは、並列処理が自明であるアプリケーションの XNUMX つのオプションです。 他のアルゴリズムはそれほど簡単に分割できないかもしれませんが、固有の並列処理を利用した投機的実行の恩恵を受ける可能性があります。 通常、投機的実行はキャッシュ コヒーレンスに依存し、特にシミュレーションではオーバーヘッドが高くなります。 この方法はコヒーレンスの必要性をバイパスし、タスクの実行を物理的にローカライズして、ターゲットの読み取り/書き込みオブジェクトによってタイルを計算し、グローバルなコヒーレンス管理を必要とせずに競合検出をローカルで検出できるようにします。 タスクは投機的に並行して実行できます。 検出された競合は、子タスクを介してタスクからアンロールされ、他のスレッドを停止する必要なく再実行できます。

ここでもう一つ注意点。 この方法は、ほとんどのハードウェア アクセラレーション手法とは異なり、遅延ベースのシミュレーションをサポートします。

ポールの見解

うわー、なんて素晴らしいMITのハイオク紙だ! 並列計算について聞かれると、すぐにスレッド、ミューテックス、メモリ コヒーレンシについて考えます。 もちろん、これは最新のマルチコア CPU の設計方法です。 しかし、ハードウェアで並列化をサポートする唯一の方法ではありません。

この論文では、順序付けられたタスクのキューに基づく Chronos と呼ばれる並列化のための代替アーキテクチャを提案します。 実行時に、タスクはタイムスタンプ順に実行され、各タスクはキューに動的に追加される新しいサブタスクを作成できます。 実行は、いくつかの初期タスクをキューに入れることで開始され、キューにタスクがなくなると終了します。

キュー内のタスクは複数のプロセッシング エレメント (PE) に並行してファーム アウトされます。これは、現在のタスクが完了する前に、Chronos が将来のタスクを投機的に実行していることを意味します。 現在のタスクが投機的に実行された将来のタスクを無効にする場合、それらの将来のタスクのアクションは「元に戻され」、再度キューに入れられます。 この概念をハードウェアに正しく実装するのは簡単ではありませんが、外部ユーザーにとっては美しいことです。タスク キューが単一の PE でシリアルに実行されているかのようにアルゴリズムをコーディングするだけです。 ミューテックスをコーディングしたり、デッドロックを心配したりする必要はありません。

著者は、Chronos を SystemVerilog に実装し、それを FPGA にコンパイルします。 紙の多くは、彼らがどのようにタスク キューを実装したか、および最大限の効率を得るためにハードウェアで必要な展開を行う方法を説明することに専念しています。 Chronos は、タスク キュー ベースのアーキテクチャに適した 32 つのアルゴリズムでベンチマークされています。 各アルゴリズムは 3 つの方法で実装されます。15 つ目は専用のアルゴリズム固有の PE を使用する方法、3 つ目は市販のオープン ソース 14 ビット組み込み RISC-V CPU を PE として使用する方法です。 Chronos のパフォーマンスは、Chronos に使用されている FPGA と同様の価格の Intel Xeon サーバーで実行されているアルゴリズムのマルチスレッド ソフトウェア実装と比較されます。 結果は印象的です。Chronos は、Xeon サーバーを使用する場合よりも XNUMX 倍から XNUMX 倍優れたスケーリングを行います。 ただし、表 XNUMX と図 XNUMX を比較すると、これらの利点のほとんどが Chronos アーキテクチャ自体ではなく、アルゴリズム固有の PE によるものであることが少し心配になります。

これが検証ブログであることを考えると、私は自然にゲートレベルのシミュレーション ベンチマークに注目しました。 EDA 業界は、ロジック シミュレーションを並列化するために多額の投資を行ってきましたが、いくつかの特定のユース ケースを超えて大きな利益を得ることは困難であることが証明されています。 これは主に、ほとんどの現実世界のシミュレーションのパフォーマンスが、L3 キャッシュで欠落し、DRAM に送信されるロード/ストア命令によって支配されるためです。 このホワイト ペーパーでベンチマークしたテストケースは 32 つだけで、それは小さな XNUMX ビットのキャリー セーブ アダーです。 もしあなたがこのブログを読んでいて、もっと徹底的なベンチマークを行うことに興味があるなら、私に知らせてください - Chronos が現実世界のシミュレーションで本当にうまくスケーリングできるなら、それは巨大な商業的価値を持つでしょう!

ラウルの見解

この論文の主な貢献は、 Spatially Location Ordered Tasks (SLOT) 実行モデル これは、並列処理とスペキュレーションを利用するハードウェア アクセラレータや、実行時にタスクを動的に生成するアプリケーションにとって効率的です。 シミュレーションには動的な並列処理のサポートが不可欠であり、投機的な同期は魅力的なオプションですが、コヒーレンシのオーバーヘッドが高すぎます。

SLOT は、各タスクが XNUMX つのオブジェクトに対して操作 (書き込み) するように制限することで一貫性の必要性を回避し、順序付けられたタスクをサポートしてマルチオブジェクトの原子性を有効にします。 SLOT アプリケーションは、タイムスタンプとオブジェクト ID によって特徴付けられる順序付けられた、動的に作成されるタスクです。 タイムスタンプは順序の制約を指定します。 オブジェクト ID は、データの依存関係を指定します。つまり、タスクは、同じオブジェクト ID を持つ場合にのみ、データに依存します。 (読み取り依存関係がある場合、タスクは投機的に実行できます)。 オブジェクト ID をコアまたはタイルにマッピングし、各タスクをそのオブジェクト ID がマップされている場所に送信することで、競合検出は (複雑な追跡構造なしで) ローカルになります。

  クロノス システムは、16MHz で動作する 4 つのアプリケーション固有の処理要素 (PE) を持つ 125 タイルのシステムとして AWS FPGA フレームワークに実装されました。 このシステムは、20 コア/40 スレッドの 2.4 GHz Intel Xeon E5-2676v3 で構成されるベースラインと比較されます。これは、価格が FPGA のもの (約 2 ドル/時間) に匹敵するという理由で特に選択されたものです。 2.45 つの PE で 44.9 つのタスクを実行すると、Chronos はベースラインよりも 8 倍速くなります。 同時実行タスクの数が増えると、Chronos 実装は 15.3 タイルで 5 倍の自己相対スピードアップにスケールアップします。これは、CPU 実装の XNUMX 倍のスピードアップに相当します。 彼らはまた、アプリケーション固有の PE ではなく、汎用 RISC-V に基づく実装を比較しました。 PE は RISC-V よりも XNUMX 倍高速でした。

この論文は、SLOT 実行モデルの概念から定義、ハードウェアの実装、4 つのアプリケーションの従来の Xeon CPU との詳細な比較まですべてをカバーしているため、印象的でした。 その努力は相当なもので、Chronos は SystemVerilog の 20,000 行を超えています。 その結果、(5.4 つのアプリケーションの) 平均 4 倍の高速化がソフトウェア並列バージョンよりも高速化されました。これは、並列処理の増加と投機的実行の使用の増加によるものです。 この論文は、シミュレーション以外のタスクへの適用についても読む価値があります。 この論文には XNUMX つの例が含まれています。

この投稿を共有する:

私たちとチャット

やあ! どんな御用でしょうか?