2008年7月16日と17日の2日間、東京都港区青山ダイヤモンドホールにおいて、『マイクロプロセッサ・フォーラム・ジャパン2008』が開催された（リード・ビジネス・インフォメーション、米In-Stat社主催）。「ホーム/モバイル・デジタル・エンターテインメント」をテーマとし、世界各国から集まったプロセッサ関連ベンダーによって、計24の講演が行われた。

　同フォーラム全体を通して、主役となったのは、やはりマルチコアプロセッサである。特に、ソフトウエア開発の生産性の向上を課題としてとらえている企業が多いとの印象が得られた。ここでは、そうした発表の中から、国内企業の発表をいくつかピックアップし、その概要を紹介する。

　東芝は2つのマルチコアプロセッサに関して講演を行った。いずれも、マルチメディア民生機器をターゲットとしたものだが、マルチコアと専用ハードウエアの使い方の点に大きな違いがある。

■Cellベースの“民生仕様版”
　1つ目のテーマは、ビデオストリーミング向けプロセッサの「SpursEngine」。スピーカを務めたのは、東芝 セミコンダクター社 先端SoC開発センター センター長の増渕美生氏である。

　SpursEngineがベースとしているのは、東芝、ソニー、米IBM社が開発した「Cell Broadband Engine（以下、Cell）」である。Cellは、汎用処理をつかさどる1つのPPE（PowerPC Processor Element）とストリーミング処理を担う複数のSPE（Synergistic Processor Element）を中心として構成される。Cellがターゲットとするアプリケーションは広範囲に及び、ハイエンド側ではハイパフォーマンスコンピューティングやグリッドコンピューティングがターゲットとなる。家庭用のオーディオ/ビデオ機器も守備範囲だが、「この分野をメインのターゲットとした場合、消費電力の観点からCellとは異なる最適なアーキテクチャが考えられる」（増渕氏）という発想から、SpursEngineが開発された。

　SpursEngineは、Cellの構成要素であるSPEを活用し、フルHD（高品位）に対応したメディアストリームのリアルタイム処理が可能なプロセッサとして構成されている（図1）。SpursEngineでは、Cellと同様、SPEがメディアストリームデータの処理を担い、これが演算性能の決め手となっている。

　SPEは、32ビット固定長、ロード/ストア型のRISC（reduced instruction set computer）命令セットアーキテクチャにのっとっている。シンプルなパイプラインで効率良く性能を出すことを狙い、ほぼすべての命令がSIMD（single instruction multiple data）対応となっている。そして、命令セットアーキテクチャからメインメモリーに直接アクセスするのではなく、個々のSPEが備える256Kバイトのローカルメモリーに命令を読み込んでから処理を行う。この部分の処理はソフトウエアで実現しており、その分の負荷は大きいと言える。しかし、キャッシュミスの発生により処理時間が多くかかるといったことがない。

　CellはSPEを8個備えるが、SpursEngineでは、低消費電力化を狙ってSPEを4個とした。また、動作周波数もCellの3.2GHzから1.5GHzまで下げた。

　チップ内部のインターコネクト（相互接続）についても、Cellと同じくEIB（Element Interconnect Bus）を採用している。SPE、EIBの部分はCellと同じ構成なので、この部分のプログラムはCellとある程度共通化できる。それ以外の共通部分についても、Cellとの共通ライブラリを用意することでフトウエア開発の簡素化を図った。

　なお、Cellでは汎用処理にPPEを用いるが、SpursEngineではこの部分はホストプロセッサで対処する。

　リアルタイムの画像処理ではコーデック（デコード/エンコード）が重要な要素となる。Cellでは、この部分はSPEを用いてソフトウエアで処理する。一方、SpursEngineでは、MPEG-2/H.264用の専用デコーダ/エンコーダを搭載した。その動作周波数は、リアルタイム処理に十分で、かつ消費電力を削減できるよう300MHz以下とした。

　メモリーインターフェースもCellと同じくXDRを採用、最大データ転送速度は12.8ギガバイト/秒とした。ホストとのインターフェースにはPCI Expressを用いる。

　ここまで述べたとおり、アーキテクチャならびにその構成要素はCellと共通の部分が多いが、実装はCellより全体的に軽くしている。また、電源管理機能により、PCI Express部のみ動作させ、それ以外の電源を遮断したり、Cellと同様、SPEの動作周波数を落としたりといったことも可能である。

