********************************************************************** セッション 基盤技術　S4-c テーマ：マルチコア用コンパイラ技術の現在 講師：木村啓二(早稲田大学) 参加者：40名ほど ********************************************************************** ■マルチコア用ソフトウェア開発 組込みでもマルチコア化が進んでいる 今後もマルチコア化の流れが進むと思われる コンパイラは最適化してくれるの？ →現状は最適化はしてくれない プログラマがしなくてはいけない ■今日取り扱う事 そもそもマルチコアのアーキテクチャとは？ 複数のコアを使う方法とは？ これまでのコンパイラやその技術は？ 最後にOSCARコンパイラを紹介 ■マルチコアプロセッサの構成例 マルチコアプロセッサ構成の原型は昔からある SMP型 全てのCPUがメモリを共有 キャッシュとメモリの一貫性を保証する必要がある CPUを増やしにくい 小規模 キャッシュ一貫性の問題→通信バスがボトルネック 共有メモリの操作→アトミック操作が必要 分散メモリ型 メモリは各CPUに分散 キャッシュメモリ一貫性は保証されない 大規模向き CellのSPEはこれに近い構成 ヘテロジニアスな構成 組込では割とよく見る構成 異種な計算資源を持つ ターゲットアプリケーションを意識した構成 ■マルチコアをどのように使うか 今回は並列処理がメインテーマ 普通のC言語を使うの？ 自動的にコンパイラが並列してくれるのか？ ■プログラムの並列化とは ＜手順＞ 並列化可能な箇所の特定 ↓ 並列処理単位(タスク)への分割 ↓ タスクのコアへの割り当て(スケジューリング) ↓ 同期コード・(必要なら)データ転送コードの挿入 ■参考：pthread UNIX系OSで標準的なスレッドライブラリ 各スレッドでメモリを共有しているモデル コンパイラに関係ない ■参考：MPI 分散メモリ型アーキテクチャ向けのAPI プロセス間のデータ転送を記述 C、FORTRANが対象 コンパイラに関係ない 簡単なコードの紹介： プログラマが並列化やデータ転送のコードを記述する必要があり大変 ■参考：OpenMP 処理したい場所にコンパイラ指示文を挿入 SMPを前提にしたメモリモデル 簡単なコードの紹介： 並列化のために記述するコードは少ない ■コンパイラの構成 ＜コンパイラ処理の流れ＞ ソースプログラム ↓ フロントエンド ↓ 高位最適化----並列化は主にここ ↓ 低位最適化----命令スケジューリングなどはここ ↓ コード生成 アセンブラ言語 ■並列処理が可能な条件は？ 処理の順序を変えても計算結果が変わらないこと つまり、2つの処理間に依存性がないこと ■マルチコアプロセッサ向けの並列化 ループ並列化 あるループを複数の処理に分けて各プロセッサに割り当てる 依存がある→ループ繰り返し インデックスに注目 ■ループ(配列)の依存分析 ここ数年で成果あがっている 配列を使うアプリケ-ションには有効な手法 ■StreamIT MITによるdomain specific language(2000) 制御処理系向け ストリーム処理向け 信号処理、コーデック、MPEG2のコーデックが記述できた プログラムの構成要素 構成要素間の通信と並列性を明示する 簡単なコードの紹介： add LowPass()と明示的に記述 ■Cuda NVIDIAによるGPU用プログラミング環境 Cに対する簡易な拡張言語 SIMD型のプログラミングモデル メモリ階層を意識したプログラミングが必要 ■X10、Habanero X10： IBMによるJavaベースの並列プログラミング言語 Habanero: RICE大学によるX10の後継プログラミング言語 特徴： 軽量なスレッド生成によるタスクベースの並列処理とループ並列処理 共有メモリモデルと分散メモリモデルを混在したプログラミングモデル 簡単なコードの紹介： JavaぽくないJavaプログラムという印象 ここまでは、基本的にはループの並列化についての話 ■並列化のポイント 数々の並列化のポイントがある 　チューニングの労力と得られる効果のトレードオフ 　処理の粒度 　負荷分散 　メモリの配置場所 　同期・通信 アムダールの法則がよく知られている ■並列化と低消費電力化 最近は低消費電力化の観点が重要になってきている ■演習 並列化コンパイラで並列化しやすいアプリケーションは？ その理由は？ また、言語拡張まで適用化としたらどう？ 画像フィルタ、画像認識 →並列化しやすい 動画コーデック →MPEG2は並列化しやい。 H.264は複雑な依存性があって並列化は難しい 開発者は並列化できるアルゴリズムを開発して欲しい。 そうすれば多くの研究者も取り上げ普及するかもしれない. データ検索 →C言語のレベルでは並列化は難しい(理由：ポインタを使うため) ワープロ →人間とのインターフェスが増えるためアプリケーション的 に並列化は難しい 並列化しやすいアプリケーションは 処理の役割がわかりやすいもの コンパイラが挙動を簡単に分析できやすいもの ■OSCAR自動並列化コンパイラ 早稲田大学　笠原・木村研で開発している自動並列化コンパイラ 特徴： マルチグレイン化 メモリ最適化 データ転送最適化 低消費電力化 ヘテロジニアス・スケジューリング OSCARコンパイラの構成の紹介 様々なターゲットに対して並列化コードを生成できる ■マルチグレイン並列化処理 プログラム全域にわたる最適化 ループ間の最適化も考慮 データの依存だけでなく制御の依存性も考慮 ■メモリの効率的な利用 メモリの配置はだんだん遠くなってきている キャッシュに載るようにプログラムをかくことがキー キャッシュに乗るように分割してあげる スクラッチパッドメモリを考慮した研究も実施中 データ転送の最適化を考慮した研究も実施中 ここまでは、一般的なアーキテクチャについての研究 ■低消費電力化技術 以前はシミュレーションで評価 現在は、いろいろなマルチコア実機での評価ができるようになってきた ■情報家電用マルチコアAPI OSCARコンパイラと各社チップ(富士通、SHなど)用コンパイラ間のAPIを策定 (現在仕様書を作成中。近日公開予定) C言語のポインタは解析が難しいため使用を制約する→並列C言語 キャッシュの最適化も考慮 ■情報家電用マルチコア:RP1 (詳細な仕様は資料を参照) SH4がベース 4コア搭載 メディアプログラムによる並列性能結果： 1プロセッサと比較して、4プロセッサで平均3.31倍の速度向上 ■情報家電用マルチコア:RP2 (詳細な仕様は資料を参照) SH4がベース 8コア搭載 キャッシュコヒーレンスをソフトで行わなければいけない 電圧制御はチップ単位 周波数制御はコア毎 並列化時の1プロセッサコアに対する処理速度向上率の評価： プロセッサ数：速度向上率 1：1.0 2：1.9 4：3.6 8：5.8 スケールアップした性能の余裕分を低消費電力化に向ける 評価結果： セキュアオーディオ圧縮処理を8コアで実行 電源/周波数制御した場合は、しない場合に比較して88.3%電力削減 動画表示処理を8コアで実行 電源/周波数制御した場合は、しない場合に比較して73.5%電力削減 ■ヘテロジニアスマルチコア 異なる計算エンジンを1チップに集積したアーキテクチャ スケジューリングのイメージを紹介 評価条件： 現在はシミュレーション 評価結果： 性能は、1cpu(1.0)<2spu(1.99)<4cpu(3.97)<2cpu+1FE(7.13)アクセラレータ ■まとめ 今日話した事： マルチコアのソフトウェアについて 各種言語処理系やコンパイル技術の復習 早稲田大学OSCAR自動並列化コンパイラについて ■質問 Q:電力で評価するのはフェア？処理時間を考慮したエネルギーで比較すべきでは？ A:処理時間は長くなるが、デッドラインを守っているので問題はないという認識。 　エネルギーを計算することは可能。しかし計算はしていない。 Q:コンパイルしたらオブジェファイルの数はどれぐらい。 A:最終的には実行ファイル1つになる。 　何コア使おうが実行ファイルは1つになる。 　実行時は複数コアにコピーされて、バリア同期し同時に実行される。 Q:実行時の並列化は可能か？ A:可能です。 Q:OSCARコンパイラではファイングレインをコンパイラが行う？人間の手が入る？ A:コンパイラが行う。 　並列化している対象がループだけでないのが特徴。 Q:ポインターを使わない言語(並列C)は実際にアドレスを指定しないと 　いけなくなるため実際的には不便なのでは？ A:現実的ににCでポインターを全く使わないことは無理。 　配列のエントリーが構造体である場合には、対応可能。 　リンクリストの場合は難しい。 　(でもこの場合アルゴリズム的に複雑になるので仕方ないと考えている) 　でも、ポインターに対応できるように努力している。 Q:OSCARアーキテクチャにおいてマルチタスクの場合はどうなる？ A:想定しているのは、コアをある程度占有し続けるアプリ。 　複数のアプリが頻繁にコアを切り替わるようなものはを対象にするのは難しい。 　コンパイラとOSの協調が重要になる。 これからの重要な課題と考えている。 Q:多くて8コアがメジャーな数。今後コア数が増えていったら、 　このコンパイラに新たな課題がある？それとも今のまま対応できる? A:16コアのシミュレーションで効果はあった。 　32-64コアぐらいではスケープアップすると予想しているが実機がないのが現状。 　シミュレーションでも時間がかかりすぎるため行っていない。 　しかし、今後評価は必要と考えている。 Q:マルチコアのデバッグの開発者支援については？ A:実際マルチコアのデバッグは大変。 　開発者自身に分かる程度のメッセージしか出ない。 　現在まだ手のついてない分野。 　(やはり、研究的には並列化の最適化に向かってしまう)