- 【スパコン】スーパーコンピュータ関連情報5【HPC】
357 ：不明なデバイスさん[sage]：2010/02/21(日) 01:20:29 ID:ox6SzNCS - 加算命令の実行のコストのうち、加算それ自体はゼロに等しいのに、その速度の話をするのはナンセンスだと思う。
どんなにALUが短い遅延で出力を出したとしても、それを受け取る側が追い付かない。
|
- 【スパコン】スーパーコンピュータ関連情報5【HPC】
360 ：不明なデバイスさん[sage]：2010/02/21(日) 04:19:48 ID:ox6SzNCS - >>359
現実のコードを分析した上で、ALUがボトルネックだと言うのか?
ボトルネックでもないものの性能を上げるのはナンセンスだよ。
加算の処理の半分以上はアドレス計算で、
それはALUではなくロードストアユニットでやったほうがいい。
なぜなら、加算の結果を使うのはロードストアユニットで、
結果をレジスタに格納する必要はないのだから。
|
- 【スパコン】スーパーコンピュータ関連情報5【HPC】
362 ：不明なデバイスさん[sage]：2010/02/21(日) 07:03:28 ID:ox6SzNCS - ↑そのandoさんの
> L1DTLBに8KBと16KBのラージページを追加したとなっていますが，
> ここは普通Full Associative構造にしてMBクラスのページもサポートする
> というのが一般的な設計で，何をいまさらという感じです。
これ、どういう意味?
ttp://download.intel.com/jp/developer/jpdoc/25110901_j.pdf
には
> 1 次DTLB は32 エントリのフル・アソシアティブ・バッファである。
> 1 次DTLB は4KB ページをサポートし、より大きなキャッシュも4KB サブセクション単位でサポートする。
> 2 次DTLB (DTLB2) は、ストア操作のデータ・メモリ参照の仮想アドレスから物理アドレスへの変換と、
> ロード操作の保護チェックを処理する。2 次DTLB は、128 エントリのフル・アソシアティブ・バッファで、
> 4KB 〜 4GB のページ・サイズをサポートする。
とあって、すでにフルアソシエイティブなのよ。
L2DTLBだけでなくL1DTLBでもサブセクションにせず、そのままMBとかGBのページをサポートしろってことかな。
|
- 【スパコン】スーパーコンピュータ関連情報5【HPC】
364 ：不明なデバイスさん[sage]：2010/02/21(日) 09:20:28 ID:ox6SzNCS - >>363
勘違いだよ。
ALU自体はもっと速く動くはずだが、他に足を引っ張られてクロックが上げられない
という話の前提には、当然、
ALUがボトルネックである
というのがあってしかるべきだよ。
ALUがボトルネックでもないのに、ALUを速くしてもしょーがないもの。
|
- 【スパコン】スーパーコンピュータ関連情報5【HPC】
368 ：不明なデバイスさん[sage]：2010/02/21(日) 10:57:12 ID:ox6SzNCS - >>365
従来がショボいというのが、わからない。
たとえば16KBページの場合、
L2DTLBは16KBページサポートで128エントリ
L1DTLBは16KBを4分割した4KBに対して32エントリ
とくに性能低下に繋がるようには思えないんだわ。
もしかして、L1DTLBがカバーできるメモリが、
ページサイズによらず常に4KB×32=128KBなのはショボいということなのかな。
L1D$が16KBと小さいので、128KBでも十分だと思うんだけど。
|
- 【スパコン】スーパーコンピュータ関連情報5【HPC】
369 ：不明なデバイスさん[sage]：2010/02/21(日) 10:58:26 ID:ox6SzNCS - >>367
違うらしい。
話の発端になった人が言うには、ALUはもっと高いクロックで動くのに、他の部分が遅いから、ALUの本来の性能がスポイルされてるんだってさ。
|