■拡張性を狙ったアプローチ
　上述したように、SpursEngineではコーデック処理のために固定ハードウエアを用意している。東芝は、これと異なるアプローチのプロセッサも紹介した。それは、モバイルマルチメディアシステム向けのマルチコアプロセッサ「Venezia」である。その開発背景を、同社半導体研究開発センター 主幹の宮森高氏は次のように説明した。

　「昨今のモバイルマルチメディア機器は、実に多くのオーディオ/ビデオコーデックをサポートしなければならない。また、扱う画像のサイズも急増しており、720p、1080i、1080pといったHD映像にも対応する必要がある。従来は、それぞれの処理のための固定ハードウエアを用意し、それらをCPUでコントロールするという方式が主流だった。しかし、この方法だと、新たな要求に対応するには、一からチップを作り直さなければならなかった」。

　Veneziaは、スケーラビリティ（拡張性）を確保可能なマルチコアソリューションを提供するというコンセプトで開発された。新たに必要となるオーディオ/ビデオコーデック処理に対応するために、必要な性能に応じてスケーラブルにコア数を拡張しようという考え方だ。例えば、VGA（video graphics array）に対応した携帯電話機向けであればコアの数は1つとし、720pに対応したければ、コアの数を4つに増やすといった具合である。また、コアの数を増やす際に、既存のバイナリコードをそのまま実行できるようにすることも目標に置いた。

　Veneziaのハードウエアアーキテクチャは図2のようなものとなっている。HeadquartersとMPE（Media Processing Engines）の2種類のプロセッサを中心として構成されるが、これらは、いずれもコアとして、東芝のMeP（Media embedded Processor）を使っている。Headquartersは、全体の制御や、コーデックのビットストリーム処理などを担う。一方のMPEは、信号処理を担当する32ビットのRISCプロセッサであり、5段パイプラインを備えるシンプルな構成とした。SIMDをサポートし、MePとVLIW（very long instruction word）型のコプロセッサであるIVC2を組み合わせることで性能を引き出している。IVC2は、64ビットのSIMD命令を2系統実行できる。MePとIVC2により、3系統の命令を同時に実行できる仕組みだ。MPEは、65nmプロセスで製造した場合に面積が1.3mm²と小型である。これを多数並べる構成としている点がVeneziaの特徴だ。

　また、Veneziaでは、スクラッチパッドメモリーは使用しない。L1（1次）キャッシュを各プロセッサに用意し、L2キャッシュを全体で共有する形としている。スクラッチパッドメモリーを使わない理由は、必要な処理を実現するためにコア数を増やした際、同メモリーのサイズを変更すると、ソフトウエアの修正が必要になるからである。なお、キャッシュを用いた場合、キャッシュミスによるペナルティが問題になるが、それを減らすためにプリフェッチ機能を強化している。L1キャッシュは、命令キャッシュの自動プリフェッチと、データキャッシュのプリフェッチ命令をサポートする。L2キャッシュについては、プロセッサとL2キャッシュとの間に512ビットのバッファを配置しており、これをプリフェッチ用に使うことができる。また、L2キャッシュ自体も、メインメモリーからのプリフェッチに対応している。

　ソフトウエアアーキテクチャの特徴は、スレッドレベルの並列度を上げ、拡張性と互換性を確保するために、「V-Thread」と呼ぶ実行モデルを採用している点である。これは、Headquartersにおいてビデオのエンコードなどの処理（タスク）を複数のスレッド（V-Thread）に分割し、個々のスレッドを各MPEに振り分ける仕組みだ。例えば、720pの画像処理の場合であれば、1フレーム当たり2000～3000のスレッドに分割して複数のMPEに振り分ける。MPEの数を増やせば、それに応じて性能が向上することが期待できるという。

　なお、Veneziaでは、タスクや粒度の大きいスレッドについては、マルチコア構成とV-Threadのモデルによって並列性を高める。一方、命令/データレベルの処理はSIMD/VLIWの構成によって並列性を高める。SIMD/VLIWについては、コンパイラによって自動並列化が実現できているが、現状、タスクや粒度の大きいスレッドについては、プログラミングの際、人手で切り分けを行う必要があるという。

　評価チップ（65nmプロセス）では、MPEが1個の場合に対して、MPEを6個にすると4.1倍の性能が得られた。消費電流は、H.264の720pデータ（30フレーム/秒）を処理する場合で156mW（コア電圧は1.2V）。2009年に、VeneziaをSoC（system on chip）に組み込んだ製品を市場投入する予定だという。

