> An update is a read-modify-write operation on a table of 64-bit words. An address is generated, the value at that address read from memory, modified by an integer operation (add, and, or, xor) with a literal value, and that new value is written back to memory.
> For the purpose of measuring GUPS, we will stipulate that each thread is permitted to look ahead no more than 1024 random address stream samples with the same number of update messages stored before processing.
進歩の方向性を見る (スコア:3, 参考になる)
スパコンの開発・購入の指針として見るには物足りない。
Linpackを使ってベンチマーク競争に参加しているスパコンは基本的にクラスタ構成を取るのだから、
HPCチャレンジベンチマークの様に部分の性能の向上程度も合わせて見る様にすれば、
・総合評価が台数を多くしただけの単なる力技なのか、
・それとも個別の部分の性能向上に寄与するものなのか、
・それともそれ以外の要素が大きいのか
が分かりやすくなる。
結果として、それは他の開発者へのモチベーション向上にもつながるだろうし、
スパコンを買おうとするユーザに対しても有効な情報となりえる。
実際
Re: (スコア:1)
・総合評価が台数を多くしただけの単なる力技なのか、
台数が多いにしても、トップを取るのは大変です。ライバルより上でないといけないし実用的に使う上では個数が多い故のMTBF問題もあります。
余談：HPC Challenge のEP-xxベンチマークがこれに相当する訳ですが(Embarrassingly Parallel:恥ずかしくなるほど並列)というネーミングがぐっときました。
・それとも個別の部分の性能向上に寄与するものなのか、
・それともそれ以外の要素が大きいのか
少し古い話なのですが、SC05 - スパコンもう一つのベンチマーク「HPC Challenge」 - BlueGene/Lが圧勝 [mycom.co.jp]にG-RandomAccess（システム全体のメモリ領域
Re:進歩の方向性を見る (スコア:3, 参考になる)
安藤さんときどき変なこと言うし。
G-RandomAccessの詳細は
http://icl.cs.utk.edu/projectsfiles/hpcc/RandomAccess/
なんですけど、これはむしろメッセージ通信型に有利そうですね。特にBG/Lはネットワークはオーバーヘッド・レイテンシ・バンド幅と意外と高性能。
> An update is a read-modify-write operation on a table of 64-bit words. An address is generated, the value at that address read from memory, modified by an integer operation (add, and, or, xor) with a literal value, and that new value is written back to memory.
なので、ナイーブにローカルPE(=アドレスジェネレータ)までデータをフェッチする必要はなく、リモートPEに"read modify write"メッセージを送ればよいし、
> For the purpose of measuring GUPS, we will stipulate that each thread is permitted to look ahead no more than 1024 random address stream samples with the same number of update messages stored before processing.
1024リクエストをバッファできるなら、そこそこパイプライン化できるでしお。