「T2Kオープンスパコン東大版の稼働報告と今後の動向」/中島研吾(東京大学)
- 機械屋からすると、ファンが直列2連になっているのはいいらしい。
- システムは6年でいれかえ、3年周期でリプレイス。
- SR11000と比べてT2KはメモリBWが低い。ピーク性能にたいしての実効性能が低い。
- opteronをつかったccNUMAなのでopenMPで性能が出ないなど。
- 当初は稼働率が低かった(50%)が、最近は伸びてきた(90%)。
- 超並列やマルチコアの時代だというメッセージをユーザに示せたのではないか。
- SR11000のユーザが反応
- センター史上初となることもいろいろあった
- 他大学への営業とか、ほかにもいろいろ
- パーソナルコースが特徴
- 64ノード 44千円/年 (大学向け)
- SGEがつかいたいというような人にはノード固定コースを用意。
- ファイルシステムが遅いのに対してはHSFSとかLustreとか
- HSFSと比較してLustreは小さいファイルに強い。
- お試しアカウント付講習会
- これはめずらしい。
- 企業の方でも参加可能で、現在は2/3くらいが企業。
- 512ノードサービス: 8192コアを24時間占有できる。
- SR11000のあと
- SMP: 50TFLOPS SMP機はこれが最後になる予定
- MPP: 1PFLOPS アクセラレータはない
「eScienceプロジェクト成果報告」/石川 裕(東京大学)
- PCクラスタからスパコンまでシームレスなプログラミング環境を提供する。
- PCCCからSCore7に同梱。
- プログラミング・コンテストを開催予定 (10/22)
「単一実行環境Xruntime」/石川 裕(東京大学)
- single runtime environment
- ファイルの扱いとか: /tmp, /home
- my pc clusterだとバッチシステムにもっていったときにハマる。
- バッチシステムの異差を吸収する
- つくば: SGE
- 東大: SR11000のやつ
- 京大: fujitsuのやつ
- 環境変数とかコンパイラオプションの違いも吸収する
- ファイルシステムのケア
- 手法1: pdcache
- ノード内でmetadata,dataをキャッシュ
- サーバへのリスエストを調停
- closeセマンティックス
- 手法2: catwalk-ROMIO
- local diskをつかう
- ナイーブな実装だとlocal diskより大きなファイルが扱えないが
- 手法1: pdcache
- MPI環境: mpi-adapter
- おなじバイナリでlibmpi.soの切り替え
- APIは決まっているけど、ABIはばらばらなので動かない。
- eg MPI_COMM_WORLDがintだったりポインタだったり
- バッチジョブスクリプト
- 次世代スパコンでも使えるようにトランスレータを開発中
「自動チューニング機能付き数値計算ライブラリXabclib」/片桐孝洋(東京大学)
- エックスエービーシーリブ
- OpenATLibは汎用自動チューニングインタフェイス。
- xabclibはそれをつかった数値計算ライブラリ。
- ポリシーを選べる: 速度とかメモリ使用量とか計算精度とか。
- それによりアルゴリズムやパラメータがかわる。
- コンパイラではできないような実行時のチューニング。
- 4コアをつかうときに、1core/1socket*4の構成にするか、4core/1socketにするかで、ピーク性能がでるパラメータがちがってくる。
- パラメータの組み合わせは膨大になってしまうので、疎行列・反復法に限定することで、パラメータを絞っている。
- メタインタフェイスというのもある。連立一次方程式を解くとか。
- 偽収束を全自動で防いでくれる。
「高性能並列プログラミング言語処理系XcalableMP」/中尾昌広(筑波大学)
- 研究室PCクラスタからthe K computerまで。
- CやFortranにdirectiveを追加。(like OpenMP)
- #pragma xmp 〜
- performance awareness: どこで通信するのかプログラマから見える。
- global view
- template(仮想配列)/distribute(ノード分割)/assign(実配列との対応)からなる。
- 集合通信をつかいやすくする。
- shadow: 隣接ノード間で共有するデータは同期をとってくれる。
- gmove: a[0:3] = b[3:6] のようにノードを意識せずにコードを書ける。
- local view
- one-sided通信に対応するため。
- co-array
- a[0:3]=b[3:6]:[1]
- NAS parallel benchmark
- MPIの実装と比べて同等の性能がでている。
- ネットワークBWが低い環境で差が出ているが、これはMPIの通信部分のコードが違うため。(XcalableMPの自動生成したMPI呼び出しが最適でないということか?)
「高生産並列スクリプト言語Xcrypt」/平石 拓(京都大学)
- パラメータスイープにつかえる。PDCA cycle。
- 汎用スクリプトとGUIワークフローのあいだをねらっている。
- perlベース。
- なので新しい言語というよりはライブラリ。
- Jobはオブジェクト。
- スクリプトの典型的な構成
- tempalte定義
- prepare
- submit
- sync
- ジョブの終了などはTCP/IPを通じてXcryptにupcallがくる。
- 途中で止まってしまうことを考慮
- ログを残しておいて
- 再実行したきに既に実行済のところはスキップ
パネルディスカッション「ポストT2K時代のセンターマシン」→「5年後のスーパーコンピュータ像」
モデレータ:
- 石川 裕(東京大学)
パネリスト:
- 平石 拓(京都大学)
- 大島 聡史(東京大学)
- 多田野 寛人(筑波大学)
- 菅 真樹(NEC)
- 安島 雄一郎(富士通)
- 櫻井 隆雄(日立)
石川
- 若手がそだってない。いや育てなかった?
- 5年後くらいが想像しやすいとおもって。
- 質問
- どういうマシンをつくるか
- 開発のすすめかた
- マイルストーン
- 開発体制
- キャッチフレーズ
- 10年後のを設計するとしたらどうするか
平石
- SC言語 S式のC
- L-closure:計算状態操作機構:MT,GC,backtrackにもとづく負荷分散
- バックトラックベース負荷分散
- 逐次計算しててどうも暇ならまきもどして並列に実行しなおす。
- アプリ開発者がメモリ管理MPI/openMPをつかうのはおかしい。
- MapReduceは成功例の一つ。
大島
- 28才
- GPGPU歴7年、GPU歴8年
- (早口だなぁ)
- HPC向けGPUとグラフィックス向けのGPUの要求の違いが拡大
- OpenCLが流行る? CUDAじゃない共通プラットホーム
- 「*PUスパコン」
- 10年後にむけては、実用化されていないアキテクチャの勉強が必要
多田野
- 次世代「京」と次々世代とのあいだに時間がある
- 「大学にもペタフロップス環境を!」
菅
- 「データセントリック・スーパーコンピュータ」
- ディスクIO
- インターコネクト
- レイテンシ
- データ配置戦略・構造制御をインテリジェントに行う
- GPUに向けてデータ圧縮をストレージがやるとか
- どうやってコアにデータを供給するかが問題になる
- チェックポイントの書き出しもたいへん
- FPGAを利用 Netezzal のようにストレージ側で計算というアプローチ
- MapReduceは並列化実装をユーザから隠蔽したところに意味がある
安島
- 演算あたりの電力量を減らす方向で
- Power Wall 2000 pJ/flop
- 電圧が1.0Vくらいから下がってない。
- 10%下げて0.6Vくらい(Vthた0.3Vくらいなので)と 10^2pJ/flop
- メニーコア部は超低電圧でマルチコア部は通常電圧となるヘテロCPUアーキテクチャ
- PGAS言語?
- 通信ライブラリはいまのままでブレークスルーは内部の方。
- 購入・設置・運用は独立したプロジェクトで、競争原理がはたらくように。
- 「超低電圧プロセッサ」「マルチ&メニーコア・アーキテクチャ」
- 「競争的開発資金制度」
- めざせ2pJ/flop
櫻井
- 障害件数の増加
- 各所で最適化が困難に
- monitoring-based system management
- 故障予測
- ユーザに対するフィードバックとか
- complex event processing (大量のログの処理)
会場から「アプリからみたエクサの必要性」
会場から 建部「..」
- 3次元メモリ実装で多ピン接続でbyte/flopがもちなおすかもしれない。
会場から「HPC向け言語」
会場から「今の技術の延長でエクサに到達できると安易に考えてない?」
会場から「HPC業界の問題点はなにか?」
- 研究費がつかえなくなってきている。景気回復
- HPCだけでなくデバイスの方も
- 夢がない。月に行くというわかりやすい目標がない。
- 派手さがない。