アカウント名:
パスワード:
> 現在の京に使われているプロセッサ(富士通のSPARC64)の能力拡張版を採用するのか、> それともアーキテクチャを一新するのかはまだ不明だが、
現在のHPCのトレンドに従えば、SIMD命令を持つ汎用CPUと、GPGPUのようなアクセラレータの組み合わせで行くのはまあ自明でしょう。 http://www.mext.go.jp/b_menu/shingi/chousa/shinkou/028/shiryo/__icsFil... [mext.go.jp] といった公開資料見ても、そんな感じです。国の予算使うので、国産技術優先になるわけで、・汎用コア (富士通 SPARC64 系、京の後継ですね)・演算加速コア(アクセラレータ、Grape系の可能性大? GPGPUの可能性も残って
GPGPUはベクトル演算器ですよ。
問題は、LINPACKでいくらピーク出しても、RUN中の大半のプログラムは理論性能の1%も出せていないってこと。
メモリバンド幅云々ってのは、大部分のプログラムにおける性能のボトルネックがメモリ/キャッシュからのデータ転送待ちであることなんです。
ぶっちゃけ、ピーク性能1000倍より、メモリバンド幅100倍の方がはるかにメリット大きい人たちの方が多いよ。
> GPGPUはベクトル演算器ですよ。
これはある意味確かにその通りなんですが、伝統的ベクトルスパコンは、比較的少ない演算器と比較的大きいメモリバンド幅という制約下で、少ない演算器に効率的にデータを供給するというところから出発しているわけです。GPGPUの場合、演算器は山ほどあるけど、メモリバンド幅は(同一世代のアーキテクチャでの比較では広めなものの、昔と比べると)少なめという制約下での解なわけで、単純にベクトルマシンとGPGPUを同じと言ってしまうのは難があるような。
GPGPUとGrape系だと、メモリバンド幅要求がまったく違うわけで、これをごっちゃにして単に演算加速コアとして括るのは問題だ…という指摘なら分かります。ただ、これは引用した政府公開の資料がそうなってるので…というのが言い訳です。
> ぶっちゃけ、ピーク性能1000倍より、メモリバンド幅100倍の方がはるかに> メリット大きい人たちの方が多いよ。
ここは100%同意です。エクサの世代だと、演算器と同一パッケージにメモリを積むことにより、圧倒的なメモリバンド幅を達成できるようになるわけで、バンド幅FLOPS比が一律に低下してきたこれまでのトレンドとはちょっと違う流れですね。これは少なくともGPGPUには追い風です。で、この追い風が旧来のベクトルスパコンにも働くのかというのが疑問点だったりします。
あれ、> 問題は、LINPACKでいくらピーク出しても、RUN中の大半のプログラムは以降のところ、間違えてコピペしたところが残ったままでした。失礼しました。
より多くのコメントがこの議論にあるかもしれませんが、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の可能性も残って
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中の大半のプログラムは
以降のところ、間違えてコピペしたところが残ったままでした。
失礼しました。