月: 2009年12月

[ FLOPS2D の設計コンセプト ]
JAXA における数値シミュレーション:
– 1980 年に M380 で二次元翼
– NS-I (1987): 1GFLOPS
– NS-II (1995): 数値風洞 : ベクトル計算機 280GFLOPS
– NS-III (2000): スカラ型 9.7TFLOPS
– JSS (2009): 140TFLOPS
二次元翼→三次元翼→オイラー全機→反応流→タービン全周解析→NS全機解析→…
三次元非定常計算の例: 液噴流コアの直接数値計算 (気液二相解析):
– 格子点: 60億
– 格子幅: 0.6um
– 5760コア、60TFLOPSで1ヶ月
– 出力総量: 153TB
100倍の計算をしようと思ったらどうするか…?
いろいろなCFDのコードがあって、メモリアクセスが主だったりディスクアクセスが主だったりする。ということは、固定されたアーキテクチャではしんどい。
リコンフィギャラブルで、「運用可能な程度にコンパクト」なシステム方式。
さきほどの乱流噴霧のだと、実行効率は4%くらいなので、もうちょっと効率よくしたい…
非定常計算が増えているのでファイル処理が問題。
柴田先生: 計算に合わせて構造を変える、というのは、つなぎかたを変えることを考えている? それともFPGAの中だけ? → 両方を考えています。現段階では機能を詰め込めるか、というところが問題。将来的にはバックプレーン的なもので専用の interconnect を作ることも考えている。
京先生: 4% くらいの実効、というボトルネックはどこにあるか解析されていますか? → 噴流の問題では通信が問題になってしまっている。実際のところスカラ型の並列計算機で 4% というのはそんなに悪くないと考えているが、ひと桁効率をあげたい。
山口先生: GPGPUでもGRAPEのような専用パイプラインでもなくFPGAなのはなぜでしょう? → GPUやCellのほうが性能は出しやすいのだが、センター運用という観点で reconfigurability に魅力を感じている。
泉先生: いまのソフトウェア実装は並列システムに適した実装 (データの空間的局所性) になっている? → はい。HPF 系の言語を使っているのでわりと楽にかけています。MPI を使う場合はデータの局所性を考えてやっている。マルチコアに関してはコンパイラに任せてスレッド並列化し、ユーザはチップ間の並列化をチューニングする感じ。
中條先生: ホストに接続できるカードの枚数は上限がある? → プロトコル的には 64 くらいまでだけど、まだ実装はしていない (し、ハードウェア的には制限がないはず)
京先生: どれくらい市場規模があるか、というのがメーカーの人間としては気になります → CFDの計算機の潜在的な需要は高いが、大規模なCFDとなるとあまり売れないと思う。それでも共通利用施設としての計算機センターとしてシステムを提供することは重要。
[ 各種暗号処理に適した2入力LUTプログラマブルロジックアーキテクチャの検討 ]
2入力LUTからなるePLXcryptと、sbox用のメモリMEMcrypt.
DES, AES, Camellia, などを実装することを考慮している。
ePLXcrypt は、配線と LUT の粒度を変えることでトランジスタ数を 40% くらい削減。
中原先生: LUTの入力サイズが2、というのが気になる。配線ふえないのはなぜ? → XOR とかが多いので。
山口先生: 結局はこれ、粗粒度アーキテクチャ的な方向なのでは? → ビットシフトとかがどれくらいうまくできるかがよくわからないので、検討していきたい。
京先生: 開発ツールは? → ePLX は専用のツールがある。ePLXcrypt はまだない。
[ マルチFPGAシステムFLOPS-2Dに向けたパイプライン構築手法の検討 ]
RER! RER!
中條先生: PCクラスタの限界というのは台数を増やしても性能が上がらないということ? →通信が飽和しちゃう。
回路を分割した場合の複数のFPGAの同期はどうしている? → そのうち…
柴田先生: 複数のFPGAに分割するときの問題にはまず通信量があるのでは? → 切り口にするところはなるべく細いところを手で探して、そこを候補点にしている。
山口先生: メモリボトルネックなのか、演算密度が高いのか、発表ではよくわからなかった →
名古屋先生: 分割したもののひとつだけが速くなっていても全体は速くなりませんよね → グローバル最適化が必要だと思います…
[ 3アドレスQDDマシン用コードの最適化アルゴリズムについて ]
Binary Decision Diagram: 論理関数を評価してシミュレーションを行う。
評価時間は平均ステップ数に依存。
MDD(k): BDDの2値変数をk個ずつグループ化した決定グラフ。
最大でBDDのk倍速くなるが、メモリ量が2^kに比例して必要。
で、QDD を評価するための専用マシンを作る。
ふんがさん: 命令長とかアドレス長は? → 命令が32bitで、アドレスが8bitくらいで3アドレッシング。ほんとはQDDだから4アドレス入れたいけど、そうするとアドレス幅が短くなりすぎて、大きな関数が評価できなくなってしまう。
柴田先生: どの変数とどの変数を合体させるのかとか評価順とかを含めて最適化している? →
[ 動的再構成型可変長複合回路の性能評価 ]
すみません、ちょっと席を外しておりました。
[ H264エンコーダのコア関数のSTPエンジンへの実装 ]
H264は動き予測が高度で、2倍以上の圧縮効率。だが、CPUでは大変。
NECの STP (Stream transpose) エンジン搭載の X-bridge に実装。
む、これって DRP か！！
泉先生: いまのチューニングは将来はコンパイラがやってくれそうか? → いまは手作業です。将来はやってくれると信じたい。
堀先生: オフロードしたのは全体のどれくらい? → 11% くらい。他の部分も同じくらいいけるかな、と思っている (が、関数を選ばないと難しい)
堀先生: 配列にアクセスできるのはふたつまで、というのは改善できる？→ DP RAM なので、たくさん使えば同時アクセス数は増やせます

