- ウィンドウズ７ あ〜あ 32/64bit版買っちゃった12
461 ：名無し~3.EXE[sage]：2011/04/15(金) 21:14:15.88 ID:vzDJG8Sq - >>456
64bitの方がキャッシュが多い ===> 事実
64bitモードの方がレジスタが多い ===> 事実
ドライバは64bitコード ===> 事実
64bitコードはXMMレジスタが気軽に使える ===> 事実
でどの辺が嘘だと思う？
通常は、
32bitコード同士で同等もしくは微妙に64bitコードの方が速い
ネイティブ同士では同等〜数割64bitコードの方が速い
>>457
ポインタのサイズは倍になる。
コードサイズは大きくなる要素も小さくなる要素もあるが、通常は微妙に増える。
64bitデータのロードが32bitデータのロードと比べて時間がかかる場合もある。
欠点は欠点として認めないと。
だがしかし、64bitコードの場合それらの欠点よりも
レジスタ数が倍になる利点と、SSE2までの命令が実装されていること前提で組めるという利点
の方がはるかに大きい。
>>459
> メモリアクセス多用するアプリで下手にコーディングすると
メモリアクセス多用すると遅くなるってのがわからん。
メモリアクセス多用すれば32bitだろうが64bitだろうが遅くなる。
|
- ウィンドウズ７ あ〜あ 32/64bit版買っちゃった12
463 ：名無し~3.EXE[sage]：2011/04/15(金) 22:19:47.59 ID:vzDJG8Sq - >>462
そういうすごく小さいループだけじゃ全然参考にならない。
たまたま大差がついちゃうこともあるし。
エラトステネスはわりと最近アセンブラで組んだような。
奇数のみ1個の数値1ビットで保持。
処理のほとんどがほんの少しのレジスタとビットセット命令によるメモリアクセスの非常に小さなループ。
4コアHTによる8個のスレッドを使って結構大きな数まで求めた気がする。
メモリ確保できるだけ確保してからふるいにかけるより、
ある程度小さな単位に分けてふるいにかけた方が速かった気がする。
（2次3次キャッシュのおかげ）
多分この処理だと32bitも64bitも速度は同じと思う。
同じデータ構造で同じ命令を使うので。
|
- ウィンドウズ７ あ〜あ 32/64bit版買っちゃった12
465 ：名無し~3.EXE[sage]：2011/04/15(金) 23:25:25.87 ID:vzDJG8Sq - >>464
そりゃアラインメントのずれた64bitデータへのアクセスは遅いが、
32bitアプリだと32bitで64bitアプリだと64bitのデータなんか普通はポインタくらい。
多くの場合は勝手に64bitアラインメントになるし。
APIの呼び出しも型が異なるものもあるけど、
普通はレジスタ経由でパラメータを渡す利点の方が大きい。
> ただ昔のゲームとかフリーツールだとか、正式に対応してないけど
> 動作するからってソフトは、体感で申し訳ないが32ビットの方が
> 速いのもあった気がするんで。
申し訳ないが気のせいだと思う。
|
- ウィンドウズ７ あ〜あ 32/64bit版買っちゃった12
466 ：名無し~3.EXE[sage]：2011/04/15(金) 23:30:22.63 ID:vzDJG8Sq - 繰り返すがCPU負荷の大きい処理の場合通常は、
32bitコード同士で同等〜微妙に64bitOSの方が速い
ネイティブ同士では同等〜数割64bitOSの方が速い
|
- ウィンドウズ７ あ〜あ 32/64bit版買っちゃった12
470 ：名無し~3.EXE[sage]：2011/04/15(金) 23:58:00.34 ID:vzDJG8Sq - >>467
そりゃ探せば中にはそういう処理もある。
6%が体感できるかどうかは別として。
でも次のページは64bitが大差で勝ってるじゃないか。
32bitアプリも64bitアプリも6%どころではなく。
じゃあ一応訂正しておくか。
32bitコード同士で微妙に32bitの勝ち〜数割64bitOSの勝ち
ネイティブ同士では同等〜数割64bitOSの勝ち
|