アカウント名:
パスワード:
x86とx64(AMD64)では使えるレジスタの幅が倍というだけでなく、数も倍(8→16)あり、実際にアプリケーションが好き勝手に使えるレジスタはそこからいくつか減るので、更に差は大きくなります。(FreeBSD向けアセンブラを組んだことはないのですが、たいてい、2つ3つのレジスタはOSのAPIや言語レベルの仕様でアプリからの変更はNGだったり用途が制限されたりします。)命令レベルでも、x86時代より各レジスタの扱いに差が小さくなっているので、コードを組み変えやすく、コンパイラによる最適化がやりやすくなっています。ですので、マルチメディア処理では違いが大きく出るかもしれませんね。
補足。上記は汎用レジスタの話で、ベクトル演算(SSEやらAVXやら)用のレジスタもx86モードとx64モードでは違いがあります。
そして、わざわざx64CPUのx86モードを前提にコンパイルしたバイナリでもなければ、x86向けの命令しか使われないわけで、ますます違いが大きいことに。# x64CPUのx86モード向けに最適化されたバイナリってどのくらいあるんだろう?# 考えても見なかったけど、それなりにあるのかな。
今回の件では動画再生のときに気付いたということなので、ちょっと違う話題になりますが、ポインタが倍になったせいでキャッシュが余計に食われて汎用レジスタが多少増えたくらいじゃ速くならないってこと、ないですかね?ポインタ多用するプログラムだったらありそうかとも思うんですが。
動画再生の話に戻すと、ベクトル演算を多用しそうなので、x86版では実はベクトル演算が使われていなかった! とか(x64なら何の指定もしなくてもSSE2までは使えるけど、x86版は何も指定されていないとかで。流石に無いか)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
使えるレジスタがぜんぜん違います (スコア:2)
x86とx64(AMD64)では使えるレジスタの幅が倍というだけでなく、数も倍(8→16)あり、
実際にアプリケーションが好き勝手に使えるレジスタはそこからいくつか減るので、更に差は大きくなります。
(FreeBSD向けアセンブラを組んだことはないのですが、たいてい、2つ3つのレジスタはOSのAPIや言語レベルの仕様でアプリからの変更はNGだったり用途が制限されたりします。)
命令レベルでも、x86時代より各レジスタの扱いに差が小さくなっているので、コードを組み変えやすく、コンパイラによる最適化がやりやすくなっています。
ですので、マルチメディア処理では違いが大きく出るかもしれませんね。
Re: (スコア:2)
補足。
上記は汎用レジスタの話で、ベクトル演算(SSEやらAVXやら)用のレジスタもx86モードとx64モードでは違いがあります。
そして、わざわざx64CPUのx86モードを前提にコンパイルしたバイナリでもなければ、x86向けの命令しか使われないわけで、ますます違いが大きいことに。
# x64CPUのx86モード向けに最適化されたバイナリってどのくらいあるんだろう?
# 考えても見なかったけど、それなりにあるのかな。
Re: (スコア:0)
今回の件では動画再生のときに気付いたということなので、ちょっと違う話題になりますが、
ポインタが倍になったせいでキャッシュが余計に食われて汎用レジスタが多少増えたくらいじゃ速くならないってこと、ないですかね?
ポインタ多用するプログラムだったらありそうかとも思うんですが。
動画再生の話に戻すと、ベクトル演算を多用しそうなので、x86版では実はベクトル演算が使われていなかった! とか
(x64なら何の指定もしなくてもSSE2までは使えるけど、x86版は何も指定されていないとかで。流石に無いか)
Re:使えるレジスタがぜんぜん違います (スコア:1)
最近は Windows 環境(Visual Studio)でも SSE はデフォルトで有効になっていたりしますが、32ビット版の方は SSE は有効になっていなかったのでは?という気はしますね。
メモリは遅いので、無駄に32ビットが64ビットになって記憶容量食うようになると、処理速度以前に遅くなりますからねぇ~
(GPUとかも、メモリアクセス以上に相当演算量の多い処理じゃない限り、メモリ速度の方に速度はクリップされますし)