メディア

SoCでもマルチコア化は進むのか?(1/2 ページ)

サーバー機器向けのプロセッサは、1つのチップに複数のプロセッサコアを搭載する方向に進化している。この流れはしばらく継続することになりそうだ。では、これと同じ流れが、組み込み機器向けのSoCにも適用されるのだろうか。本稿では、SoCの進化の方向性について考察する。

» 2009年02月01日 00時00分 公開
[Ron WilsonEDN]

方向性の大きな変化

 SoC(System on Chip)は、従来、ボードレベルで構成していたコンピュータシステムを1つのチップで実現するようになってから、明確な一筋の道に沿って進化を遂げてきた。まずメモリーが加えられ、次に特定の処理を高速/低消費電力で実行するためのアプリケーションアクセラレータが集積された。そして、ブロック間のデータフローをサポートするための複雑な配線構造やDRAMコントローラが導入された。つまり、周辺機能を順次取り込むことで進化を続けてきたのである。

 一方、サーバー機器向けのプロセッサは、一貫して処理能力の向上を目指して高速化が図られてきた。だが、最近になって、米Intel社がプロセッサの進化の方向性を転換したことを明らかにした。この転換は、CPUの高速化による処理性能の向上が、100nm以下のプロセスにおいて物理的な壁に直面したことで生じたものである。1つのチップにCPUを複数個搭載することにより、処理性能を向上させるというのが新たな方向性だ。この新しい考え方により、Intel社はクロック周波数の向上に努めることをやめ、それによって、増大するエネルギーコストに悩むという状況から解放された。この転換は、処理するジョブがそれぞれ独立したスレッドの集合であることが多いサーバー用途の要求にも適合する、理にかなったものであった。

 今日、ハードリアルタイム処理を要求されることが多くなった組み込み機器向けSoCもマルチコアに移行するのだろうか。そうはならないと考える向きもあるが、90nmから65nm、45nm、それ以降へとプロセスの微細化が進むに連れ、SoCもサーバー機器向けプロセッサと同様にマルチコア化が進むと予測するSoC設計者が多い。

 現在の典型的なアーキテクチャでは、複雑なバス構造の中心に1個のプロセッサが存在し、多種多様な専用エンジンや周辺機能を制御するようになっている。これがマルチコアになると、従来の中央集権的な構造が、ほぼ同一のCPUコアが複数並ぶマルチコア構造に変化し、それぞれのコアで制御処理を分担することになると考えられる。その際、制御の分担は分散カーネルが行い、その時点の要求や消費電力の制約に基づいて、タスクを各コアへと動的に振り分けることになる。

 この予測は、革新的な発想に基づいてはいるが、非現実的なものであるように感じられるかもしれない。しかし、SoCがこの方向に向かっていることを示す要因や実例がすでにいくつも存在している。以下では、それらを紹介していく。

