アカウント名:
パスワード:
VMの仕様見て言ってくれ。64bit化なんぞやったら、正直ロスのほうが大きいんじゃないかと思うよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
残りの32bit (スコア:3, すばらしい洞察)
Opteron側に使用されたOSはXPの32bit版のようですし、Mac側のPantherにしても、まだ64bitに最適化されていない筈です。比較に使用されたソフトウェアも、Mac用PhotoshopのG5プラグイン以外は64bitに最適化された物はなさそうです。これ
Re:残りの32bit (スコア:1)
そもそも今のアプリで64bit整数演算を使ってたかと。4GB越えメモリアクセスについても、そりゃ、36bitセグメントとか、ディスクにスワップしてたのがオンメモリでとなると速くなるわけだけど、そんなにメモリを食うソフトって何って事になってくるし。
ところで、SSEとか3DNow!とか使うと、128bitに最適化って言っても好いんですかネ?
Re:残りの32bit (スコア:2, 興味深い)
バイトアライメントが取れている前提であれば、今は物理的なデータバスが64bit以上
あるのが普通なので、8/16/32/64のどれでも実質的にはほとんど変わらないと思います。
(厳密にいうと、巨視的には主記憶とキャッシュの間の転送量が増える分だけ性能に影響
するかもしれませんが、どちらのCPUもキャッシュがかなり大きいので、これも誤差範囲の
ような気がします。)
> ところで、SSEとか3DNow!とか使うと、128bitに最適化って言っても好いんですかネ?
PC等では、SSE/3DNow!命令対応、とかって言っているような気がしますが、
DreamCast(SH4)なんかはそういっているような気がしますね(^_^;;
ちなみに、一般的なグラフィック処理の性能改善には、むしろ
メモリのレイテンシーに最適化、の方が影響あるんじゃないかと思いますが(^_^;;
# G5の性能って、FSBクロックの高さに由来するところも多いと思います。
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アプリの性能比」の話と「メモリ速度が実行速度全体に
与える影響」は、少しレベルの違う話だと思いますが。
Re:残りの32bit (スコア:1)
AltiVec(Velocity Engine)も加えてやってください。
Re:残りの32bit (スコア:1)
Javaのlong型は64bit整数なので、JVMがちゃんと対応すればlongを多用するJavaアプリには恩恵があるかも。
Re:残りの32bit (スコア:1)
VMの仕様見て言ってくれ。64bit化なんぞやったら、正直ロスのほうが大きいんじゃないかと思うよ。