アカウント名:
パスワード:
確かにプロセススィッチングに伴うレジスタ周りの取り扱いやキャッシュ制御, MMUの設計あたりが効いてきそうですよね.
今みたいにプリエンプティブなOS環境が標準的になってくると, 一般的なアプリケーションベンチマークでさえ, かってのDhrystoneなみに非現実的なものになっちゃって, いかに現実的な動作環境に近づけるかというのがキモになりそうですね.
あえて言う。ページ単位でキャッシュのフラッシュもTLBのフラッシュもできないCPUはカスであると。
# シャンパンなのでAC
それって Powe(ずきゅーん
# AC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
残りの32bit (スコア:3, すばらしい洞察)
Opteron側に使用されたOSはXPの32bit版のようですし、Mac側のPantherにしても、まだ64bitに最適化されていない筈です。比較に使用されたソフトウェアも、Mac用PhotoshopのG5プラグイン以外は64bitに最適化された物はなさそうです。これ
64bitに最適化 (スコア:3, 興味深い)
8bit→16bitや、
16bit→32bitのときのような事は無いとおもいますよ、ええ
扱えるメモリ空間が広くなることや、扱える数値の桁数が増えることが、
即処理効率UPにつながらないような処理には、あまり意味がないと思いますけど。
以前から、クロックあたりの速度はPPCのほうが速いと言われていましたが、
そのクロック自体が大幅に差をつけられていたので、それは
最適化とは別に...(Re:64bitに最適化) (スコア:2, 興味深い)
実利用環境上で、こういったソフトウェアが必須であれば、
こういったものを踏まえた速度比較が必要かもしれないね。
ウィルスやら攻撃への耐性とかも踏まえて、実際に使う場合の
(同じ程度の安定性/安全性を前提にするための)資源を
踏まえた「速さ」の目安ってのが必要かもね。
Re:最適化とは別に...(Re:64bitに最適化) (スコア:1)
確かにプロセススィッチングに伴うレジスタ周りの取り扱いやキャッシュ制御, MMUの設計あたりが効いてきそうですよね.
今みたいにプリエンプティブなOS環境が標準的になってくると, 一般的なアプリケーションベンチマークでさえ, かってのDhrystoneなみに非現実的なものになっちゃって, いかに現実的な動作環境に近づけるかというのがキモになりそうですね.
Re:最適化とは別に...(Re:64bitに最適化) (スコア:0)
あえて言う。ページ単位でキャッシュのフラッシュもTLBのフラッシュもできないCPUはカスであると。
# シャンパンなのでAC
Re:最適化とは別に...(Re:64bitに最適化) (スコア:0)
それって Powe(ずきゅーん
# AC