アカウント名:
パスワード:
前々からですが、スパコンのプロセッサは自分で作るものではないという感じですね先端プロセスで専用プロセッサを作る手間とコストを考えたら見合わないし、ウェハー製造を出来るファウンダリも限定されるので．．．．．．．結局は大量生産のスケールメリットをフルに享受している汎用プロセッサには敵わない
＃残念ながら、いくら富士通が頑張ってもSPARCは先のない負け組
スパコンの肝はバンド幅です。また、巨大な超並列となると宇宙線によるソフトエラーが無視できなくなりますが、現在のXEON EはRASの実装が限定的です。ネットワークをシンプルにするにはルータを単純にしてオンチップのI/Oをリッチにする必要があります。また今後のスパコンは「なるべくデータを動かさない」方向で開発が進んでいると聞いています。
XEONやItaniumが要求を満足しているならそれでも構わないのでしょうが、現状の量産チップでは超並列を連続して動かせる信頼性に欠けているので、必要に迫られて自分で作ることになります。ノードごと縮退させるなら現状でもいいのですが、それではいけないと判断してるんでしょう。
ちなみに、富士通のSparc64はOracleでも使っているので、汎用といえば汎用ですね。数はともかくスパコン以外でも開発費用は回収できています。
バンド幅がどれぐらい必要かなんてそんなの完全にアプリ次第だし、RASの実装が限定的ってそんなに困ることですか？
１６０００ノードで５時間かかるLinpackが走り切るぐらいの信頼性があればたいていの科学技術アプリでは問題ないんじゃないですかね。
> RASの実装が限定的ってそんなに困ることですか？
大規模なスパコンだと、割と困りますね。
http://www.geocities.jp/andosprocinfo/wadai13/20130601.htm [geocities.jp]にありますが、> TitanもLinpackはGPUメモリだけで実行できる規模で，1時間くらいで終わっていました。> この理由の一つが，故障発生頻度が高く，マシンが長時間，連続して動かないことであったといわれています。> Tianhe-1AもMTBFが数時間とか言われていました。ハード規模に逆比例して，Tianhe-2でMTBFが更に> 短くなると，なかなかフルシステムでは長時間の計算はできなくなってしまいますし，チェックポイント，> リスタートをするとしてもオーバヘッドが大きくなってしまいます。
てな感じで、せっかく大規模なスパコンを構築しても、信頼性が低いと、大規模な計算には使えないなんてことになってしまうので。
大規模なスパコンのいいところは、大規模な計算にも、あるいは小規模な計算を複数平行して行うのにも使えるところなんですが、前者の利点がなくなり、小規模なスパコンを沢山導入するのと変わらないことになってしまいます。
> てな感じで、せっかく大規模なスパコンを構築しても、信頼性が低いと、大規模な計算には使えないなんて> ことになってしまうので。
一般論としては完全に仰るとおりです。前の書き込みで言いたかったのは「3.3PFで5時間強走ったのなら、1PFあたりのMTBFで比較して倍は違わない可能性はないですかね？」ということでした。
天河2: 3.3PF×５時間強＝17時間京: 1PF×30時間弱=30時間
もっと言うと、スパコンのRASって、CPUだけじゃなくてインターコネクトとか冷却システムとか色々考えなきゃいけないし MTBF/PF が10倍とかならさておき、2倍未満ぐらいの差だとXeon E を使ったことで言うほど差が付いていないんじゃないか、という疑問が私の中に湧いているのです。
# 完全に門外漢なので詳しい人に教えて欲しい
> 天河2: 3.3PF×５時間強＝17時間> 京: 1PF×30時間弱=30時間
数字間違ってませんか？天河2: 30.65[P Flops]×5[時間]×3600[秒]=550 [Exa Flo]京: 8.162[P Flops]×28[時間]×3600[秒]=820 [Exa Flo]では？
数字は http://www.netlib.org/utk/people/JackDongarra/PAPERS/tianhe-2-dongarra... [netlib.org] http://news.mynavi.jp/articles/2011/07/01/kcomputer/ [mynavi.jp] からとりました。
> MTBFで比較して倍は違わない可能性はないですかね？
解ける問題サイズという観点で見ると、(ピーク性能で5.5倍高いはずの天河2よりも)実は京の方が1.5倍大容量ということになるわけで、やっぱりRAS重要と
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
スパコンのプロセッサは自分で作るものではない (スコア:0)
前々からですが、スパコンのプロセッサは自分で作るものではないという感じですね
先端プロセスで専用プロセッサを作る手間とコストを考えたら見合わないし、ウェハー製造を出来るファウンダリも限定されるので．．．．．．．
結局は大量生産のスケールメリットをフルに享受している汎用プロセッサには敵わない
＃残念ながら、いくら富士通が頑張ってもSPARCは先のない負け組
Re: (スコア:1)
スパコンの肝はバンド幅です。
また、巨大な超並列となると宇宙線によるソフトエラーが無視できなくなりますが、
現在のXEON EはRASの実装が限定的です。
ネットワークをシンプルにするにはルータを単純にしてオンチップのI/Oをリッチにする必要があります。
また今後のスパコンは「なるべくデータを動かさない」方向で開発が進んでいると聞いています。
XEONやItaniumが要求を満足しているならそれでも構わないのでしょうが、現状の量産チップでは
超並列を連続して動かせる信頼性に欠けているので、必要に迫られて自分で作ることになります。
ノードごと縮退させるなら現状でもいいのですが、それではいけないと判断してるんでしょう。
ちなみに、富士通のSparc64はOracleでも使っているので、汎用といえば汎用ですね。数はともかく
スパコン以外でも開発費用は回収できています。
Re: (スコア:0)
バンド幅がどれぐらい必要かなんてそんなの完全にアプリ次第だし、
RASの実装が限定的ってそんなに困ることですか？
１６０００ノードで５時間かかるLinpackが走り切るぐらいの信頼性が
あればたいていの科学技術アプリでは問題ないんじゃないですかね。
Re:スパコンのプロセッサは自分で作るものではない (スコア:4, 興味深い)
> RASの実装が限定的ってそんなに困ることですか？
大規模なスパコンだと、割と困りますね。
http://www.geocities.jp/andosprocinfo/wadai13/20130601.htm [geocities.jp]
にありますが、
> TitanもLinpackはGPUメモリだけで実行できる規模で，1時間くらいで終わっていました。
> この理由の一つが，故障発生頻度が高く，マシンが長時間，連続して動かないことであったといわれています。
> Tianhe-1AもMTBFが数時間とか言われていました。ハード規模に逆比例して，Tianhe-2でMTBFが更に
> 短くなると，なかなかフルシステムでは長時間の計算はできなくなってしまいますし，チェックポイント，
> リスタートをするとしてもオーバヘッドが大きくなってしまいます。
てな感じで、せっかく大規模なスパコンを構築しても、信頼性が低いと、大規模な計算には使えないなんて
ことになってしまうので。
大規模なスパコンのいいところは、大規模な計算にも、あるいは小規模な計算を複数平行して行うのにも
使えるところなんですが、前者の利点がなくなり、小規模なスパコンを沢山導入するのと変わらないことに
なってしまいます。
Re: (スコア:0)
> てな感じで、せっかく大規模なスパコンを構築しても、信頼性が低いと、大規模な計算には使えないなんて
> ことになってしまうので。
一般論としては完全に仰るとおりです。前の書き込みで言いたかったのは
「3.3PFで5時間強走ったのなら、1PFあたりのMTBFで比較して倍は違わない可能性はないですかね？」
ということでした。
天河2: 3.3PF×５時間強＝17時間
京: 1PF×30時間弱=30時間
もっと言うと、スパコンのRASって、CPUだけじゃなくてインターコネクトとか冷却システムとか
色々考えなきゃいけないし MTBF/PF が10倍とかならさておき、2倍未満ぐらいの差だと
Xeon E を使ったことで言うほど差が付いていないんじゃないか、という疑問が私の中に
湧いているのです。
# 完全に門外漢なので詳しい人に教えて欲しい
Re: (スコア:0)
> 天河2: 3.3PF×５時間強＝17時間
> 京: 1PF×30時間弱=30時間
数字間違ってませんか？
天河2: 30.65[P Flops]×5[時間]×3600[秒]=550 [Exa Flo]
京: 8.162[P Flops]×28[時間]×3600[秒]=820 [Exa Flo]
では？
数字は
http://www.netlib.org/utk/people/JackDongarra/PAPERS/tianhe-2-dongarra... [netlib.org]
http://news.mynavi.jp/articles/2011/07/01/kcomputer/ [mynavi.jp]
からとりました。
> MTBFで比較して倍は違わない可能性はないですかね？
解ける問題サイズという観点で見ると、(ピーク性能で5.5倍高いはずの天河2よりも)
実は京の方が1.5倍大容量ということになるわけで、やっぱりRAS重要と