アプリケーション実行性能

100 1000

1 2 4 8 16

Mop/s

Number of CPUs 50

Class S PM/RHiNET Class W PM/RHiNET Class A PM/RHiNET Class S PM/RHiNET-VP Class W PM/RHiNET-VP Class A PM/RHiNET-VP

図8.12 CG^{の実行結果}

1 10 100

1 2 4 8 16

Mop/s

Number of CPUs Class S PM/RHiNET

Class W PM/RHiNET Class A PM/RHiNET Class S PM/RHiNET-VP Class W PM/RHiNET-VP Class A PM/RHiNET-VP

図8.13 EP^{の実行結果}

100 1000

1 2 4 8 16

Mop/s

Number of CPUs Class S PM/RHiNET

Class W PM/RHiNET Class A PM/RHiNET Class S PM/RHiNET-VP Class W PM/RHiNET-VP Class A PM/RHiNET-VP

図8.14 FT^{の実行結果}

10 100

1 2 4 8 16

Mop/s

Number of CPUs 5

Class S PM/RHiNET Class W PM/RHiNET Class A PM/RHiNET Class S PM/RHiNET-VP Class W PM/RHiNET-VP Class A PM/RHiNET-VP

図8.15 IS^{の実行結果}

100 1000

1 2 4 8 16

Mop/s

Number of CPUs Class S PM/RHiNET

Class W PM/RHiNET Class A PM/RHiNET Class S PM/RHiNET-VP Class W PM/RHiNET-VP Class A PM/RHiNET-VP

図8.16 LU^{の実行結果}

100 1000

1 2 4 8 16

Mop/s

Number of CPUs 50

Class S PM/RHiNET Class W PM/RHiNET Class A PM/RHiNET Class S PM/RHiNET-VP Class W PM/RHiNET-VP Class A PM/RHiNET-VP

図8.17 MG^{の実行結果}

100 1000

1 4 9 16

Mop/s

Number of CPUs 50

Class S PM/RHiNET Class W PM/RHiNET Class A PM/RHiNET Class S PM/RHiNET-VP Class W PM/RHiNET-VP Class A PM/RHiNET-VP

図8.18 SP^{の実行結果}

た場合とPM/RHiNET-VPを用いた場合とで比較すると，PM/RHiNET-VP^の方がPM/RHiNET^を 上回る性能を示しており，ノード数が増えるにつれ差が広がる傾向にある．中でもIS^{は，ノード} 数が少ない場合でも差が顕著である．MPIレベルのベンチマーク結果でも示したように，サイズ の大きなデータ転送ではPM/RHiNET-VPの方がPM/RHiNETよりも高いスループットを示して いる．ISでは他のベンチマークに比べてサイズの大きなデータをまとめて転送することが多いた

め，PM/RHiNETよりも高いスループットを提供可能なPM/RHiNET-VPの方が高い性能を実現で

きていることがわかる．ただし，PM/RHiNETは安定動作のためにスループットを抑制する制限 が課されているため，ここでのClass W^やClass Aのアプリケーションのベンチマーク結果を元 に，PM/RHiNET^とPM/RHiNET-VPの設計上の優劣を比較することはできない．

8.7 Martini におけるメッセージ通信の実装に関する考察

8.7.1 メッセージ通信の性能改善案

これまでに示した評価の結果より，PM/RHiNET-VPはシステムの規模に関係なくレイテンシは 一定だが値が大きく，一方でPM/RHiNETはシステムが小規模なうちは，レイテンシは非常に小 さいが，大規模化するにつれノード数に比例してレイテンシは増大していくことが予想される．

PM/RHiNETのノード数増加時のレイテンシ増加の問題は，5.5.1節で述べたSEND/RECVプリ ミティブにおけるディスクリプタテーブルのようなバッファを受信バッファと別に用意すること で，メッセージ受信確認のためのアクセス範囲を集中させることができるため，ある程度緩和す

ることができると考えられる．しかしながら，この手法では，先に述べたようなレイテンシの増 大やパケット数の増加によるネットワークの混雑という問題を伴う他，メッセージ到着の検出に ノード数分のメモリアクセスが必要となる問題や，ノード数分の受信領域を確保しなければなら ないというPM/RHiNETの問題については解決しない．

この問題を根本的に解決するには，Martiniのハードウェア機能を強化し，PM/RHiNET-VP^に

おけるVPUSHの性能を向上させればよい．VPUSHの性能向上には，オンチッププロセッサの処

理能力を向上させる方法と，VPUSHそのものをハードウェア実装する方法が考えられる．

VPUSHの受信処理のうち，ハードウェアが待機状態でオンチッププロセッサのソフトウェア

のみが処理を行っている時間は約7.4µsecであることがRTLシミュレーションより求まっている．