　マルチコアプロセッサにおけるソフトウエア開発の生産性に注目した方策もいくつか紹介された。富士通研究所 システムLSI開発研究所 プロセッサソリューション開発部 部長の須賀敦浩氏による講演はその1つである。

　須賀氏がキーワードとして挙げたのは、「資産の継承性とシステムの革新性」である。すなわち、高機能化/多機能化が進む組み込み機器において、シングルプロセッサ時代の資産を可能な限り利用しつつ、マルチコアプロセッサによって、新たに求められる機能/性能を実現しようということだ。このコンセプトを具現化するものとして、富士通研究所は、コアの数に依存しないスケーラブルなマルチコアプラットフォームを開発中である（図3）。これは、既存のアプリケーションプログラムにおいて並列化可能な部分を、プログラムに大きく手を加えることなく、コンパイル処理でマルチコアに対応させようというものだ。

　このプラットフォームは、関数の単位で並列化を実現するプログラミングモデルを提供する。OSやドライバ、個々の機能を実現するプログラムについては、シングルコア時代の資産を再利用する。既存のアプリケーションプログラムは、それぞれに何らかの並列性を備えているので、その部分を複数のコアに割り当てる。この処理を自動化しようというものである。各コアに割り当てた処理は、RPC（remote procedure call）の形で非同期で呼び出される。これを実現するRPCライブラリ（ARPCライブラリ）と、負荷分散を担うスケジューラで構成される。

　開発フローは、既存のC言語プログラムから始まる。それを分析して、並列性のある部分を見つけ出し、その部分に「#pragma ARPC」という行を手作業で追加する。この記述に対応する専用変換ツールにより、関数の起動、中断、ポーリングによる完了待ち、完了待ちを表すAPI（application program interface）を用いたコードを生成する。そのコードに対応して、1つのコアがその他のコアに対して非同期型のRPC技術を用いて関数を呼び出す仕組みだ。このコードを基に、ターゲットとするプロセッサのネイティブコンパイラによって最終的なコードを生成する。

　消費電力を削減するための機能として、特にプログラムを修正することなく、処理を行っていないコアのクロックを停止する機能も盛り込まれている。サンプルアプリケーションでは、20％の電力削減効果が確認できたという。

　このプログラミングモデルにおいては、メモリー（ポインタ）の扱い方が重要になる。複数のコアが共有のメモリーを持っている場合には、データの一貫性を保証するために完了待ちの処理で対処する。一方、各コアがローカルメモリーを持っている場合には、あるコアからもう1つのコアに対してメモリーデータのコピーを行うといった処理が必要になる。この処理のためのAPIも現在開発中だという。

　また、分散処理については、多数のコアを利用するケースに対応するために、ハードウエアアシスト機能を備えたスケジューラによってスケジューリングの高速化を図ることも検討しているという。

　もう1つ、ソフトウエア開発の生産性を高めるための方策についての発表が行われた。スピーカを務めたのは、早稲田大学 理工学術院 基幹理工学部 情報理工学科 教授の笠原博徳氏と、ルネサス テクノロジ CPU開発第一部 部長の服部俊洋氏である。「勝ち残れるマルチコアはソフトウエア生産性の高いマルチコア」（笠原氏）との発想の下、考え出されたのが、自動並列化コンパイラ「OSCAR Parallelizing Compiler（以下、OSCARコンパイラ）」である。これは、NEDO（新エネルギー・産業技術総合開発機構）のプロジェクトとして、2005年7月～2008年5月に行われた「リアルタイム情報家電用マルチコア技術の研究開発」における成果である。同プロジェクトには、日立製作所、ルネサス、富士通、東芝、松下電器産業、NECも参加した。

　このプロジェクトでは、8コアのプロセッサを試作し、OSCARコンパイラを使って自動並列化したプログラムで目標性能を実現しようと考えた。その際、特に注目していたのは消費電力である。また、参加各社のマルチコアのいずれにも対応したコードをOSCARコンパイラによって生成できるよう、共通のマルチコアアーキテクチャのモデルを考案し、それに対応したAPIを策定した。そのアーキテクチャのサブセットと見なせるプロセッサであれば、OSCARコンパイラを適用できるという。

　OSCARコンパイラでは、より多くの並列性を自動的に抽出できるようにすることを目標とした。具体的には粗粒度（コースグレイン）のタスクの並列化、すなわち、ループ、サブルーチン間の並列性を自動的に抽出する技術を開発し、同コンパイラに盛り込んだ。

