------------------------------------------------------------------
第 345 回 PTT のお知らせ
--- Programming Tools and Techniques ---
------------------------------------------------------------------
■日時: 2008年6月26日 (木) 18:30 から
■場所: 東京大学 情報理工学系研究科 秋葉原拠点 秋葉原ダイビル 13F
■アクセス情報：
東京大学大学院情報理工学系研究科
創造情報学専攻
http://www.i.u-tokyo.ac.jp/map/index.shtml#aki
〒101-0021 東京都千代田区外神田1-18-13
秋葉原ダイビル（13階）[*地上31階建のビル]
（13階のエレベータを降りてすぐの部屋になります）
1階に警備員の方がいらっしゃいます。もし何か言われたら「13階の
東京大学に用事がある」と仰ってください。また、20時以降、表の入
り口が閉まります。裏口からお回りください。
・JR「秋葉原」駅（電気街側出口）より徒歩1分
・地下鉄日比谷線「秋葉原」駅より徒歩4分
・地下鉄銀座線「末広町」駅より徒歩5分
■食事など：
駅前にパン屋などがあります。
------------------------------------------------------------------
■話者: 三好健文（東京大学大学院情報理工学系研究科）
------------------------------------------------------------------
■題名：ヘテロジニアスマルチプロセッサ向け軽量フレームワークと
自動並列化の試み
------------------------------------------------------------------
■概要：
本発表では，ヘテロジニアスマルチプロセッサを効率良く利用する
ために，計算コアへの繁雑なプログラム転送オーバヘッドを削減す
るための軽量なプログラミングフレームワークについて述べる．こ
れは，計算コアで実行すべき複数の部分プログラムを一つのプログ
ラムとしてまとめて転送し，実行時に制御コアから処理を選択する
ことで所望の計算を実行する．提案手法では，細かい部分プログラ
ムを柔軟に計算コアへ割当てることができるため，従来のコンパイ
ラあるいは動的な粗粒度自動並列化手法とも親和性が高い．本発表
では，提案手法をCellB.E.に適用した例を基に，その評価結果を示
す．
第 345 回 PTT report
出席者：36名
田辺, 笹田, 立木, 橋本, 横山, 河瀬, 相川, 加藤, 薦田, 中島,
丸山 (東大), 並木 (農工大), 辻, 多田, 川ノ上, 丹野, 石橋, 唐
沢, 鵜川, 寺田 (電通大), 大橋, 阿部, 稲岡, 斉藤 (IIJ), 牟田,
三廻部 (IBM), 遠藤 (東工大), 疋田 (トヨタIT開発センター), 卜
部 (TNT), 山崎 (日本工業大学),上野 (千葉大), 阿部 (数理シス
テム), 山崎 (ミラクルアーツ), 永松 (神奈川大), 日比野 (朝日
ネット), 匿名希望
話者: 三好健文（東京大学大学院情報理工学系研究科）
題名：ヘテロジニアスマルチプロセッサ向け軽量フレームワークと
自動並列化の試み
質疑応答：
Q. atomic command はどの程度遅いのか．
A. 数値は忘れたが凄く遅い．
128bitSPEからPPEへ転送する実験をしてみました．
- Atomic DMAでPUTした場合: 0.017481(msec)
- DMAでPUTした場合 : 0.000013(msec)
Q. 図中，A の時間がずれているのは何か．
A. PPEから個々のSPEへ独立にタスクを発行するため．
Q. タスクのロードは同時にできるのか．
A. マルチキャストはできないため同時にはできない．
Q. 図中，B の時間はずれないのか．
A. Bは各SPEでAのタスクの終了を待って実行が開始されるため．
Q. マスターが起動するのは遅いのに，スレーブが動的にタスクを
取りに行くのが速いのはなぜか．
A. (Aの実行が大きく，Bの実行のずれが小さい点についての質問)
タスクの実行には多くのデータを送信しているが，
スレーブが動的にタスクを取りにいくデータは少い．
また，タスク生成のためのPPEの計算時間もあるため．
Q. 動的なタスク選択を選ぶのは PPE, SPE のどちらか
A. 現在は，タスクキューにあるトップをSPEが取りにいく．
Q. 動的なタスクタスクは SPE にロードされているのか
A. タスクの実行バイナリはSPEにロードされている．
Q. タスク管理は入出力を送受信するだけか
A. 入出力の管理と，同期の管理．
Q. オーバーレイはしないのか．する場合，スケジューリングポリシが
変わるのではないか
A. 変わる．SPEでタスクを選択できるようにする必要があります．
Q. デッドロックは起こらない？
A. 適切にロックしているつもり
Q. バイナリサイズを考慮したスケジューリングが必要？
A. 将来的には必要になります．
Q. 静的なスケジューリングは要るのか．
A. 静的なものは静的にスケジューリングしたいという基本的な
発想がある．動的なタスクのオーバヘッド等を詳細に調査し
てみます．
Q. 外れタスクを取ったら待ってしまうのか．
A. 待ってしまいます．
ただし，依存関係の解決したレディタスクのみをキューに
挿入することで解決できます．
Q. タスク構造体に依存関係を記述するものは無かったと思うが．
A. タスク構造体は，単にタスクに必要なデータを保持します．
タスク間の依存については，現在タスクモジュールで記述する
必要があります．ランタイムだけを見ると，これはユーザへ負
担をかけることを意味しますが，将来的に，コンパイラ等での
自動生成によって解決することを検討しています．
Q. タスク1, 2 の同期はどのようなコードになるのか．
A. 共有するメモリのカウンタで管理しています．
Q. modoki のプログラミングモデルは？ 子供の終了を待つような
コードは書けるのか．
A. 新しいタスクを生成し，その終了を待つことはできません．
継続のようなモデルで記述する必要があります．
Q. slave processor が task を生成したとき，親が待たなければ
ならないか．事実上の関数呼び出しなのか．
A. 関数呼び出しにはなりません．
Q. OpenMP を対象にしていると共有メモリを前提としているが，
分散メモリ型の Cell ではどうなのか．
A. 提案フレームワークをバックエンドとする粗粒度並列化として，
OpenMP向けの粗粒度並列化コンパイラを用いたという話で，
OPenMPを対象にしているわけではありません．
ご指摘に通り，Cellでは分散メモリとなりますので，効率良い実行には
データ授受を考慮したタスク分割/分散が必要になります．
Q. このフレームワークが実際に適用できるアプリケーションは何か．
A. たとえば，信号処理システムを考えています．
回数が決定している静的なタスクと，そうでないタスクがあるような
ケースを想定しています．
Q. CPU + GPU のようなモデルでも使えるか．
A. フレームワークは使えるとは思いますが，よりデータの分割に関する
比重が多きくなりますので，OpenMPを対象にした粗粒度並列化コンパ
イラをそのまま用いることは難しそうです．
Q. 自動SIMD化はこのフレームワークは出来ないのか．
A. 考慮していません．自動SIMD化は粒度が細かすぎますので．
別途，バックエンド側のコンパイラでサポートすればよいと思います．
Q. データの分割に対するサポートは？
A. 今回の話ではタスク分割をメインにしています．
データの分割は各モジュールで明示的に実装する必要があります．
これはコンパイラ側でサポートしたいところです．
Q. ネットワーク越しに使えないか．
A. データの分割が主問題になりそうです．
C. 既存研究が多い．
A. グリッドやSMPとは違うヘテロジニアスならではの特徴，制約を
活用/解決できればいいかなと思っています．
C. FP を対象とするのなら，クラスタでやれたほうが．
A. チップ内通信ということでクラスタとは違う問題の切り分けができそう
だと思っています．
Q. FP の転送速度は距離に寄るのか
A. 距離によると思います．
Q. FP において，グルーピングして複数並列化してもマスターは
分散できないのではないか．
A. 一つのアプリケーション/プロセスに対してマスタを分散することは
困難ですし，性能がでないような気がしますが，
複数のアプリケーション/プロセスに対して，それぞれのマスタを
用いることで並列実行することはできそうです．
Q. 「動的だけでいいのでは」という質問にはどう答えるのか．
A. 実験してみます．