Kepler2のどの点が大規模アプリ屋から見て魅力的でしょうか？FLOPSやメモリバンド幅等の絶対性能は公式には発表されてませんが、まあFermi 2050比で2~3倍と仮定して。@sdpaninf

posted at 12:24:37

RT @sdpaninf: 予算や電力などの制約があると思いますが、これからのアプリ分野の進展を考えますとやはり必要では。。。アプリ屋さんの無責任な意見ですが@ProfMatsuoka やはり必要ですかね？ RT @sdpaninf ただしそのとき日本で Kepler 用の大規模実行基盤があるかは知りません

posted at 12:23:02

やはり必要ですかね？ RT @sdpaninf ただしそのとき日本で Kepler 用の大規模実行基盤があるかは知りません http://t.co/JVbqjnp7

posted at 11:38:17

RT @sdpaninf: http://t.co/qpgWEcLI Kepler が出ると良い意味で TSUBAME2.0 上で作成した SDPARA 7.5.0-G も書き直しになる。ただしそのとき日本で Kepler 用の大規模実行基盤があるかは知りません http://t.co/W11Q6dNS

posted at 11:37:35

RT @sdpaninf: 最適化ソフトウェアの求解能力の向上は，計算機の性能向上ではなく、最適化理論の進歩が原因と言う人が多いのですが、http://t.co/pqrvKc7n どっちも重要です。実際に 148万制約の SDP の求解は T2 の 4080 個の GPU 計算パワーによって達成されています

posted at 00:55:39

RT @sdpaninf: 曇ったおかげで、ハンディカムでも撮影できた。http://t.co/j7vdvorh

posted at 08:24:37

それは単に京のノードの相対計算性能が低いからでは? HA-PACSだとinjectionバンド幅は8GB/s以上あるし。@sdpaninf

posted at 14:35:32

RT @sdpaninf: いろいろと実験した結果では、F社の Tofu （通信ライブラリ込み）の上に HA-PACS のノード(SandyBridgeEP + Tesla) を載せると（技術的に載ればですが）、超高性能なスパコンが出来ると思います。同じように思っている人が予想よりも多くて驚き。

posted at 14:33:33

両方とも。“@sdpaninf: 今回 GTC に参加できなくて残念だったのですが、こちらには参加します。http://t.co/UiqRbjZI @torii_h @m_sekijima GTC2013は3月19〜23日です。たぶん、こっちの方が。。。”

posted at 14:31:41

