CPUは100コア時代に向けて猛進している。IntelやAMDなど大手CPUメーカーの技術リーダーを始め、多くのCPU業界関係者がそう語っている。すでにCPUメーカーにとっては、100コアは規定の路線のようだ。AMDが提唱している、CPUに多数の小型コアやシステム機能を統合するシステムレベル統合時代のCPUも、方向としては100コアを目指している。この場合の100個のコアには、伝統的なCPUコア以外の、もっと小型の演算コアがカウントされる。2011年の新CPU「Bulldozer(ブルドーザ)」が、この方向へのスタート地点となる。

システムレベルインテグレーションCPU

　しかし、100コアCPUには、まだ大きな壁がいくつも立ちふさがっている。なかでも、アーキテクチャ面で重要になるのは、「アムダールの法則」の壁だ。アムダール氏が予見したのは、プロセッサが実行するタスクの中で、並列(パラレル)化できない部分、すなわち逐次(シリアル)実行するしかない部分が、タスク全体の実行時間を制約してしまうことだった。

　タスクのうち並列化できる部分を並列ハードウェアで実行して時間を短縮しても、逐次実行しなければならない部分の実行時間はシングルスレッド性能に依存する。そのため、逐次実行しなければならないコード部分の比率が高ければ、そこで実行時間がかかってしまい、ハードウェアの並列度を高めても全体の実行時間は短くならない。

　アムダールの法則自体はよく知られているが、それがどれだけ大きな制約であるかは、意外と実感されていない。下のアムダールの法則のスライドは、AMDのCPUアーキテクトであるChuck Moore(チャック・ムーア)氏(AMD Senior Fellow)が、昨年(2008年)11月に開催されたCPUアーキテクチャのカンファレンス「Micro41」で行なったスピーチのプレゼンテーションのものだ。8コアまでの範囲での、アムダールの法則による理論上の高速化の違いを示している。Moore氏は、この一連のスライドで、AMDの2010年代のCPUの方向性を浮き彫りにしているが、そこで重要なポイントとして扱われているのがアムダールの法則だ。

アムダールの法則

IntelとAMD CPUの比較

　上のチャートでは、左から右へ行くに従ってCPUコア数が増えている。各ラインは、CPUが実行するタスク群の中に、どれだけの量の並列化できないシリアルコード部分が含まれているかを示している。シリアル部分の多いワークロードは、CPUコア数が増えても性能向上が少ない。

　グリーンのラインはシリアルコンポーネント部分が全くない理想的な並列化のケースで、これなら、CPUコア数の増加に応じて(メモリなどが理想的なら)パフォーマンスもリニアに伸びる。8コアなら8倍のスピードアップとなる。

　ところがイエローのラインのように、全体の10%でもシリアルコンポーネントがあると、効率はがくっと落ちて、8コアで理論値4.7倍の性能向上になってしまう。つまり、理論上でも、約60%の性能アップ効果しか得られないことになる。しかし、これはマシな方で、CPUコア数が増えるに従ってアムダールの法則の制約は、どんどんきつくなる。

　下のスライドは上のスライドをズームアウトして128コアまでの、メニイコア時代を見据えたグラフとなっている。これを見ると、10%でもシリアルコンポーネントがあると、128コアでも理論上の性能向上はたった9.3倍しか達成できないことがわかる。理論値では最高128倍のはずが9.3倍なので、ピーク値の7.3%のパフォーマンスに過ぎなくなってしまう。

アムダールの法則の延長

　これだけでも、アムダールの法則の制約が厳しいことがわかるが、もっとズームすると、さらにクリティカルであることがわかって来る。シリアルコンポーネント部分が10%以下のケースも計算すると、次の図のようになる。上のチャートがアムダールの法則でのパフォーマンスアップ、下のチャートがアムダールの法則でのパフォーマンス効率を示している。どちらも128コアまでで、グリーンの線は100%完全に並列コードで構成されていて、シリアル部分がない理想的なパターンを示している。つまり、できるだけグリーンに近い線が、いちばんいいことになる。