　メモリーに対する最適化も重視した。従来の方式では、1つ1つのループの内部でキャッシュ/ローカルメモリーに対する最適化が行われる。それに対し、OSCARコンパイラでは、並列性を抽出した後、ローカルメモリー、キャッシュメモリーのサイズに合わせて、ループやデータを分割し、プログラム全体に対して最適化が行われるという。それぞれのループで扱う配列サイズがキャッシュ/ローカルメモリーのサイズよりも大きい場合には、それを小さい2つのデータに分割する。同じ配列にアクセスするループの集合を1つのプロセッサに連続して割り当てることで、プログラム全体でキャッシュの再利用を図ることが可能になるという。なお、この最適化では効果が得られないケースでは、DMA（direct memory access）コントローラを利用する。

　また、低消費電力化に向けて、処理を行っていないコアの周波数/電圧を下げたり、電源を遮断したりする仕組みを設けた。この機構も、OSCARコンパイラが備えている。

　OSCARコンパイラで処理できるのは、C言語またはFORTRANで記述したプログラムである。ただし、C言語については、ポインタの利用法に制限を加えたC言語のサブセットのみ利用できる。プログラムをOSCARコンパイラで処理すると、並列性の抽出、メモリーに対する最適化、電力制御用コードの付加を行ったコードが生成される。生成されたコードは、C言語のコードに、APIを用いて記述した指示文が追加された形となる。指示文に記述されるのは、変数をどのメモリーに格納するのか、どのデータに対してDMAコントローラを使うのか、どのタイミングで周波数/電圧を下げるのかといったことだ。このAPIを解釈可能な専用コンパイラで前処理を行い、生成されたコードを各社の逐次コンパイラで処理すれば、各社のマルチコアプロセッサで並列動作するコードを生成できる。

■チップの特徴と評価結果
　一方、OSCARコンパイラとともに開発されたのは、プロセッサとRAMを8個ずつ搭載する「RP2」というプロセッサである。90nmプロセスで製造し、1つのコアの面積は6.6mm²。1.0V/600MHz動作時に8640MIPSを実現し、その消費電力は2.8Wである。

　RP2は、2つのクラスタから成り、各クラスタが4つのプロセッサコアを備える（図4）。これら4個のコアの間のコヒーレンシ（一貫性）は、スヌープコントローラによって保証する。2つのクラスタ間のコヒーレンシは、ハードウエアでは保証しない。

　RP2では、「マルチコアプロセッサでは、すべてのコアが常に処理を行っているわけではない。情報家電向けの場合、個々のコアの電力制御をきめ細やかに行ってリーク電流による電力消費を抑えることが必須だ」（ルネサスの服部氏）との考えに基づき、低消費電力化に向けての対策が行われた。具体的には、8個ずつのコアとRAMの電源をそれぞれ独立とし、個々にクロックの停止や電源の遮断が行えるようにした。同社従来品では、キャッシュメモリーのデータを保持することを目的として電源の遮断は行わない、いわゆるスリープモードを設けていた。それに対し、RP2では、キャッシュメモリーのみ電源は遮断せず、それ以外のブロックの電源をすべて遮断するモードを設けた。これにより、従来のスリープモードに対し、88％の消費電力削減が実現できたという。

　また、処理性能の向上を目的とした工夫として、バリアー同期処理の高速化を図った。複数のコアに依存関係が生まれる処理が行われる場合、各コアの処理の完了を待ってから次の処理に移るために、バリアー同期の手法が用いられることが多い。これをソフトウエアで実現しようとすると、処理負荷が重く、時間もかかってしまう。そこで、ハードウエアによってバリアー同期を実現する機構を盛り込んだ。各コアの処理が完了したことを示すフラグを共有メモリー上に格納するのではなく、各コア内にすべてのコアのバリアフラグを書き込むレジスタを用意し、それを各コアが確認して処理を進めるようにした。これにより、ソフトウエアによるバリアー同期に対して、18倍の高速化が図れたという。

　このRP2を用い、OSCARコンパイラによってコードを生成して評価を行ったところ、並列処理を担うコア数を1、2、4、8個と増やすことで、1.0、1.9、3.6、5.8倍の性能が得られた（評価にはAACエンコーディングのサンプルを使用）。また、OSCARコンパイラによる電力制御コードについては、88％の電力削減効果が確認できた（AACエンコーディングとAES暗号処理のサンプルを使用）。笠原氏は、「この自動並列化にかかる時間は2～3s程度なので、開発期間を大幅に短縮できることが確認できた」と述べた。

（飴本 健）