Technoboseの日記： OSを64bitにする効果 10
日記 by
Technobose
十年物のVaio Type BXを使えるようにするためFreeBSDを入れて、デスクトップ環境としてLXqtを入れようと苦戦していた件、あきらめました。
で、Lxdeを入れることにした。
当初、主記憶が２ギガバイトしかないためFreeBSD 11.2 Release(x86)を入れてたんだけど、qgisのインストールでもおかしな点があって、AMD64版で入れ直し。
firefoxで試しにyoutubeを見ていて気がついたんだけど、同じ動画を再生していても64bitにしたほうがプロセッサの使用率がかなり低い。
今まで主記憶が2ギガバイトくらいなら、アドレスの表現方法の違いで64bit版の方がメモリの利用効率が落ちるから32bit版の方が良いと思っていたけど、違うみたい。
単純に64bit化しただけでなく、グラフィックプロセッサ周りも64bit版の方が新しい技術を利用できたりするから、単純にはいえないけど、64bitプロセッサで64bit版のOSを使えるなら主記憶が多少少なくてもメリットはあるのではないかしら。
それにしても、FreeBSDで単にOSを入れてデスクトップ環境を入れただけで、youtubeが見られるようになったというのはすごいなあ。
使えるレジスタがぜんぜん違います (スコア: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とかも、メモリアクセス以上に相当演算量の多い処理じゃない限り、メモリ速度の方に速度はクリップされますし）
言うほど速くなるやろか (スコア:0)
i5やi7以降ならAVX未対応のNehalem世代でも速くなるのはわかるけど
VAIO type BXはMeromコアのCore 2、しかもGPUはGMA960
この頃のCore 2は、64bitレジスタをふたつに割ってALUに処理させるもんで
32bitだとふたつづつ処理できるから速いけど、64bitで使うと同世代のAthlon 64 X2に比べ見劣りした
あれを64bitで使って速くなる所が想像できない
というより、ただ単純に最適化不足なだけな気がする
32bit版のCFLAGSとCXXFLAGSを-march=native -O2でmake worldするだけで64bit版使うより速くなるような…
(clnagの-O2が--mfpmath=sse -msse2を有効にするのかは知らんけど…)
俺も昔、AtomのD525 + ION2搭載母板を貰って、どうにかできないかとGentooで試行錯誤したけれど
結局i686で使うのが一番軽かったな、x86_64や当時出たてのx86_64-x32で使うより