　チャートを見ればわかる通り、シリアルコンポーネントが5%の場合でも、理論値で17.4倍のパフォーマンスアップにしかならない。パフォーマンス効率は13.6%となる。シリアルコンポーネントが1%でようやく56.4倍、44.1%のパフォーマンスを達成できる。つまり、99%のコードを並列化できて、ようやく理論上のピーク値の半分以下の性能に達するレベルだ。シリアル部分が0.25%にまで下がっても、まだ80%のパフォーマンス効率を得られない。

アムダールの法則による性能アップと効率性

　こうしてみると100コア時代には、アムダールの法則がクリティカルになることがよくわかる。並列化できるコード部分が、コンピューティング時間を圧倒的な部分を占めるのでなければ、CPUコアを増やす意味が薄くなってしまう。

　アムダールの法則がそんなにきついなら、無理矢理並列化を推し進めなくてもいいのでは、と思うかもしれない。しかし、そうは行かない状況がある。それは、シリアルコンポーネントの高速化が、どうにもならないからだ。

　シリアルコンポーネントを速くするには、CPUのシングルスレッド性能を上げなくてはならない。しかし、それはさまざまな壁に阻まれている。引くに引けないのが現状のCPUだ。

　まず、根本である『ムーアの法則』自体が壁に近づいており、同法則の指数関数的な成長におんぶにだっこでは進めなくなりつつある。その一方で、消費電力の壁は厳然として存在し、ますます厳しくなりつつある。それどころか、TDP(Thermal Design Power:熱設計消費電力)や平均消費電力の引き下げについての要求は、強くなる一方だ。

　そして、CPUの動作周波数も、今は上げにくくなっている。高速化のためにパイプラインを深くすると、一般にラッチオーバーヘッドが増える。また、パイプラインの深化は、インフライトで保持しなければならない命令数を増やす。これらは、いずれもトランジスタ数の増大を招いて、消費電力を押し上げる。

　CPUのシングルスレッド性能は、周波数×サイクル当たりの命令実行数×命令ステップ数で決まる。それなら、より多くの命令を並列で処理することでサイクル当たりの命令実行性能「Instruction-per-Clock(IPC)」を高めればいい。しかし、今では、ハードウェアを複雑にしても、IPCは少ししか向上しない。IPCの壁に当たってしまっている。

　局所性を利用してパフォーマンスを引き上げるのはどうか。これも、飽和点に達していて、キャッシュメモリの量を増やして行っても、少ししかパフォーマンスが上がらない。こうした状況で、シングルスレッドパフォーマンスが今後どうなるのか、かなり疑問符が灯っている。

　そうなると、残る手段は、命令レベル以外の部分の並列性で性能を上げることしかない。つまり、スレッドまたはタスクを並列にするか、データを並列にするか。しかし、その場合もアムダールの法則が立ちふさがる。そして、アムダールの法則の制約を超えて性能を出せるのは、タスク群のほとんどが並列化可能な例に限られるというわけだ。そして、タスク間の同期やコミュニケート、あるいはデータムーブメントのオーバーヘッドも少なくなければならない。

シングルスレッドのパフォーマンス

高性能化の手段

　では、どういうコンピューティングのスタイルが、その例に当てはまるのか。それは、ラージスケールの「スループットコンピューティング(Throughput Computing)」だ。スループットコンピューティングでは、依存性のないタスクを大量に走らせるため、並列ハードウェアで容易に並列化ができる。逆を言えば、スループットコンピューティングでなければ、100コアといった大量の並列ハードウェアを活かすことが難しい。

　Intelも、以前、AMDの説明と似たようなアムダールの法則の制約を説明している。その時、Intelは将来のアプリケーションでは並列化できる部分が非常に多くなるため、アムダールの法則の制約が軽くなるだろう、と結論づけていた。将来アプリケーションとは、“RMS”と呼ばれる「Recognition(認識)」「Mining(分析&抽出)」「Synthesis(合成)」といったジャンルのアプリケーションだ。これは、必然的に、100コアCPUのパフォーマンスを活かすことができるアプリケーションも決まってくることを意味している。

　ただし、スループットコンピューティングに向けたハードウェアになって行くとしても、依然としてシングルスレッド性能は重要となる。それは、アムダールの法則が生きているためで、シリアルコンポーネントは必ず残るからだ。特に、OSはコードのほとんどは基本的にシリアルコンポーネントであるため、OSのスケーラビリティがどこかの時点でボトルネックになる、とAMDのスライドでは指摘されている。

　これは、逆の見方をすれば、シリアルコンポーネントであるOSから、並列化可能なタスクが、他のプロセッサコア群にオフロードされると考えることもできる。また、アプリケーション自体で、スループットコンピューティング化を行なうこともできると言う。下のスライドでは、HPC(High Performance Computing)アプリケーションの中にはデータ並列をタスクレベルのスループットコンピューティングに変換できることが挙げられている。また、将来は、ランタイム環境がそうしたスケジューリングをハンドルできる可能性があるとも指摘されている。このランタイムでの、スループットコンピューティングのスケジューリングは、Intelも似たようなことを言っている。ここでも、IntelとAMDの目指している方向が、根底では一致していることがわかる。

　それでは、実際のスループットコンピューティングの実装はどういったスタイルになって行くのか。AMDのMoore氏のMicro41のスライドは、スループットコンピューティングの考察から、2010年代の同社のCPUの姿を垣間見せている。

　Moore氏のスライドは、まず、現行のラージスケールスループットシステムとして2つの例を挙げている。それは、WebエッジサーバーとプログラマブルGPUだ。Webエッジサーバーの場合はタスクレベルのスループットコンピューティング、GPUの場合はほぼデータレベルのスループットコンピューティングになる。

スループットコンピューティング

　どちらも共通しているのは、ハードウェアのスレッドスロット以上に多くのスレッドを実行する点。中央のコントローラがスレッドのスケジューリングを担当する点。つまり、ヘテロジニアス(Heterogeneous:異種混合)型のシステムで制御している。

　こうしたシステムから見えてくるスループットコンピューティングの姿があるという。

　まず、スループットコンピューティングでは、並列化できるリソースはいくらでもある。そのため、従来のCPUのように並列化がボトルネックにはならない。ボトルネックになるのはプロセッサとメモリのデータ転送だ。そのため、スループットコンピューティングのゴールは、メモリへのパイプラインを飽和させることにあるという。メモリのレイテンシはスレッドによって隠蔽できるため、メモリ帯域をいかに効率的に使い切るかが重要となる。

　また、マイクロアーキテクチャでは、膨大な数のスレッド(アクティブだけでなくスタンバイも含めて)をサポートする必要がある。あるスレッドでメモリストールが起きた場合に、すぐに他のスレッドに切り替えてメモリパイプラインを埋めるようにしなければならないからだ。メモリコントローラ側も、膨大な数のリクエストを保持できるようになっていなければならない。

　ソフトウェアサイドでは、自然な並列性を、膨大な数の独立したスレッドに分割する必要がある。スレッドを、ハードウェアに合わせて、データ並列ワークロードとタスク並列ワークロードに適用して行く。これには、CUDAやOpenCLのような言語モデルとランタイムでのサポートが必要になると思われる。

スループットコンピューティングの特性

　ここで、おそらくポイントになると思われるのは、データ並列とタスク並列のどちらへと技術が流れて行くのかという点だ。AMDは、データ並列とタスク並列のどちらを選ぶかを明言していない。この件は、スーパーコンピュータで大きな論争となった、SIMD(Single Instruction, Multiple Data)対MIMD(Multiple Instruction, Multiple Data)の論争とも関連している。今は、データ並列とタスク並列の流れの中で、バランスを取る地点を模索しているように見える。

ベクタプロセッシング

SIMDとMIMD

スーパーコンピュータの歴史