ISCA 2018で発表される予定の論文、"FireSim: FPGA Accelerated Cycle Exact Scale-Out System Simulation in the Public Cloud" をざっと流し読みした。
EC2 F1インスタンスを勉強している身としては、把握しておきたい内容ということで、分かったことをまとめていくことにした。 まだ途中だし、2~3時間で読んだので全然理解としては足りないのだが、概要をまとめていく。
ちなみに、最後まで読んでわかったのだが、Rocket Chip @ 3.2GHz というのは「仮想の」動作周波数で、ネットワークの帯域がいくらであると仮定して、それに合わせてシミュレーションのタイミングも間引くことで「正確なサイクル」での、シミュレーションを可能としている、ということらしい。 最初読んだときに、「FPGAって3.2GHzで動くの!?」と思ってびっくりしてしまった。
ベンチマークを取るために、1024コアのRISC-V Rocket-Chipを32個のf1.16xlarge を動かしている。 これで1時間のシミュレーションで$400程度だったというのだから、研究室で自前でFPGAを持つよりもコスト的にはお得だなあ...という感じ。
ちなみにオリジナルの論文はこちら。図もすべてこちらから参照している。
- FireSim: FPGA-Accelerated Cycle-Exact Scale-Out System Simulation in the Public Cloud
https://sagark.org/assets/pubs/firesim-isca2018.pdf
FireSim: クラウド上で構築するサイクルベースでスケールアウト可能な、FPGAでのシステムシミュレーション
概要
FireSimはサイクルベースなRTLシミュレーション環境である。 これまでのように単体のFPGAを使うわけではなく、Amazon EC2 F1インスタンスを使用するところが新規部分である。 1024個の3.2 GHz 4コアサーバと、16GBのメモリ、さらに200Gbit/sのインターコネクトネットワークを使って3.4MHzのシミュレーションを行っていたが、Amazon EC2 F1インスタンスを使うことにより、4096コアと16TBのメモリのシステムをシミュレーションし、1秒当たり140億命令を実行する環境を構築した。
イントロダクション
Warehouse Scale Computingにおいて、個々のサーバを密に結合させる方向にトレンドが進んでいる。
ソフトウェアシミュレータを使用した場合には、シミュレーション速度がボトルネックになる(5~100KIPS)。
そこで、FPGAベースのシミュレーションフレームワークであるFireSimを提案する。 ユーザはネットワークのトポロジと、ブレードサーバのタイプを選択する、FireSimは自動的に高性能シミュレーション環境をAmazon EC2 F1インスタンス上に構築する。 ユーザは、FPGA上にシミュレーション環境を構築するという煩雑な作業から解放されるという点が利点である。
- 第2章 : 近年のハードウェアのトレンドを紹介する。高速かつコスト効率の高いシミュレーション環境の必要性を説明する。
- 第3章 : FireSimのシミュレーション環境について説明する。
- 第4章 : ソフトウェアを実行し、デザイン構成のシミュレーションを行う。
- 第5章 : シミュレーションの性能とスケーリングの可能性について説明する。
- 第6章 : 過去のWarehouseスケールのハードウェア・ソフトウェアの協調設計について説明する。
- 第7章 : スケーリングアウトするシステムシミュレーションについて、過去の研究について説明する。
- 第8章 : FireSim の性能と機能を向上させるための概要について説明する。
パブリッククラウド上のFPGA
FPGAの開発環境はとにかくひどい。ビルドに時間がかかり、並列化するにも、ライセンスの制限に引っかかる。大きなFPGAを導入しても、その管理コストは馬鹿にならず、研究用プロトタイプとして共有使用するのも非常に難しい。
しかし、最近はAmazonはじめとするクラウドサービスとして、FPGAを導入する企業が増えてきている。 Amazon, Microsoft, Huawei, Alibabaなどである。 FPGAを高性能計算リソースとして使用することを期待している。
FireSimはAmazon EC2 F1インスタンスを使用するプラットフォームである。 EC2のf1.2xlargeとf1.16xlarge を使用する。
f1.2xlarge
: ホストインスタンス 8 vCPU / 122GB DRAM, 10Gbit/s ネットワーク, 1 Xilinx UltraScale+ FPGAf1.16xlarge
: ホストインスタンス 64 vCPU / 976GB DRAM, 25Gbit/s ネットワーク, 8 Xilinx UltraScale+ FPGA
各FPGAには、64GBのDRAMが接続されている。4-CH接続である。
FPGA Developr AMIというFPGA開発用のOSイメージを提供しており、FPGA合成用のツールとライセンスが提供されている。
さらに、F1インスタンスは m4.16xlarge
インスタンスを備えており、これにより高性能ネットワーク(25Gbit/s) をサポートしている。
FireSimでは、このインスタンスを使用してルートスイッチモデルを実行している。
FireSim
FireSimのモデルは、複数のネットワークに接続されたサーバブレードモデルから構成されている。 これをFAME-1モデルと呼ぶ。 ターゲットのネットワークは、ホストサーバ上で動作するサイクルベースのC++スイッチモデルに接続されている。
図1と図2は、ターゲットのトポロジと、ターゲットとホストのマッピングの構成について説明している。 64ノードのシミュレーション環境は、8つのtop-of-rack(TOR)スイッチに接続されている。
サーバブレードのシミュレーション
ターゲットサーバのデザイン
FireSimの計算サーバは、Rocket Chip SoC Generator により構成されている。 このRocket ChipはChiselで記述されている。 Rocket ChipはVerilog RTLを生成することができる。これには、RISC-V Rocket CPU、L1, L2キャッシュ、カスタムアクセラレータ(表2)、そしてI/Oペリフェラルが含まれる。
ブレードの構成 | RTL or モデル |
---|---|
1から4 コアのRISC-V コア @ 3.2GHz | RTL |
RoCCアクセラレータ(表2) | RTL |
16KB L1I\$, 16KB L1D\$, 256KB L2$ | RTL |
16GB DDR3 | FPGA Timing Model |
200Gbit/s Ethernet NIC | RTL |
ディスク | ソフトウェアモデル |
アクセラレータ | 目的 |
---|---|
ページフォルトアクセラレータ | メモリの高速アクセスパス |
Hwacha[25] | ベクトル計算 |
HLS-Generated | カスタムデザインの早期スケールアウト |
ターゲットサーバのネットワークインタフェースコントローラ
完全なサーバモデルを構築するために、我々は2つの新しいペリフェラルをRocket Chip SoCに挿入した。 一つ目はChiselで記述されたネットワークインタフェースコントローラ(NIC)であり、SoCのトップレベルのネットワークインタフェースである。 NICのデザインは図3に示されている。
NICはネットワークスイッチからのEthernetパケットを送受信する。 近年の研究では、レイテンシを削減するためにCPUとNICを1つのチップ上に実装する試みがなされているが、私たちのNICも同様の手法を取っている。 NICはRocket Chipのネットワークに、TileLinkを通じて直接接続されている。 これにより、NICはサーバSoCの共有L2キャッシュを直接読み書きすることができる。
私たちの実装したNICは大きく3つの領域に分割されている。
- コントローラ
- 送信パス
- 受信パス
この中で、送信パスと受信パスはCPUにメモリマップドI/Oで接続されている。 送信パスと受信パスは合計4つのキューを持っており、また割り込みにより受信したことを通知されることもできる。
送信パスは、まずReaderユニットがメモリからデータを読み込み、それをReservation Bufferに渡す。 送信パスはデータをネットワーク上に送信し、送信がすべて完了すると、完了バッファからその情報を受信する。 (※ ここから先はSend Pathの詳細な構成が語られているが省略)
受信パスは、まずはPacket Bufferがデータを受信するところから始める。 パケットは完全に受信できない場合(つまり十分な受信バッファの空き容量がない場合)、そのパケットは破棄される。 Writerは受信したデータをメモリに書き込み、すべてのデータを書き込んだらControllerに通知する。 Controllerは受信完了したことをCPUに通知し、ユーザレベルのLinuxドライバがその受信データを処理する。
Writerはすべてのデータを書き込むまでControllerに通知を送ることはないため、不完全なネットワークパケットをCPUに通知することはない。
ターゲットサーバのブロックデバイスコントローラ
Linuxのディストリビューションを実行するために、ブロックデバイスのコントローラを実装した。これはMemory Mapped I/O(MMIO)に接続される。 これにより、512-byte のセクタのデータ転送が可能となる。
RTLによるサイクル精度のサーバシミュレーション
MIDAS / Strober のシステムを利用して、Chiselで記述されたデザインを変換してRTLを生成しFPGAで動作させる。 FPGAでは、各インタフェースでは外部からそのサイクルのトークンが入力される。 もしトークンが入力されなければシミュレーションはトークンが到着するまで停止し、これによりサイクル精度のシミュレーションを実現している。
スケーラビリティと使用率の向上
複数のサーバブレードのモデルを1つのFPGAに挿入することで、FPGAの使用率を向上させる。 これにより、最大で1024コアを動作させるクラスタが構成できる。
B. ネットワークシミュレーション
1. ターゲットスイッチのモデリング
ネットワークスイッチはソフトウェアにてシミュレーションを行う。
2. ハイパフォーマンス・トークン転送
トークンの転送はソフトウェアで行われるが、サイクル数をを正確にシミュレーションするために、パケットを通過させるレイテンシを計算してソフトウェアでシミュレーションを行う。 トークンが通過するサイクル数を算出すると、それに合わせてハードウェアの動作が調整される。
200Gbit/sのリンクをシミュレーションするためには、シミュレーションするプロセッサの3.2GHzとしてシミュレーションが行われる。
まず、ホストCPUとFPGAのデータ転送にはPCIeを使用する。 次に、トークンの束を転送するためAmazon Elastic DMA(EDMA)を使用する。 ToRスイッチには、共有メモリポートを使用し、異なるノード間の転送にはTCPを使用する。
NIC転送におけるサイクル計算の考え方。
3. EC2 F1インスタンスへのデプロイとマッピング
FireSimの構成をFPGAにデプロイするために、手動で構成していると時間がかかって無駄である。 FireSimは実現したい構成をPythonで記述すると、自動的にシステムを構成してFPGAでデプロイを行う。
Pythonで記述されたブレードサーバの構成を図4. に示す。 必要な構成に応じて、スイッチングのためのサーバには自動的にMACとIPアドレスが割り当てられ、MACのスイッチングテーブルはシミュレーション用に自動的に構成される。
4. 環境と性能測定
FireSimのシミュレーション環境の検証と性能測定を行う。
A. ネットワークレイテンシベンチマーク
8ノードクラスタでLinuxをブートし、100のpingを実行して結果を測定した。 リンクのレイテンシを調整していき、レイテンシが予測通り変化することを確認した。
B. ネットワークバンド幅測定
次に、ネットワークのバンド幅を測定するために、2つのノード間でパケットを転送しバンド幅を測定した。 結果は1.4Gbps/s となり、ネットワーク帯域の200Gbit/sを大幅に下回ったが、これはターゲットプロセッサのRocket CPUの性能ボトルネックになっているものと思われる。
C. ベアメタルのネットワークバンド幅テスト
一方で、Linuxを使用しないベアメタルのネットワークバンド幅テストのソフトウェアを開発し動作させた。 このテストでは100Gbit/sを計測し、私たちのネットワークバンド幅テストが低速な理由が、Linuxのソフトウェアスタックであることが確認できた。
D. ネットワークバンド幅の飽和を確認する
単一ノードでのネットワーク転送では最大帯域まで到達することは出来なかったが、複数のノードを接続することでネットワーク帯域が飽和するかを確認した。 これにより、例えば100Gbit/sの帯域制限を持たせたネットワークテストでは、2つのノードが転送を始めるとネットワーク帯域が200Gbit/sとなりバンド幅が飽和することを確認した。
E. FireSimクラスタでmemcachedのQoS現象を再現する
(※ 省略)
5. シミュレーションパフォーマンス
A. ノード数と性能の関係
ノード数を増やしていき、シミュレーション性能を測定した。 200Gbit/s のネットワークで、2usのレイテンシの構成を使い、Linuxのユーザスペース上でベンチマークプログラムを実行した。 結果は、ノードの数を増やすとシミュレーション速度の低下がみられる。 ネットワークのシミュレーション性能がボトルネックになっており、特にSuperNodeの状態では複数のコア同期をとる必要があるため性能が落ちやすい。 図8. では、ベンチマークプログラムを実行した際のシミュレーション性能(シミュレーション性能MHz)を示している。
B. ネットワークのレイテンシと性能の関係
ネットワークのレイテンシを短くすると、シミュレーション性能が低下することが確認できた。 つまり、ネットワークのレイテンシは性能における重要なボトルネックになっていることが確認できた。
C. 数千ノードのデータセンタシミュレーション
FireSimのスケーラビリティをデモンストレーションするため、1024×2.2GHzの4コアノードでのシミュレーションを行った。 これには、32個のTop-of-Rackスイッチと4つの中間スイッチ、1つのトップスイッチを使用する。 ネットワーク帯域は200Gbit/sでレイテンシは2usの構成を使用した。 この状態でシミュレーション速度は3.42MHzであった。
このシミュレーション環境を、32個のf1.16xlarge
インスタンスにマッピングして実行した。
これにはホストのToRスイッチと、サーバブレードのシミュレーション環境が含まれている。
5つのm4.16xlarge
インスタンスを立ち上げ、ルートスイッチモデルと中間スイッチをシミュレーションした。
これにより、全体でかかったコストは1時間のシミュレーションあたりおよそ~\$100であった。
オンデマンドインスタンス、固定されたインスタンスの料金を含めて、1時間当たりのシミュレーションにかかる料金は~\$440であった。
EC2のFPGAを購入して使用するとなると、1FPGAあたり\$50Kとして、\$12.8M 必要となるところである。