アカウント名:
パスワード:
> 現在の京に使われているプロセッサ(富士通のSPARC64)の能力拡張版を採用するのか、> それともアーキテクチャを一新するのかはまだ不明だが、
現在のHPCのトレンドに従えば、SIMD命令を持つ汎用CPUと、GPGPUのようなアクセラレータの組み合わせで行くのはまあ自明でしょう。http://www.mext.go.jp/b_menu/shingi/chousa/shinkou/028/shiryo/__icsFil... [mext.go.jp]といった公開資料見ても、そんな感じです。国の予算使うので、国産技術優先になるわけで、・汎用コア (富士通 SPARC64 系、京の後継ですね)・演算加速コア(アクセラレータ、Grape系の可能性大? GPGPUの可能性も残ってる?)でまあ決まりではないかと。
…と思ってたんですが、twitterかなにかで、メモリバンド幅重視(ベクトルスパコン、要はNECのSXの後継機)の目も残っていて、3種類の混成構成になるみたいな話を目にしてびっくりしました。でも今探してみるとソースを再発見できないので幻だった…?
ベクトルスパコンはHPC界ではさすがにもう終わった感じだし、NECは京の時に途中撤退やってるので、もうないか…と思ってたんですが。まだなんか目があるんですかね?
> 周知のように、京が完成するまでのプロセスはけっして平坦なものではなかった。開発プロジェクトからNECと> 日立製作所が脱退したために、当初の目標の一つだった複合構成が成らなかったのである。
当初の検討段階では、京の世代も、汎用/演算加速/ベクトルの3種複合構成のはずだったんですが、ベクトルのNECが脱退して、富士通のところに予算が集中したのは、結果的には成功だったと思います。事業仕分けについても、結果的にはプラスに働いたと評価する関係者もいますね。https://twitter.com/Prof_hrk/status/447933713897103360 [twitter.com]
あと、演算加速コアに相当するものが、京の世代の計画から消えたのは日立の撤退とは関係ないと思います。http://jun-makino.sakura.ne.jp/articles/future_sc/note114.html [sakura.ne.jp]https://twitter.com/jun_makino/status/447079046627606529/photo/1 [twitter.com]にあるように、政治的に潰されたというのが真相っぽいです。演算加速コアを提案していた側は、この2012年になるまで、理由を知らされてなかったようですね。
ご存知の通り、演算加速コアに相当するものは、GPGPUという形で世界で主流になってますので、計画から外したのは、理研側の判断ミスだったと言ってよいかと思います。まあ上記の牧野先生は、4月から理研で、エクサのプロジェクトの副プロジェクトリーダーをされるようですから、理研の方も失敗だったという反省はしていて、今度はちゃんとやるんじゃないかと思ってますが。
関連ストーリーにあるSX-ACE発売の記事 [srad.jp]によると、NECも研究は続けているようなので、芽はないことはない……かなあ。
事業仕分けのメンバーには円周率計算の第一人者もいたそうで、単なるパフォーマンス集団ではなかったはずです。
GPGPUはベクトル演算器ですよ。
問題は、LINPACKでいくらピーク出しても、RUN中の大半のプログラムは理論性能の1%も出せていないってこと。
メモリバンド幅云々ってのは、大部分のプログラムにおける性能のボトルネックがメモリ/キャッシュからのデータ転送待ちであることなんです。
ぶっちゃけ、ピーク性能1000倍より、メモリバンド幅100倍の方がはるかにメリット大きい人たちの方が多いよ。
> GPGPUはベクトル演算器ですよ。
これはある意味確かにその通りなんですが、伝統的ベクトルスパコンは、比較的少ない演算器と比較的大きいメモリバンド幅という制約下で、少ない演算器に効率的にデータを供給するというところから出発しているわけです。GPGPUの場合、演算器は山ほどあるけど、メモリバンド幅は(同一世代のアーキテクチャでの比較では広めなものの、昔と比べると)少なめという制約下での解なわけで、単純にベクトルマシンとGPGPUを同じと言ってしまうのは難があるような。
GPGPUとGrape系だと、メモリバンド幅要求がまったく違うわけで、これをごっちゃにして単に演算加速コアとして括るのは問題だ…という指摘なら分かります。ただ、これは引用した政府公開の資料がそうなってるので…というのが言い訳です。
> ぶっちゃけ、ピーク性能1000倍より、メモリバンド幅100倍の方がはるかに> メリット大きい人たちの方が多いよ。
ここは100%同意です。エクサの世代だと、演算器と同一パッケージにメモリを積むことにより、圧倒的なメモリバンド幅を達成できるようになるわけで、バンド幅FLOPS比が一律に低下してきたこれまでのトレンドとはちょっと違う流れですね。これは少なくともGPGPUには追い風です。で、この追い風が旧来のベクトルスパコンにも働くのかというのが疑問点だったりします。
あれ、> 問題は、LINPACKでいくらピーク出しても、RUN中の大半のプログラムは以降のところ、間違えてコピペしたところが残ったままでした。失礼しました。
解きたい問題の解法がスケールしないのなら、巨大な計算機でなければ解くことは不可能だしスケールするのなら、巨大な計算機を非常に効率よく利用することができます
どのみちでかいのが必要ってこと単にメモリがたくさん使えるということだけでもありがたい
ちょっとニュアンス違うと思いますよ。
>>解きたい問題がスケールできないなら、クラスタなど巨大なマシンで計算することは無理。GPGPUも同じ。>>スケールするなら、効率よく実行できる。
これが正しい。
素人くさい意見でほほえましいのですが、実際のところは
たとえばプロセッサ台数nに対してn^(1/2)の速度向上しか得られないなら、巨大なマシンで強引に解く必要があります小さなマシンをいくら集めても解けませんつまり、京のような巨大なマシンがあるなら他の研究者ができないことができます
GPGPUは故障率の問題がありますので天河のような巨大なシステムでは効率がガタ落ちしていますつまり、京のような故障率の低いマシンがあるなら他の研究者より効率よく研究ができます
http://www.geocities.jp/andosprocinfo/wadai14/20140322.htm [geocities.jp]によると東北大からの発表がないそうで何もわかりませんが、例えばSX-ACEだとCPUあたり64GBとうちのパソコン並みの容量ですので、とうてい大容量という気がしませんね
共有メモリマシン、それもCray MTAみたいなのがあると喜ぶ人がいるかもしれません
> http://www.geocities.jp/andosprocinfo/wadai14/20140322.htm [geocities.jp]> によると東北大からの発表がないそうで何もわかりませんが、
あああ、「今探してみるとソースを再発見できない」と書いたソースは、このandoさんのところでした。ありがとうございます。
エクサスケール・スパコン開発と言っても、理研は仕様と発注伝票を買うぐらいで、実態は富士通等のコンピューターメーカーが開発するのでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
エクサのシステム構成 (スコア:3, 興味深い)
> 現在の京に使われているプロセッサ(富士通のSPARC64)の能力拡張版を採用するのか、
> それともアーキテクチャを一新するのかはまだ不明だが、
現在のHPCのトレンドに従えば、SIMD命令を持つ汎用CPUと、GPGPUのようなアクセラレータの
組み合わせで行くのはまあ自明でしょう。
http://www.mext.go.jp/b_menu/shingi/chousa/shinkou/028/shiryo/__icsFil... [mext.go.jp]
といった公開資料見ても、そんな感じです。国の予算使うので、国産技術優先になるわけで、
・汎用コア (富士通 SPARC64 系、京の後継ですね)
・演算加速コア(アクセラレータ、Grape系の可能性大? GPGPUの可能性も残ってる?)
でまあ決まりではないかと。
…と思ってたんですが、twitterかなにかで、メモリバンド幅重視(ベクトルスパコン、要はNECのSXの後継機)の
目も残っていて、3種類の混成構成になるみたいな話を目にしてびっくりしました。
でも今探してみるとソースを再発見できないので幻だった…?
ベクトルスパコンはHPC界ではさすがにもう終わった感じだし、NECは京の時に途中撤退やってるので、
もうないか…と思ってたんですが。まだなんか目があるんですかね?
> 周知のように、京が完成するまでのプロセスはけっして平坦なものではなかった。開発プロジェクトからNECと
> 日立製作所が脱退したために、当初の目標の一つだった複合構成が成らなかったのである。
当初の検討段階では、京の世代も、汎用/演算加速/ベクトルの3種複合構成のはずだったんですが、
ベクトルのNECが脱退して、富士通のところに予算が集中したのは、結果的には成功だったと思います。
事業仕分けについても、結果的にはプラスに働いたと評価する関係者もいますね。
https://twitter.com/Prof_hrk/status/447933713897103360 [twitter.com]
あと、演算加速コアに相当するものが、京の世代の計画から消えたのは日立の撤退とは関係ないと思います。
http://jun-makino.sakura.ne.jp/articles/future_sc/note114.html [sakura.ne.jp]
https://twitter.com/jun_makino/status/447079046627606529/photo/1 [twitter.com]
にあるように、政治的に潰されたというのが真相っぽいです。
演算加速コアを提案していた側は、この2012年になるまで、理由を知らされてなかったようですね。
ご存知の通り、演算加速コアに相当するものは、GPGPUという形で世界で主流になってますので、
計画から外したのは、理研側の判断ミスだったと言ってよいかと思います。
まあ上記の牧野先生は、4月から理研で、エクサのプロジェクトの副プロジェクトリーダーをされる
ようですから、理研の方も失敗だったという反省はしていて、今度はちゃんとやるんじゃないかと
思ってますが。
Re:エクサのシステム構成 (スコア:1)
関連ストーリーにあるSX-ACE発売の記事 [srad.jp]によると、NECも研究は続けているようなので、芽はないことはない……かなあ。
Re:エクサのシステム構成 (スコア:1)
事業仕分けのメンバーには円周率計算の第一人者も
いたそうで、単なるパフォーマンス集団ではなかった
はずです。
Re: (スコア:0)
GPGPUはベクトル演算器ですよ。
問題は、LINPACKでいくらピーク出しても、RUN中の大半のプログラムは
理論性能の1%も出せていないってこと。
メモリバンド幅云々ってのは、大部分のプログラムにおける性能のボトルネックが
メモリ/キャッシュからのデータ転送待ちであることなんです。
ぶっちゃけ、ピーク性能1000倍より、メモリバンド幅100倍の方がはるかに
メリット大きい人たちの方が多いよ。
Re:エクサのシステム構成 (スコア:4, 興味深い)
> GPGPUはベクトル演算器ですよ。
これはある意味確かにその通りなんですが、伝統的ベクトルスパコンは、比較的少ない演算器と
比較的大きいメモリバンド幅という制約下で、少ない演算器に効率的にデータを供給するという
ところから出発しているわけです。
GPGPUの場合、演算器は山ほどあるけど、メモリバンド幅は(同一世代のアーキテクチャでの
比較では広めなものの、昔と比べると)少なめという制約下での解なわけで、単純にベクトル
マシンとGPGPUを同じと言ってしまうのは難があるような。
GPGPUとGrape系だと、メモリバンド幅要求がまったく違うわけで、これをごっちゃにして
単に演算加速コアとして括るのは問題だ…という指摘なら分かります。
ただ、これは引用した政府公開の資料がそうなってるので…というのが言い訳です。
> ぶっちゃけ、ピーク性能1000倍より、メモリバンド幅100倍の方がはるかに
> メリット大きい人たちの方が多いよ。
ここは100%同意です。
エクサの世代だと、演算器と同一パッケージにメモリを積むことにより、圧倒的なメモリ
バンド幅を達成できるようになるわけで、バンド幅FLOPS比が一律に低下してきた
これまでのトレンドとはちょっと違う流れですね。
これは少なくともGPGPUには追い風です。
で、この追い風が旧来のベクトルスパコンにも働くのかというのが疑問点だったりします。
問題は、LINPACKでいくらピーク出しても、RUN中の大半のプログラムは
理論性能の1%も出せていないってこと。
メモリバンド幅云々ってのは、大部分のプログラムにおける性能のボトルネックが
メモリ/キャッシュからのデータ転送待ちであることなんです。
ぶっちゃけ、ピーク性能1000倍より、メモリバンド幅100倍の方がはるかに
メリット大きい人たちの方が多いよ。
Re: (スコア:0)
あれ、
> 問題は、LINPACKでいくらピーク出しても、RUN中の大半のプログラムは
以降のところ、間違えてコピペしたところが残ったままでした。
失礼しました。
Re: (スコア:0)
解きたい問題の解法がスケールしないのなら、巨大な計算機でなければ解くことは不可能だし
スケールするのなら、巨大な計算機を非常に効率よく利用することができます
どのみちでかいのが必要ってこと
単にメモリがたくさん使えるということだけでもありがたい
Re: (スコア:0)
ちょっとニュアンス違うと思いますよ。
>>解きたい問題がスケールできないなら、クラスタなど巨大なマシンで計算することは無理。GPGPUも同じ。
>>スケールするなら、効率よく実行できる。
これが正しい。
Re: (スコア:0)
素人くさい意見でほほえましいのですが、実際のところは
たとえばプロセッサ台数nに対してn^(1/2)の速度向上しか得られないなら、巨大なマシンで強引に解く必要があります
小さなマシンをいくら集めても解けません
つまり、京のような巨大なマシンがあるなら他の研究者ができないことができます
GPGPUは故障率の問題がありますので天河のような巨大なシステムでは効率がガタ落ちしています
つまり、京のような故障率の低いマシンがあるなら他の研究者より効率よく研究ができます
Re: (スコア:0)
http://www.geocities.jp/andosprocinfo/wadai14/20140322.htm [geocities.jp]
によると東北大からの発表がないそうで何もわかりませんが、
例えばSX-ACEだとCPUあたり64GBとうちのパソコン並みの容量ですので、とうてい大容量という気がしませんね
共有メモリマシン、それもCray MTAみたいなのがあると喜ぶ人がいるかもしれません
Re: (スコア:0)
> http://www.geocities.jp/andosprocinfo/wadai14/20140322.htm [geocities.jp]
> によると東北大からの発表がないそうで何もわかりませんが、
あああ、「今探してみるとソースを再発見できない」と書いたソースは、このandoさんのところでした。
ありがとうございます。
Re: (スコア:0)
エクサスケール・スパコン開発と言っても、理研は仕様と発注伝票を買うぐらいで、実態は富士通等のコンピューターメーカーが開発するのでしょう。