午後の RECONF
[SRAM型FPGAの部分再構成によるエラー訂正手法の一検討]
SEUで回路が壊れたときにそこを部分再構成する。
Virtex-4 からフレーム単位で部分再構成ができるが、Xilinx のツールではできない。
九工大 中原先生: TMR自体のエラーは考えていない? → voter は壊れないものとしている。voter のところは一定時間間隔で scrubbing (書き直し?) することで信頼性を確保すればいい。
堀先生: フレーム単位での部分再構成は EDA がサポートしていない、というより、１フレームに収まるモジュールは扱えるけど、複数フレームにまたがるようなモジュールはダメ、ということであっていますか? → はい。
堀先生: Readback は誰がやっている? → 外部のPCでやっています。FPGA内部でやるよりは、同じボードにそういう回路を載せることを考えている。
[ MEMS を用いた反転・非反転ダイナミック光再構成型ゲートアレイ ]
TI のデジタルミラー (1024×768) を使用。応答時間は数 ms.
ゲートアレイのほうは、フォトダイオードの接合容量をメモリとして使うやつ。
LUT には 16 個のフォトダイオードがある。でも、照射する点の数が増えるとパワーが下がるので、なるべく照射点数は抑えたい。それで、LUT あたり 4 つのビット反転用フォトダイオードを追加して、それを使って転送ビット数を増やせるかな、という研究。
22% くらい明点を減らせて、それに従って 700ns から 600ns に再構成時間が縮みました。わほーい。
久我先生: 今回は OR 回路なので単純で、明点の数が少ないと思うんだが、実用的な回路になるとどうか → ビット反転の仕掛けで明点を削減するのは大事。複数のレーザーを使ってやる方法もある。
山口先生: 細粒度だけどいっぺんに書き換えられるからいいよね、という方向性か、粗粒度な方向にいくのか → ちょうどいま分岐点に立っていて、考えている。
[ 宇宙放射線に対して高い耐性をもつ光バッファリング手法 ]
構成情報をホログラムメモリに記録しておいて、それを使って不良部分を再プログラムする。
ホログラムメモリにノイズを付加した場合の再構成時間なども測定。
名古屋先生: フォトダイオードが一部不良でもうまくいく、というところをもうすこし詳しく教えてください → 不良になったビットが使えなくなるだけで、他は使える。
渡辺先生@岡山大: ホログラムの冗長性というのは何倍くらいあるんでしょうか? → ポスターでお願いします。
[ PCAにおける圧力の概念を用いた回路増殖法の評価 ]
どこかで集中的に回路リソースを管理するのではなくて、ローカルに混雑具合を見ながら回路をずらしたりしていって、必要なところに空き領域を作る。
構成手順は大幅に減ったけど、通信量が増える。まあ、そりゃしょうがないか。
[ スケーラブルFPGAシステムにおけるハードウェア拡張プロトコル ]
複数の FPGA にまたがる回路をどうやって同期するか?
久我先生: こういうの、どういうアプリケーションだったらうまくいくとかいかないとか、そういう知見があればぜひ…
[ 並列ふるい法とMPUを用いたウイルス検出エンジンについて ]
Snort と ClamAV: パターン数が二桁違う。Snort のほうが手の込んだ正規表現を使っている。
ClamAV では2段階マッチングをしており、パターンの先頭3文字をexact matchで見て、残りをpattern matchする。
インデックス生成関数がキモなのかな。
泉先生: 束縛変数とかを見つけるのはPCでやっているので、アップデートはFPGAの上だけじゃできない? → はい。
山口先生: 最初のexact match のところが速くなっても後ろがしんどくなる、ということはない? → そういうケースはカウンタを入れて見つけて、攻撃とみなしてしまえばいい。
[ サイドチャネル攻撃手法の評価環境の実装 ]
サイドチャネル攻撃対策を入れると回路規模がふくらんで、昔の SASEBO では入らなくなってしまったので SASEBO-GII というのを作りました。V5LX30 or 50 が載る。95,000 円 from TED で USB から configuration + 給電 (!)。
泉先生: ボードの個体差とか、このボードが持っている特性による癖のようなものはある？ → 個体差はたくさん作るのでこれから調べていく。SASEBO でやったらこうで、このボードでやったらこうでした、という知識を集積していきたい。
山口先生: 130nm から 65nm になって電圧以外にかわったことは? テクノロジが変わっても対策はかわらない? → かわらない感じです。だから、昔のデバイスのほうが取りやすいし、そこで対策を考えるのもいいかも。
[ FPGA実装されたストリーム暗号 CryptMT の評価 ]
ストリーム暗号ではブロック暗号と違って、疑似乱数を送信元と受信先で作って、それとデータの XOR をとることで暗号化を行う方式。通信系で多く使われている。