RT @sdpaninf: @ToshioEndo 某書類を真面目に読んで勉強になりました。複数メモリ階層の最適配置では、アプリ側での実行時再配置技術が重要で、最小電力でデータを省電力高密度演算器に届けるのはロジスティクス(適時、適量）最適化と同じ概念ですから、全体で大きな最適化問題と捉えることもできます。

posted at 10:15:56

おっしゃるようにDRAMを含めて「完璧」なメモリデバイスや実装法は無いと。なのでメモリ階層を深化させアプリ特性によって使い分けるしか無いと。で、現実的には外部か積層実装でDRAMとフラッシュの間にはさまるモノですが、色々一長一短で。。。@Prof_hrk @sdpaninf

posted at 19:41:29

RT @Prof_hrk: @ProfMatsuoka @sdpaninf NVMは何を使うと考えていらっしゃいますか？ いろいろと考えているのだけれど、なかなか本命感がないものばかりです。

posted at 19:34:16

もう今後のスパコンとIDCは電力の制限から不揮発性メモリの活用がカギ。でないと性能あたりのメモリ量が今の1/10未満に。しかもメモリ階層のかなり上位で。で、デバイスからアプリまでcross-cutするので色々なプロジェクトが連携してあたる必要があります。@sdpaninf

posted at 16:22:33

RT @sdpaninf: Fusion-IO で ioMemoryを拡張メモリ空間として使用可能ということで、使用するデータを総移動距離(Flow x Distance)最小の意味でを複数階層に分けてみた。もちろん真面目にやるとNP-困難なので近似で。 http://t.co/RJVgKHIZ

posted at 16:15:24

RT @sdpaninf: 京は知りませんが、FX10 から見ると Tofu と通信ライブラリは超高性能で、その上の部分の総合性能は Intel 系に劣ります。Tofu 上に Intel Xeon 系を搭載できたら超協力なマシンになるでしょう。コンパイラやライブラリの性能でも現時点では Intel 系が有利

posted at 00:55:29

RT @sdpaninf: TSUBAME 2.0 における Cholesky 測定 (2012年4月5日) : 1360 ノード, 4080 GPU, 行列サイズ N = 1484406, 計算量 1.0903e+18, 実行時間 2045.0秒, 性能値 5.3314e+14 FLOPS

posted at 03:27:39

RT @sdpaninf: TSUBAME 2.0 における Linpack 測定 (2010年10月18日）: 1357 ノード, 4071 GPU, 行列サイズ N = 2490368, 計算量 = 1.0297e+19, 実行時間 8639.84秒, 性能値 1.1918e+15 FLOPS

posted at 03:27:35

RT @sdpaninf: HPCI提供資源一覧 : http://t.co/FRiGw7WG 今回作成した SDP と Graph500 用のプログラムが想定通りの高性能が発揮できるのは TSUBAME 2.0 と HA-PACS(ここにはない)ぐらいと予想。

posted at 16:22:42

RT @sdpaninf: 日本の高機能素材産業で特筆すべきなのは、現場の製造能力の高さで、超電導ケーブルにしても各国とも研究室レベルの実験やアイデアの考案は出来ても、複数の素材を組み合わせて焼き上げる技術はどうしても日本の企業に勝てないそうです。こんな話は現場に行くと数えきれないぐらい聞くことができます。

posted at 18:21:37

RT @sdpaninf: 日本の先端産業はかなり前から高機能素材産業(半導体, LED, 鉄鋼, 電池, 電線, 炭素繊維、紙、水)に移っていまして、確実に世界の製造業のサプライ・チェインの最上流を握りつつあります。日本の電機, IT関係企業の不調ばかりが伝えられて、意外と知られていないのですが。。。

posted at 18:18:19

これ元々333Mhzの富士通オフィスPCを64台使ったクラスタスパコン"Presto I（1997)"を世代を重ねCPUアップグレード・OCして1.3Ghz(初期設計の4倍）になったらある日ゲタの電源レギュレータがパンク焼失…@hashimoto_tokyo @sdpaninf

posted at 11:05:31

RT @sdpaninf: http://t.co/w6rp890i 結局 1.3GHz ぐらいまで上げてこうなりました。@ProfMatsuoka @hashimoto_tokyo Celeron 300A をSocket370→Slot1ゲタで300→450Mhzとか。でも燃えたことも。懐かしいなあ。

posted at 11:00:50

GPU対応が良くなってるので上げるべき。“@htsst: @ToshioEndo @sdpaninf T2のデフォルトも上げるべきだとは思いますが、個人でmvapich2をインストールしてもSキューで動作はしました。性能面は未検証ですが。。”

posted at 14:12:51

RT @sacred_fox: @sdpaninf @ToshioEndo 横からすみません、mvapich2のほうは/homeに入れるという手があります ~nomura-a-ac/mpi/mvapich2-1.8a1p1/config.log が参考になるかもしれません

posted at 14:11:04

RT @sdpaninf: @ToshioEndo 受賞おめでとうございます（副賞付くのかな？）。ところで勝手なお願いで申し訳ないのですが、某スパコンのmvapich2 のバージョン上げるの難しいでしょうか？それに atomic 命令も使いたいので Intel コンパイラも新しいのが良いです。

posted at 14:10:58

RT @sdpaninf: 同じ２号館８階の住人です。近所ですので、これからよろしくお願いします。ちなみにTSUBAME のヘビーユーザーでもあります。@kentakeuchi2003 きょう、@ProfMatsuoka 先生を訪問し、スパコンのビデオを拝見。

posted at 20:06:36

RT @sdpaninf: あの方から情報が来ました http://t.co/V29Qmqus あの方も iPad版を作っているそうです。公開不可かもしれませんが、性能的はこちらの方が上だと思います。RT: LinpackのiPad版を開発元のドンガラ先生のチームがAppStoreに

posted at 19:35:30

をを、巨匠一号ですか。まあ確かに不可でしょうね。こちらの巨匠二号と競争すると面白いのですが、彼は全体で高性能が出ないと興味がないので残念。@sdpaninf あの方も iPad版(Linpack)を作っているそうです。公開不可かもしれませんが、性能的はこちらの方が上だと思います。

posted at 10:17:58

RT @sdpaninf: 何やってたのという質問ありましたが、TSUBAME グランドチャレンジ(4/3 〜 6) : 当CREST から２チーム：(1) Graph500 ベンチマーク (2) 最適化問題(SDP)に対する世界記録挑戦(更新)。東工大の皆様ご協力大変ありがとうございました。

posted at 03:15:31

RT @sdpaninf: 結果を整理中。TSUBAME 2 の Linpack 測定時のヘテロ混成計算と通信と計算のオーバーラップ技術を実アプリにも応用しました。最適化汎用ソルバーなので、定式化できれば基本的に何でも解けるはず。このまま T2 にインストールして世界中の研究者に使用してもらえれば幸い。

posted at 23:37:16

RT @sdpaninf: 両方在籍した経験から言いますと早稲田と東工大では研究のレベルがアマとプロくらい差があります。@torii_h 早稲田、慶応、東大、千葉大、回ったうちで、東工大が一番良かったとのこと。２年後本当に受験するかもです。

posted at 22:32:58

RT @sdpaninf: n = 1484406 --> 約533TFlops です。Cholesky 分解(GPU 依存)だけでなく、内点法アルゴリズム全体(CPU + GPU)が安定して動いています。予想よりも良い感じです。@ProfMatsuoka つまり約500テラフロップスですな。素晴らしい。

posted at 02:57:11

つまり約500テラフロップスですな。素晴らしい。@sdpaninf

posted at 00:47:03

RT @sdpaninf: 3 乗のオーダーの部分(Cholesky 分解：計算量 1.0903e+18 FLOP : 約 1 エクサ)を TSUBAME 2.0 の 4080 GPU の処理で 約 2045 秒で通過。ちなみに 4 乗部分は 2720 CPU の並列処理でわずか 6.5 分で通過。

posted at 00:46:06

RT @sdpaninf: 昨日は日独伊の招聘研究者を連れて東工大。GSIC のご厚意でフルスケールのTSUBAME 2.0 見学会。以下の４つに強烈な印象を覚えたそうです。1: CPU+GPU の巨大な計算能力 2: 最適化も含めた幅広いアプリ 3: ストレージ系の豪華さ 4: 高校生等への教育普及活動

posted at 16:40:20

RT @sdpaninf: @ProfMatsuoka 今回は Linpack のコード(CPU+GPU)を LU から Cholesky に変え線形方程式ソルバーにして、SDP に対する内点法に組み入れたものですが（実際にさらにかなりの工夫が）、実アプリでも大規模かつ安定動作することが確認できたわけです

posted at 23:50:23

まあ京でも同様にしばしば「宣伝」してますが、このようなペタフロップス級の計算の場合、大規模スパコンではかのごとく高信頼性が不可欠なのです。Tsubame2もメーカーとの協業の継続的な小改良の結果、かのごとく相当高信頼になりました。単に並べただけでは動かない。@sdpaninf

posted at 23:12:02

RT @sdpaninf: 昨日はGPUコンピューティング講習会の後、GSIC で作戦会議。特定問題用に tuning するのではなく、特性の異なる様々な問題に対してもソルバー自身が、ほぼ最適に近い計算方法の組み合わせを見付けてくれるはず。あとは CPU コアによる行列生成と GPU による行列分解に期待。

posted at 01:24:56

RT @sdpaninf: http://t.co/splY2Aba 様々な工場等に見学に行きますが、高機能素材(半導体, LED, 鉄鋼等)における日本メーカーのシェアは非常に増大していることはあまり知られてません。日本からこれらの供給が途絶えれば、世界の製造業は在庫が無くなった時点でアウト。

posted at 00:47:01

RT @sdpaninf: T2(CPU + GPU) で最高性能を出そうと思うと、現存する世界最大規模の SDP でもまだ小さいという試算結果が。。。よって、もっと大きな規模を狙っても良いのだが、その規模だと今度は実行に何日もかかってしまう

posted at 17:42:48

RT @sdpaninf: @ProfMatsuoka @htsst @ToshioEndo 超大規模問題用の最新ソースコードはちょっと複雑になってまして、これが T2 上で長時間安定して動作(4920コア)できたのが幸いでした（普通のスパコンですと◯◯な理由で最新版を使えないことが多いので）。

posted at 20:58:45

おめでとうございます。またTSUBAME2で世界一が。@sdpaninf 結果を確認しまして、T2 で SDP の世界記録更新(制約数 = 379350)できたのですが、目標は 120 万制約なのでまだまだです。結果解析してからまた送ります。@htsst @ToshioEndo

posted at 13:00:01

前者は誰でもできることだから優位な競争力にはならないわけですね。後者が金脈。@sdpaninf リアルタイムで流れて来た超大規模データに優先順位を付けて計算量の少ないアルゴリズムで処理するイメージですと、クラウドでも十分と思う人が多いと思いますが、また別の形態が@htsst

posted at 11:37:09

ヲヲ。“@sdpaninf: http://t.co/1W2ofcZe Intel Xeon E7-4870 2.4GHz 10 コア x 4 CPU x HT = 80 コア。HT 無しでも AMD Magny-cours 48 コアに勝てると思います。”

posted at 02:34:27

Tsubame2は因みに省電力(Speedstep)は常時オンです。性能ペナルティはないことは確認済み。@sdpaninf

posted at 20:51:50

RT @sdpaninf: おそらく測定時はオフだったと思います。Xeon X5690(3.46GHz) が2個(HT24コア)ですので、アイドル時でも大きめの値になります @ProfMatsuoka C2075アイドル50WなのでCPU側の省電力設定がオフなのでは？http://t.co/yioZXi50

posted at 20:49:13

C2075アイドル50WなのでCPU側の省電力設定がオフなのでは？“@sdpaninf: http://t.co/WfRecTCH 設定変更で中を開けたら、本当に C2075 が４枚入っていた。アイドル時でも400W/h に達している。最大時には 1000W/h を超えるらしい”

posted at 20:40:56

RT @sdpaninf: 安定性と他の部分の性能は非常に良好でした。いろいろ工夫してまた挑戦します。@ProfMatsuoka @htsst @ToshioEndo 春に調査予定です。

posted at 00:40:00

RT @sdpaninf: @htsst @ToshioEndo 今回のように大規模で長時間、連続最適化問題を安定して解いた例は他には無いと思います。本体の計算量が大きいので、本当にネットワーク性能低下しているならば、ブロックサイズを大きくして対応します。

posted at 23:22:32

春に調査予定です。“@sdpaninf: @htsst @ToshioEndo 今回無事に 404ノード(4848コア)完走できたのですが、ネットワーク性能の見積もりが甘かった…多ノード通信時で複数のスイッチを経由するときに何らかの原因で性能低下している可能性があります。”

posted at 23:21:19