マルチコア化を促す要因

 なぜ上述したような革新的な変更が求められているのだろうか。その要因は2つある。1つは消費電力の増加、もう1つはスケーラビリティである。

 特に、マルチコア化による消費電力の削減は魅力的な要素だ。あるタスクを複数のプロセッサコアに分散して処理することで、1つのコアで処理するよりも動作周波数を低くでき、各コアの電源電圧を下げることができる。ダイナミック消費電力は、電源電圧の2乗に比例するので、電源電圧を低下させることによる消費電力の削減効果は大きい。また、電源電圧を下げればリーク電流などによるスタティック電力も低減できることとなる。

 マルチコア化に当たってソフトウエアを活用すれば、電力削減の効果をさらに高められる。この点について、英ARM社で製品マネジャを務めるIan Rickards氏は以下のように語る。

 「ARMアーキテクチャでは、『wait for interrupt』命令を使うことでCPUのクロックをゲーティングできる。この機能により、実際に何らかの処理を行っているコアだけを動作させて、電力の消費を最小限に抑えられる。また、Linuxでは、未使用のコアをOSが認識して、コアごとの電源を完全に停止することが可能だ。この概念を拡張したものが、動的電圧周波数スケーリング(DVFS:Dynamic Voltage Frequency Scaling)である。これは、OSが各コアをその時点のタスク処理に必要な最小限の電源電圧と周波数で動作できるように制御するものだ。ただし、マルチコア構成でこの機能が用いられているのを実際に見たことはない」。

 さらに、Rickards氏は、「周波数を下げることにより、電力に関するほかの利点も得られる」と指摘する。例えば、コアの最大周波数を下げられれば、標準の製造プロセスに代わって消費電力の少ないローパワープロセスを採用することができる。また、高性能な1配線/2トラックのライブラリの代わりに、10配線トラックのライブラリを使用したりすることも可能かもしれない。これらすべてを合わせれば、大きな電力削減につながる。

 ただし、マルチコア化においては注意しなければならないことがある。それは、汎用プロセッサを利用するプログラムアーキテクチャのエネルギー効率がハードワイヤードのエンジンと比べて本質的に低いことである。米AMCC(Applied Micro Circuits Corporation)社でマイクロプロセッサ部門最高技術責任者を務めるDan Bouvier氏は、「特にセキュリティに関する演算や正規表現マッチングなど、ハーバードアーキテクチャには不向きなタスクの場合、アクセラレータのほうが絶対に消費電力が少ない」と述べる。ハードワイヤードとプログラムアーキテクチャを比較すると、プログラムアーキテクチャでは命令をフェッチしてデコードしなければならないという単純な違いがあり、エネルギーの消費量が確実に増えることになる。また、専用ハードウエアであれば1サイクルで処理可能なことでも、汎用プロセッサでは多くの命令を費やさなければならない場合が多い。高度な電力管理とカスタム命令に対応したハードウエアを使えばこの差は縮められるが、完全になくすことはできない。

 また、SoC上のプロセッサコアの数が増えるに連れ、2つ目の要因であるスケーラビリティが重要になってくる。「アーキテクチャが統一されていれば、プロセッサ数の増加に応じたプログラムの作成が容易であり、スケーラビリティが高いと言える。一方、特殊なアクセラレータを使用する場合には、プログラミングモデルに統一性がないためスケーリングは困難だ」とBouvier氏は指摘する。

 米Open-Silicon社の技術担当シニアディレクタであるVamsi Boppana氏は、ハードウエア設計者の立場から同様の見解を示した。「すでに限界点に達していると強く感じている。最近では、1つのチップに数百ものプロセッサ/アクセラレータが集積されることがある。その数が数千に達する日も遠くないはずだ。それほど数が多く、さらに複雑なヘテロジニアスなアーキテクチャのマルチコアに対し、静的なタスク割り当てを行って管理するのは困難であろう。多数のコアを搭載するならばSMP(Symmetric Multiprocessing)を採用しなければならない」とBoppana氏は述べる。

アーキテクチャ

 上述したように、将来のSoCは、統一が図られた汎用プロセッサが並んだSMPになると予想される。では、これまでシングルコアやASMP(Asymmetric Multiprocessing)のSoCを中心に設計してきた技術者は、SMPのSoC設計にどのように取り組めばよいのだろうか。このことについて考えるには、アプリケーションレベルに踏み込む必要がある。米Tensilica社のCTO(最高技術責任者)であるChris Rowen氏は、以下のよう述べる。

 「アプリケーションに存在する並列性に注目するところから始め、解決しようとする問題の性質に着目する。まず、SoC上の異なる機能サブシステムの間に多くの並列性が存在する場合が多い。例えば、IP(Internet Protocol)セットトップボックスのプロトコルスタックとビデオ処理の層は互いにかなり独立して動作することができる。そのような潜在的な並列性がデータプレーンに数多く存在する。機能が別々のチップに分けられていた時代から、そのように作られてきたからだ。この構造に着目すれば、アプリケーションを複数のプロセッサコアによって分散処理することができる。困難なのは、簡単な部分を分散させた後に残る、パイプライン化されていない単一のタスクの分割だ」。

 さらにRowen氏は、「複雑さが増すと、プロセッサコアが動作するインフラストラクチャを構築することが重要になってくる。タスクを個々のスレッドに分割すると、タスク間に2種類の関係があることに気付く」と述べる。つまり、データがあるタスクから別のタスクへと定められた順序で流れるようなデータストリーム的な関係と、データの送受の順序が不定で、予測も不可能な複雑な共有データ的な関係である。このように2つの関係が存在することから、プロセッサ間に2種類の接続が必要となる。その接続とは、データストリーム向けのキューによる接続と、より複雑な場合向けの共有メモリーによる接続である。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSフィード

公式SNS

EDN 海外ネットワーク

All material on this site Copyright © ITmedia, Inc. All Rights Reserved.
This site contains articles under license from AspenCore LLC.