「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より大きなファイルが扱えないが
  • 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だけでなくデバイスの方も
  • 夢がない。月に行くというわかりやすい目標がない。
  • 派手さがない。