これより，オンチッププロセッサの処理能力を向上させ，仮にVPUSHにおけるソフトウェア処 理時間が半減できたとすると，PM/RHiNET-VP^のRTT^を7.4µsec小さくできることになる．ただ し，この場合でもRTT^は18.1µsec^{程度であり，}PM/RHiNET^{を用いた場合の}2^{ノード時の}RTT^と 比べると倍近く大きい．

一方，VPUSHそのものをハードウェア実装するには，受信バッファの空きを判定する処理と，受

信のためのDMA要求発行後に受信先のアドレスを更新しつつホストに対して受信通知を行う機構 をpushパケットの受信処理に追加する必要がある．RHiNETプロジェクトで派生したDIMMnet-1 の後継プロジェクトであるDIMMnet-2[128][129]^では，VPUSH^{に似た，より高機能な}IPUSH[130]

と呼ばれる機構がハードウェア実装されている．IPUSH^も通常のRDMA^{の受信処理を拡張して} 実現されているが，処理時間の増大は受信領域の空き容量の判定部分で4^{サイクルだけで済んで}

いる．Martiniでも同様に数サイクルの遅延増加で実装可能であると考えられる．

また，受信通知に要する遅延時間は，受信側でpushパケットのデータ受信のためのDMA要求 が発行されてから実際にホストメモリに書き込まれ，それがCPUから検出されるまでの時間と ほぼ等しいものと考えられる．この時間は，実機評価およびRTLシミュレーションより，評価で 用いた環境では約1.0µsecとなることがわかっている．この時間はパケットの受信処理時間の増 加分に比べて十分に大きい．よって，VPUSHをハードウェア化することで，受信処理時間は通 常のpushパケットの受信処理時間に比べて多く見積っても約1.0µsecの増加で済むと考えられ，

PM/RHiNET-VPのレイテンシは2ノードでのPM/RHiNETのレイテンシに対して約1.0µsec増とな る．PM/RHiNET-VPのRTTが16ノードの場合のPM/RHiNETのRTTとほぼ等しくなることから，

VPUSHをハードウェア実装した場合，16ノードより大きな規模であれば性能面でPM/RHiNET

を上回ると考えられる．

また，VPUSHをハードウェア実装する場合のハードウェア量については，受信バッファのア

ドレスやサイズ，受信通知用の領域のアドレスなどを保持するレジスタが数ワード分新たに必要 となるが，メッセージ本体の受信処理や受信通知の処理は既存のpushパケットの受信処理機構 をほぼそのまま利用できるため，増加はわずかであると予想される．MartiniにおいてVPUSHが ハードウェア実装されていた場合，メッセージ通信のレイテンシは16^{ノード時の}PM/RHiNET^の レイテンシと同程度となると見積られることから，NAS^{並列ベンチマークの}Class S^の結果は16 ノードでほぼ同等，2^{ノードから}8^{ノードまでは図}8.11^から図8.18^に示したPM/RHiNET^を用い た場合の結果をやや下回る結果となると予想される．また，VPUSHをハードウェア実装するこ

とでPM/RHiNET-VPにおいても乗っ取り機構による実装上の制約がなくなるため，PULLが利用

できるようになり，PMでRMA機構を提供することが可能となる．そのためメッセージサイズが 16Kbyte以上の際のスループットはRMA^{を使用することで図}8.9^で示したZerocopy^{と同様の値} を得ることができる．NAS並列ベンチマークにおいても，問題サイズの大きなClass A^を中心に

現状のPM/RHiNET-VPを用いた結果よりもさらに高い性能を得られると予想される．

8.7.2 メッセージ通信の実装より明らかになったMartiniの課題

RHiNET-2では，ネットワークインタフェースに対してPUSH^とPULL^という2^{つの単純な}

RDMA通信機構のみをハードウェア実装し，これを上位レイヤから利用することで複雑な通信処 理においても高い性能を実現できるものと考えMartiniが開発された．Martiniを搭載したネット ワークインタフェースは，RHiNET-2/SWを介した2ノード間の通信による評価では，他のSAN のネットワークインタフェースと同程度の高性能な基本通信性能を示した[131]^{が，実際にシス} テムを構築して並列分散処理環境を実装してみると，ネットワークインタフェースの提供する機 能が不十分なために大規模化した際に通信性能が悪化してしまうことが判明した．このような事 態を防ぐために，並列分散処理向けのネットワークインタフェースにおいては，複雑な通信処理 は上位レイヤを組み合せて実現する場合であっても，単純なRDMAだけでなく，VPUSHのよう な単純ながらもメッセージ通信の効率的な実装を支援する通信機能を十分検討しハードウェア実 装すべきである．