アカウント名:
パスワード:
x86の32bit(としてつかう)モードに最適化したものでしょうか。キリキリチューニングが必要なら各自自分でやってください、なのかな。
ざっくり言えば、i386:従来からの32bitモード。プロセスあたりのメモリ空間上限4GBx86_64: 64bit CPUモード。ポインタは64bitでプロセスあたりのメモリ空間上限128TBに対して、x32: 64bit CPU を「レジスタ数がたくさんある32bitCPU」扱いするモード。メモリ空間4GBってことです。4GBの壁はあるかわりにポインタが32bitなので若干省メモリ。64bitモードで増えたレジスタを使うので、64bitモードのない古いCPUでは動きません。
＞ 64bitモードのない古いCPUでは動きません。
誰得…？
x86_64向けのbinary にしちゃうと ポインタやらなんやらあらゆる i386 binary の倍になるわけで、そうすると実際のメモリフットプリントが雑にいうと倍になっちゃうわけですよ。
DBとかは別として 日常使うようなアプリで実際に64bitポインタつかった巨大なメモリ空間なんかは要らないようなアプリが多い、でもx86_64で拡張された各種機能はとっても美味しいので使いたい。
という結果 64bit ポインタをあきらめることで メモリ消費を抑えつつ 本来の x86_64 の各種機能を使えるモード として提案されたのがx32 なわけですよ。
というわけなので 誰でも得と言えば得なんだけど...
一方で、もはやメモリなんかじゃぶじゃぶあるわけで そこまでしてガンバる構造をkernelに残しておくことの複雑さとか、そもそもみんな使ってないし.. とかいうあたりで メリットとデメリットを天秤すると 普及してもないしデメリットのが多くね? という話が出てきたというのが 本件だと思います。
メモリフットプリント倍ということは、単にメモリ倍積めば同じになるわけではなく、同一キャッシュサイズではキャッシュミス率も倍ということになります。イマドキはCPUキャッシュとメモリの速度差が数百倍あり、ほぼキャッシュミス率で速度が決まるので、下手すると速度が半分（実際にはデータ中のintとポインタの比率による）になります。
英wikipedia [wikipedia.org]によると、SPEC INTベンチで最速40%,平均5-8%の高速化になるそうです。(x86-64比)
イマドキの 64bit javaでは、 同様に（オプションで）参照を32bit表現にして高速化しています。32bit表現->64bitポインタへの余分な変換処理を入れてでもキャッシュミス率を低めた(ヒット率を高めた)法が速いってことです
x64でもオペランドサイズのデフォルトは32bitなのでさすがに「すべて倍」は雑すぎる。大きくなることは確かだけど。だからintが32bitなのもx64では「自然」
ところがLinuxのx86_64ではlongやint_fast32_tを64bitで定義しちゃったので、無駄に64bit演算させられるソースコードで溢れてるわけです。x32ならこの辺りは32bitになるので効率的と。
Raspberry Pi3とかで有効活用できる。でも今のraspbianってi386しかないよね。
raspbrrypi は ARM
あっ... (´・ω・`) ...
うっかりするような所か？
ラズパイ３はcpuがARM 64bitだけど、rasbianが既存のraspberrypiと互換を取るために32bitモードで動いているのであって全然違う話。
そもそも x86 の話ですよ？
ARM関係ない
Intelの安かったり古いCore MAなCPUが64bitだと遅かったので、それ対策かも。Macro-Fusion 64bitとかで検索
省メモリって書いてあるじゃん。あと、多分32ビット命令しか使わないんだろうから、コードサイズが減って多少キャッシュ効率とか上がったりしそう。
今と違い4GB以下のマシンにも人権（マシン権？）があった時代の徒花ですな。
誰得とか言ってる奴もJVMはきっと圧縮OOPで動いているhttps://www.oracle.com/technetwork/jp/articles/java/compressedoops-427... [oracle.com]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
32bitマシンは他にもあるから (スコア:0)
x86の32bit(としてつかう)モードに最適化したものでしょうか。
キリキリチューニングが必要なら各自自分でやってください、なのかな。
Re: (スコア:2)
ざっくり言えば、
i386:従来からの32bitモード。プロセスあたりのメモリ空間上限4GB
x86_64: 64bit CPUモード。ポインタは64bitでプロセスあたりのメモリ空間上限128TB
に対して、
x32: 64bit CPU を「レジスタ数がたくさんある32bitCPU」扱いするモード。メモリ空間4GB
ってことです。
4GBの壁はあるかわりにポインタが32bitなので若干省メモリ。
64bitモードで増えたレジスタを使うので、64bitモードのない古いCPUでは動きません。
Re:32bitマシンは他にもあるから (スコア:0)
＞ 64bitモードのない古いCPUでは動きません。
誰得…？
Re:32bitマシンは他にもあるから (スコア:4, 興味深い)
x86_64向けのbinary にしちゃうと ポインタやらなんやらあらゆる i386 binary の倍になるわけで、
そうすると実際のメモリフットプリントが雑にいうと倍になっちゃうわけですよ。
DBとかは別として 日常使うようなアプリで実際に64bitポインタつかった巨大なメモリ空間なんかは要らないようなアプリが多い、
でもx86_64で拡張された各種機能はとっても美味しいので使いたい。
という結果 64bit ポインタをあきらめることで メモリ消費を抑えつつ 本来の x86_64 の各種機能を使えるモード として提案されたのが
x32 なわけですよ。
というわけなので 誰でも得と言えば得なんだけど...
一方で、もはやメモリなんかじゃぶじゃぶあるわけで そこまでしてガンバる構造をkernelに残しておくことの複雑さとか、そもそも
みんな使ってないし.. とかいうあたりで メリットとデメリットを天秤すると 普及してもないしデメリットのが多くね? という話が
出てきたというのが 本件だと思います。
Re:32bitマシンは他にもあるから (スコア:1)
メモリフットプリント倍ということは、単にメモリ倍積めば同じになるわけではなく、
同一キャッシュサイズではキャッシュミス率も倍ということになります。
イマドキはCPUキャッシュとメモリの速度差が数百倍あり、ほぼキャッシュミス率で速度が決まるので、下手すると速度が半分（実際にはデータ中のintとポインタの比率による）になります。
英wikipedia [wikipedia.org]によると、SPEC INTベンチで最速40%,平均5-8%の高速化になるそうです。(x86-64比)
イマドキの 64bit javaでは、 同様に（オプションで）参照を32bit表現にして高速化しています。32bit表現->64bitポインタへの余分な変換処理を入れてでもキャッシュミス率を低めた(ヒット率を高めた)法が速いってことです
Re: (スコア:0)
x64でもオペランドサイズのデフォルトは32bitなのでさすがに「すべて倍」は雑すぎる。大きくなることは確かだけど。
だからintが32bitなのもx64では「自然」
Re:32bitマシンは他にもあるから (スコア:2)
ところがLinuxのx86_64ではlongやint_fast32_tを64bitで定義しちゃったので、無駄に64bit演算させられるソースコードで溢れてるわけです。
x32ならこの辺りは32bitになるので効率的と。
Re: (スコア:0)
Raspberry Pi3とかで有効活用できる。でも今のraspbianってi386しかないよね。
Re: (スコア:0)
raspbrrypi は ARM
Re: (スコア:0)
あっ... (´・ω・`) ...
Re: (スコア:0)
うっかりするような所か？
Re: (スコア:0)
ラズパイ３はcpuがARM 64bitだけど、rasbianが既存のraspberrypiと互換を取るために32bitモードで動いているのであって全然違う話。
Re: (スコア:0)
そもそも x86 の話ですよ？
ARM関係ない
Re: (スコア:0)
Intelの安かったり古いCore MAなCPUが64bitだと遅かったので、それ対策かも。
Macro-Fusion 64bitとかで検索
Re: (スコア:0)
省メモリって書いてあるじゃん。
あと、多分32ビット命令しか使わないんだろうから、コードサイズが減って
多少キャッシュ効率とか上がったりしそう。
Re: (スコア:0)
今と違い4GB以下のマシンにも人権（マシン権？）があった時代の徒花ですな。
Re: (スコア:0)
誰得とか言ってる奴もJVMはきっと圧縮OOPで動いている
https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427... [oracle.com]