[ 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 なので、たくさん使えば同時アクセス数は増やせます