このページの本文へ

ロードマップでわかる!当世プロセッサー事情 第317回

スーパーコンピューターの系譜 今後のGPGPU利用の方向性

2015年08月17日 12時00分更新

文● 大原雄介(http://www.yusuke-ohara.com/) 編集●北村/ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

メモリー帯域が不足

 2つ目の問題は、高まる性能にメモリー帯域が追いついてきていないことであるが、幸いにもこれはHBMあるいはMHCといった3次元メモリーが実用化されたことで短期的には解決しつつある。

AMDのHBM(High Bandwidth Memory)

 AMDはRadeon R9 Fury/Fury XでHBM(HBM 1)を採用し、HBMスタック1つあたり128GB/秒、4スタックで512GB/秒という従来実現が難しかった広帯域を実用化に持ち込んだ。これに続きSK Hynixは転送をDDR化するHBM 2を予定しており、こちらはAMDの将来製品とNVIDIAのPascalの世代で採用されることになる。

 HBM 2ではスタック1つあたり256GB/秒の帯域なので、4スタックでは1TB/秒に達するわけで、GDDR5頼みだった従来から大幅に改善が見込まれる。また容量的にもHBM 1はスタックあたり1GBだったのがHBM 2では4GBになる予定で、4スタックでは16GBになるため、こちらも当面は十分と言えるだろう。

 インテルは前回説明した通り、Knights Landingの世代ですでにMCDRAMを採用しており、続くKnights HillでもやはりMCDRAMが利用されると見られているため、これも問題ではない。

ホストとの連携が遅い

 3つ目の問題はI/F、あるいはホストとの連携である。前回のKnights Landingのところでも少し説明したが、現在のGPGPUの大きな問題は、ホストとの連携が遅いことだ。

 これは元がGPUを利用している関係で、PCI Expressを利用して接続する形になるわけだが、PCI ExpressはもともとI/Oバス用ということでキャッシュコヒーレンシの機能は搭載されていない。

 このため、例えばGPUが直接ホスト側のメモリーにアクセスしてデータを取得、演算後に結果をメモリーに書き込むと、CPU側のキャッシュの一貫性が崩れることになる。

 したがって、必ずホストからGPUに対して演算命令を発行し、演算が終わったらホストがその結果を取り込むという処理をしないといけない。これはもう原理的にどうしようもない話である。

 加えて、最新のPCI Express Gen 3.1であっても帯域そのものはx16で16GB/秒に過ぎない。これは、先に出てきたRadeon Fury/Fury Xのメモリー帯域の32分の1に過ぎない。

 現在PCI Expressの仕様制定を行なっているPCI-SIGは帯域を2倍、つまりx16構成で32GB/秒にするGen 4の仕様策定作業中だが、現在の進捗から考えると仕様が定まるのは2017年にもつれ込みそうな勢いだ。

 仮にこれが制定されても、32分の1が16分の1になるだけで、根本的に帯域が足りていない状況は解決しそうにない。

 実はこうした、ホストとGPGPUの連携を高速化するためのオプションがPCI Express Gen 2.1で追加されているのだが、このオプションをPCI-SIGにねじ込んだ張本人であるインテル自身がそれを使ってない。

 というのは、多少オプションで高速化されても絶対的な性能が足りないので、サポートする労力に見合わないと判断したようだ。

 その代わりにXeon Phiでは、PCI Expressの動作周波数をオーバークロックして転送を若干高速化するという無茶なオプションが用意されたが、所詮焼け石に水である。

 この問題に対する解は三社三様である。インテルのKnights Landingでは、それぞれのコア上でOSが動くようになっており、そもそもホストと連携する必要を省く、という形で対応した。

ホストなしで直接Knights Landingがノードになれる、というわけだ。インテルが2014年9月にKnights Landingを発表した時の資料より抜粋

 前回、Knights Cornerとの大きな違いは「単体でOSが動作すること」と説明したが、もっと厳密に説明すれば「ホストOSが要らないこと」である。

 実はKnights Cornerそのものは各コア毎にLinuxが動作しているが、問題はこのコアはI/Oアクセスが一切できないことで、このためMPI(Message-Passing Interface)と呼ばれるHPCでよく使われるI/Fを経由してホスト側にI/Oを行なわせるという無駄な処理が必要だった。

 ところがKnights Landingではこうした処理が要らないので、各コアが独自に処理できるわけだ。もっとも、そうは言ってもある程度大規模な計算だと、複数コアどころか複数マシンで処理を分散させたりする必要があるため、I/Fは高速なほうが望ましい。

 これに向けてKnights Landingには同社が開発したOmni-Pathと呼ばれる100Gbps/リンクのネットワークチップを搭載したモデルも用意されており、これで高速接続を可能にするという目論見だ。ちなみに現時点ではKnights LandingのOmni-Pathが何リンク構成なのかは公開されていない)。

→次のページヘ続く (NVIDIAとAMDの解決策

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

最新記事

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン