アカウント名:
パスワード:
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ポインタへの余分な変換処理を入れてでもキャッシュミス率を低めた(ヒット率を高めた)法が速いってことです
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
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: (スコア:0)
＞ 64bitモードのない古いCPUでは動きません。
誰得…？
Re: (スコア: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ポインタへの余分な変換処理を入れてでもキャッシュミス率を低めた(ヒット率を高めた)法が速いってことです