アカウント名:
パスワード:
確かにプロセススィッチングに伴うレジスタ周りの取り扱いやキャッシュ制御, MMUの設計あたりが効いてきそうですよね.
今みたいにプリエンプティブなOS環境が標準的になってくると, 一般的なアプリケーションベンチマークでさえ, かってのDhrystoneなみに非現実的なものになっちゃって, いかに現実的な動作環境に近づけるかというのがキモになりそうですね.
あえて言う。ページ単位でキャッシュのフラッシュもTLBのフラッシュもできないCPUはカスであると。
# シャンパンなのでAC
それって Powe(ずきゅーん
# AC
VMの仕様見て言ってくれ。64bit化なんぞやったら、正直ロスのほうが大きいんじゃないかと思うよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
残りの32bit (スコア:3, すばらしい洞察)
Opteron側に使用されたOSはXPの32bit版のようですし、Mac側のPantherにしても、まだ64bitに最適化されていない筈です。比較に使用されたソフトウェアも、Mac用PhotoshopのG5プラグイン以外は64bitに最適化された物はなさそうです。これも、公正を期する比較という事ならば、おそらく使われていないと思いたい所です。
つまりどちらにも言える事ですが、将来64bit環境が整えられた時、この数値はさらに上がる訳で、この結果もひっくり返るかもしれない訳で…。
とっても楽しみですね。(棒読み)
64bitに最適化 (スコア:3, 興味深い)
8bit→16bitや、
16bit→32bitのときのような事は無いとおもいますよ、ええ
扱えるメモリ空間が広くなることや、扱える数値の桁数が増えることが、
即処理効率UPにつながらないような処理には、あまり意味がないと思いますけど。
以前から、クロックあたりの速度はPPCのほうが速いと言われていましたが、
そのクロック自体が大幅に差をつけられていたので、それは意味を成さなかったわけですが、
やっと周回遅れから挽回できたので、こういうベンチを見られるようになったわけですね。
#弟のXPマシンは私のMacの倍近いクロックスピードだが私のMacより明らかに遅かった。
その原因は…バックグラウンドで動作するアンチウイルスとファイアウォールだった。
最適化とは別に...(Re:64bitに最適化) (スコア:2, 興味深い)
実利用環境上で、こういったソフトウェアが必須であれば、
こういったものを踏まえた速度比較が必要かもしれないね。
ウィルスやら攻撃への耐性とかも踏まえて、実際に使う場合の
(同じ程度の安定性/安全性を前提にするための)資源を
踏まえた「速さ」の目安ってのが必要かもね。
Re:最適化とは別に...(Re:64bitに最適化) (スコア:1)
確かにプロセススィッチングに伴うレジスタ周りの取り扱いやキャッシュ制御, MMUの設計あたりが効いてきそうですよね.
今みたいにプリエンプティブなOS環境が標準的になってくると, 一般的なアプリケーションベンチマークでさえ, かってのDhrystoneなみに非現実的なものになっちゃって, いかに現実的な動作環境に近づけるかというのがキモになりそうですね.
Re:最適化とは別に...(Re:64bitに最適化) (スコア:0)
あえて言う。ページ単位でキャッシュのフラッシュもTLBのフラッシュもできないCPUはカスであると。
# シャンパンなのでAC
Re:最適化とは別に...(Re:64bitに最適化) (スコア:0)
それって Powe(ずきゅーん
# AC
Re:64bitに最適化 (スコア:1)
Re:64bitに最適化 (スコア:0)
> その原因は…バックグラウンドで動作するアンチウイルスとファイアウォールだった。
よけいな一言だよなー また、アンチ君たちが喜ぶ
Re:64bitに最適化 (スコア:0)
#Macの隣にWin機をセットアップし終わったところなのでAC
Re:残りの32bit (スコア:2, すばらしい洞察)
# AMD にその辺て期待できるのかしら?
Re:残りの32bit (スコア:1)
利用出来るメモリ空間は4GBのままだし。あくまで32bitのままG5向けで
若干の最適化がされただけです。本当に最適化して高速化をはかるなら、
やはりソフト全体の見直しが必要になるでしょう。
CS (スコア:1)
Re:CS (スコア:1)
32bit APIのままですから、Mac OS Xでいつ64bit APIが導入されるか
どうかで次のバージョンがどうなるかが決まるでしょう。
同じくOpteronに最適化する為にはWindowsが64bit化した上でAPIも
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化なんぞやったら、正直ロスのほうが大きいんじゃないかと思うよ。
Re:残りの32bit (スコア:0)
>この数値はさらに上がる訳で、この結果もひっくり返るかもしれない訳で…。
上がるとは限らんだろ。
Re:残りの32bit (スコア:0)
Re:残りの32bit (スコア:0)
"64bitに最適化" というのがそもそものカンチガイ。
Re:残りの32bit (スコア:0)
CPUの性能比較ならOpteronはLinuxを使えば良かったのに。
IA64をサポートしてるディストリはあるし。
最新CPUに搭載したWindowsとMacの性能比較ということなら別だけど。
Re:残りの32bit (スコア:0)
Re:残りの32bit (スコア:0)
OpteronはAMD64でわ