最初はコンピュータシステム研究会。
[ Smith-Waterman アルゴリズムにおける GPU を用いた実装方法の位置提案 ]
土肥君＠長崎大の発表。
既存の GPU 実装 (CUDASW++) とか Cell 版、Xeon 版に比べて健闘している。いいね。
通信バンド幅についてきいてみた。
時間的にはスコア計算のほうが支配的で、まだバンド幅には余裕がある模様。
でも、発表後にマイク付けたまま戻っちゃダメだよ。
[ 高性能かつ低消費電力を実現する可変レベルキャッシュのモード切替アルゴリズムの改良と評価 ]
最近のマイクロプロセッサはなんと言ってもキャッシュで性能を稼ぐわけだけど、キャッシュのリーク電流の割合というのは無視できない。
ノーマルモード (ふつうのキャッシュ) と低消費電力モードがある。
キャッシュの容量が小さくてもよさそうなら低消費電力モードで動かす。低消費電力ではキャッシュの半分をスリープモードにし、そこにあるデータを使いたいときだけ起こして、L2 の中身と入れ替える。
SimpleScalar にこのモード切替コントローラを実装。
除算を使って (わりとちゃんと) 計算する版と、そうでないのと作ったが、性能差は 1% くらいなので除算器なしのほうでもいいかな。
横田先生: キャッシュの容量は変えて評価はとってないの? → はい。
三木先生: スリープモードというのはどこをどう落としたモード? → バンクごとに電圧を変えるようにしておいて、スリープにするときはデータが死なない範囲でキャッシュメモリのそのバンクの電源電圧を丸ごと下げます。
柴田先生: 連想度はどうしてますか? → 4-way です。連想度は変えずにキャッシュラインの数だけが半分になったりします。
渡辺先生@岡山大: 256kB と 512kB で評価をとっているけど、256kB だけとか 512kB だけで走らせた評価があれば教えてください → ありません。
[ 可変パイプライン段数プロセッサのためのメモリアクセスに着目した細粒度なモード切替コントローラ ]
高速モードではパイプラインを D-FF で刻み、低速モードではそれを外す。
メモリアクセスと負荷の関係があることがわかったので、それを基準 (最近の32サイクル分のload,store命令の数) にして制御をする。
あまり細かく制御すると、パイプラインを flush する回数が増えてよろしくない。
– 共有のハードウェアとして作ると、それでオーバーヘッドがあってかえって電力消費が増えるのでは → D-FF のところにマルチプレクサをつけるだけなので、それほど大変ではない
– パイプライン段数を3段階とかにもできる? → 考えてはいる。基本的にパイプラインの各ステージの遅延は同じはずなので、段数は整数倍になっていたほうがいいよね。
[ パス限定投機実行を実現するマルチコアプロセッサPALSの提案 ]
薬袋さんの ISIS-SimpleScalar がベースです!
投機がパス単位なので、メモリ周りは大変ではないかしら? メモリバッファそのものはひとつの投機状態をずっと保持している? → そうです。パス (スレッド) の実行が終了したときにはじめて共有キャッシュに反映される。