アカウント名:
パスワード:
x86とx64(AMD64)では使えるレジスタの幅が倍というだけでなく、数も倍(8→16)あり、実際にアプリケーションが好き勝手に使えるレジスタはそこからいくつか減るので、更に差は大きくなります。(FreeBSD向けアセンブラを組んだことはないのですが、たいてい、2つ3つのレジスタはOSのAPIや言語レベルの仕様でアプリからの変更はNGだったり用途が制限されたりします。)命令レベルでも、x86時代より各レジスタの扱いに差が小さくなっているので、コードを組み変えやすく、コンパイラによる最適化がやりやすくなっています。ですので、マルチメディア処理では違いが大きく出るかもしれませんね。
補足。上記は汎用レジスタの話で、ベクトル演算(SSEやらAVXやら)用のレジスタもx86モードとx64モードでは違いがあります。
そして、わざわざx64CPUのx86モードを前提にコンパイルしたバイナリでもなければ、x86向けの命令しか使われないわけで、ますます違いが大きいことに。# x64CPUのx86モード向けに最適化されたバイナリってどのくらいあるんだろう?# 考えても見なかったけど、それなりにあるのかな。
x86-64で増えたレジスタ使うにはREXプレフィックス付けなきゃで命令長が長く為、命令のフェッチ帯域の制限で1クロックあたりのデコードできる命令が減って遅くなる場合が多々あるようです。
追加レジスター使っても2命令のデコードが出来るのはhaswellからだった記憶があります。
arm64関連でx86-64でレジスター増えたけど速くなったのか?の議論が時々起きますが、この辺に触れてる人はほぼ見かけないですね。
そもそも物理的なレジスタの数はオペランドに出てくる名前の数より遥かに多かったはずです。逆説的ですがx86はレジスタが少ないがゆえにx86はレジスタが多いのです。
レジスタリネーミングは、「パイプラインを乱さないため」「アウトオブオーダー実行しやすくするため」、つまり「CPUの稼働効率を上げる」ための、小手先の技術。確かにその効果は絶大ですが、ある特定の処理において「ワーキングセットがレジスタに収まるかどうか」の瀬戸際では、「レジスタリネーミングがあるから物理レジスタはもっと多い」というのは何の意味もありません。レジスタが足りない場合はメモリアクセスが頻発する羽目になり、そのペナルティは絶大です。そういう場面では、論理的なレジスタの多さが全て。
ギリギリレジスタに収まらなくて悔しい思いをしたかギリギリレジスタに収まって快感を得たかで記憶にバイアスがかかっていませんか?
メモリアクセスのペナルティが大きいのは事実ですが論理的なレジスタが増えたところで入出力のメモリアクセスは無くなりません。
メモリアクセスのペナルティを隠蔽する点でもレジスタリネーミング様々だと思います。
経験則としてn-bitのintegerの計算をするのにn-bitのレジスタよりも最初から2n-bitのレジスタを使ったほうがいいアセンブラコードになりますね。だから32bit integerを前提にしているコードはx86環境よりx64環境のほうがいいコードになるじゃないかと。
あとはclang(llvm)の最適化がx86よりx64のほうが進んでいるのかもしれない。
今回の件では動画再生のときに気付いたということなので、ちょっと違う話題になりますが、ポインタが倍になったせいでキャッシュが余計に食われて汎用レジスタが多少増えたくらいじゃ速くならないってこと、ないですかね?ポインタ多用するプログラムだったらありそうかとも思うんですが。
動画再生の話に戻すと、ベクトル演算を多用しそうなので、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:使えるレジスタがぜんぜん違います (スコア:1)
x86-64で増えたレジスタ使うにはREXプレフィックス付けなきゃで命令長が長く為、
命令のフェッチ帯域の制限で1クロックあたりのデコードできる命令が減って遅くなる場合が多々あるようです。
追加レジスター使っても2命令のデコードが出来るのはhaswellからだった記憶があります。
arm64関連でx86-64でレジスター増えたけど速くなったのか?の議論が時々起きますが、この辺に触れてる人はほぼ見かけないですね。
Re: (スコア:0)
そもそも物理的なレジスタの数は
オペランドに出てくる名前の数より遥かに多かったはずです。
逆説的ですがx86はレジスタが少ないがゆえにx86はレジスタが多いのです。
Re:使えるレジスタがぜんぜん違います (スコア:1)
レジスタリネーミングは、「パイプラインを乱さないため」「アウトオブオーダー実行しやすくするため」、つまり「CPUの稼働効率を上げる」ための、小手先の技術。
確かにその効果は絶大ですが、ある特定の処理において「ワーキングセットがレジスタに収まるかどうか」の瀬戸際では、「レジスタリネーミングがあるから物理レジスタはもっと多い」というのは何の意味もありません。
レジスタが足りない場合はメモリアクセスが頻発する羽目になり、そのペナルティは絶大です。そういう場面では、論理的なレジスタの多さが全て。
Re: (スコア:0)
ギリギリレジスタに収まらなくて悔しい思いをしたか
ギリギリレジスタに収まって快感を得たかで
記憶にバイアスがかかっていませんか?
メモリアクセスのペナルティが大きいのは事実ですが
論理的なレジスタが増えたところで
入出力のメモリアクセスは無くなりません。
メモリアクセスのペナルティを隠蔽する点でも
レジスタリネーミング様々だと思います。
Re: (スコア:0)
経験則としてn-bitのintegerの計算をするのにn-bitのレジスタよりも
最初から2n-bitのレジスタを使ったほうがいいアセンブラコードになりますね。
だから32bit integerを前提にしているコードはx86環境よりx64環境のほうが
いいコードになるじゃないかと。
あとはclang(llvm)の最適化がx86よりx64のほうが進んでいるのかもしれない。
Re: (スコア:0)
今回の件では動画再生のときに気付いたということなので、ちょっと違う話題になりますが、
ポインタが倍になったせいでキャッシュが余計に食われて汎用レジスタが多少増えたくらいじゃ速くならないってこと、ないですかね?
ポインタ多用するプログラムだったらありそうかとも思うんですが。
動画再生の話に戻すと、ベクトル演算を多用しそうなので、x86版では実はベクトル演算が使われていなかった! とか
(x64なら何の指定もしなくてもSSE2までは使えるけど、x86版は何も指定されていないとかで。流石に無いか)
Re:使えるレジスタがぜんぜん違います (スコア:1)
最近は Windows 環境(Visual Studio)でも SSE はデフォルトで有効になっていたりしますが、32ビット版の方は SSE は有効になっていなかったのでは?という気はしますね。
メモリは遅いので、無駄に32ビットが64ビットになって記憶容量食うようになると、処理速度以前に遅くなりますからねぇ~
(GPUとかも、メモリアクセス以上に相当演算量の多い処理じゃない限り、メモリ速度の方に速度はクリップされますし)