アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
残りの32bit (スコア:3, すばらしい洞察)
Opteron側に使用されたOSはXPの32bit版のようですし、Mac側のPantherにしても、まだ64bitに最適化されていない筈です。比較に使用されたソフトウェアも、Mac用PhotoshopのG5プラグイン以外は64bitに最適化された物はなさそうです。これ
Re:残りの32bit (スコア:1)
そもそも今のアプリで64bit整数演算を使ってたかと。4GB越えメモリアクセスについても、そりゃ、36bitセグメントとか、ディス
Re:残りの32bit (スコア:2, 興味深い)
バイトアライメントが取れている前提であれば、今は物理的なデータバスが64bit以上
あるのが普通なので、8/16/32/64のどれでも実質的にはほとんど変わらないと思います。
(厳密にいうと、巨視的には主記憶とキャッシュの間の転送量が増える分だけ性能に影響
するかもしれませんが、どちらのCPUもキャッシュがかなり大きいので、これも誤差範囲の
ような気がします。)
> ところで、SSEとか3DNow!とか使うと、128bitに最
Re:残りの32bit (スコア:1)
「G5はメモリ=キャッシュ間を高速化したから高性能」
えー。これって両方いっぺんに主張してもらっても困るなぁ。
http://pcweb.mycom.co.jp/benchmarklab/2002/09/page2.html
それに、現状でメモリだけ高速化してもそれなりに効果がある、ってことは、キャッシュが大きくても隠蔽しきれず、誤差範囲以上に性能は低下するって事でしょ。
標準変数が32bitから64bitになると、メモリ=キャッシュ間の速度が幾らか低下したのと同じ事になるわけだから、まあ20%~30%膨らむとして、さっきのグラフを見れば、200:200と266:266のときで、5%程度低下することになりますよね(キャッシュ効率が低下するのは含まないとして)
Re:残りの32bit (スコア:1)
> 「G5はメモリ=キャッシュ間を高速化したから高性能」
> えー。これって両方いっぺんに主張してもらっても困るなぁ。
セットで主張しているわけでもないし、上記2点についてはアプリケーションに
依存する所が大きいから断定せずに書いているのですが。
そもそも、ここで問題にしているのは、「どーでもいいような変数やポインタ」への
アクセス速度の問題ですよね。
元々の、「32bitアプリと64bitアプリの性能比」の話と「メモリ速度が実行速度全体に
与える影響」は、少しレベルの違う話だと思いますが。