Linuxカーネル開発者の間でx32 ABIの廃止が議論される 48
ストーリー by hylom
微妙なポジションではある 部門より
微妙なポジションではある 部門より
あるAnonymous Coward曰く、
Linuxでは数年前に「x32」ABIが導入されたが、利用者が少ないことから最終的に廃止される可能性が出て来ているようだ（PHORONIX、Slashdot）。
「x32」は、「x86_64」（64ビット版x86アーキテクチャ）をベースに、アドレス長だけを32ビットにしたアーキテクチャで64ビット対応のx86系CPUで利用できる（2002年の「本の虫」記事）。
x32ではパフォーマンスの向上が期待できると言われているが、実際にはあまり使われておらず、メンテナンスコストがかかることからカーネル開発者グループの間で廃止が検討されているという。Linux開発のリーダーであるLinus Torvalds氏は廃止に賛成している模様。
やっぱりみんな使ってないし (スコア:3, おもしろおかしい)
ここのコメントでの範囲ですら x32 がいったいなんなのか/ほんらいどういうメリットデメリットがあるものなのかを理解してない人がいっぱい出てきてるような状況だし、結局そもそも使ってないんだろうなということなわけでなくなってもほとんど誰も困らなさそうw
Re:やっぱりみんな使ってないし (スコア:1)
メガドライブの上のほうに挿してあるからよく知ってる
Re: (スコア:0)
それは32Xだｗ
Re: (スコア:0)
鏡餅を飾るのはまだ早いだろ
Re: (スコア:0)
i386のことをしばしばx32と言ったりするくらいの知名度のなさだもんな
Re: (スコア:0)
i386のことをしばしばx32と言ったり
この「i386」ってのもコメント主が指してるのは特定のCPUじゃなく「i386以降」のことだと思われるのでめんどくさいぞw
Re:やっぱりみんな使ってないし (スコア:3)
i386とか言いながら、それ以降に入った命令が必須だったりするので、最近だとi386以降ですらなく、Pentium(ひょっとしたらMMX Pentiumかも)以降ぐらいの意味ですよ。たいていのバイナリパッケージもアーキテクチャ表示がi686になってますしね。
ほんとにi386に対応してたのは、Windowsだと3.1まででNTだと3.51まで、以降のバージョンは動作しません。
Linuxだと3.8で、NetBSDだと5.0で、FreeBSDだと6.0で、OpenBSDだと4.2でサポートが切られました。
Re: (スコア:0)
Pentium Proから追加されたCMOV命令が多用されています
i686ではCMOV命令は定義されておらずVIA C3の初期のものなどは実装していませんが、実際のところ何も動きません
x86_64も・・・ (スコア:0)
Intel AVX2を使えない環境が足切りされるのも時間の問題かもなあ。CPUは3年ひと昔でどんどんサポートが切られていく。6年たつと存在しないものとして扱われることも多い。
Re: (スコア:0)
現時点で販売されているAtomプロセッサがAVX2使えないからそれはしばらく無いと思う。
Re: (スコア:0)
ずっと昔、PC-98用(486SXだったかな・・・)にLinuxを入れたとき、コマンドの実行時にエラーが出まくった記憶があります。
そういうことでしたか。
Re: (スコア:0)
結局中途半端な過渡期のものですよ。PAEなんかもまとめてオワコンにしてしまえ。
ふと思い出しました (スコア:0)
うろ覚えなのですが、IntelのAtomでCedar Trailってあったじゃないですか。
あれって、64bit対応してるのに様々な事情で64bitOSが使えなかったような…（調べてみたけど自信がない）
もしかするとそういうのにピッタリだったのかなぁ。
Cedar Trailも過渡期の産物感アリアリですが…だとしても、実績十分のいにしえi386版がありますしね。
/*
昔DN2800MTというAtom N2800が載せてあるMini-ITXマザーが一時期気になっててCedar Trailを思い出したのですが、
このマザーは12Vのみで動くようなので、ディスプレイも小型でUSB電源で動作するものにすれば、だいたい50cm四方の太陽電池＋バッテリーな電源で動作するPCが作れるかなぁ、とか考えてました。（ノートPCだと一旦AC100Vにしないといけないので効率が落ちるのだ。）
大体同じ頃？にRaspberry PiみたいなGUI環境が使えるCPUボードが出はじめて、そちらも気になってましたね。
*/
Re: (スコア:0)
LAHF命令やXDビット(AMD用語ではNXビット)に対応してないんじゃなかったっけ
Re: (スコア:0)
それはもうちょっと古いCPUかも知れない。
wiki [wikipedia.org]によると内蔵GPUが32bitしか対応してないらしいです。
LAHF,SAHF命令ってフラグとレジスタ間でデータをやりとりするやつですよね。もともと仮想化周りで使われていたとか。Windows8.1で必須になって初期の64bitCPUがアウトになったようですね。
Re: (スコア:0)
#3534035 とか現状を知らない奴も多いし
x86_64-x32は選ばれし者だけが使える (スコア:1)
Linuxを常用している人であっても、自前でビルドして使ってるような猛者は僅かで
残りの連中はディストリが配布してるアーカイブをそのまま使ってる
この辺でx86_64-x32をサポートしていないディストリ使いは利用することができない
例えGentoo使いのようなx32をサポートしたディストリ使いであったとしても
プロプラ系のアプリやドライバを利用する人は、そのドライバやアプリが
奇跡的にx86_64-x32をサポートしているわけでもない限り利用することができない
この辺でnvidiaやamdのドライバ使いも除外される
そんな人は開発者の中にも希少なので、OSSアプリであってもx32は殆どサポートされず
それゆえに、例えばgcc5系でApache 2.4をx32ビルドすると-march=nativeでビルドした場合のみ
壊れたバイナリを吐くというような環境依存のバグを嫌というほど踏み抜く
そうして色々と面倒すぎるので誰も使わなくなる
Re:x86_64-x32は選ばれし者だけが使える (スコア:1)
やっぱりいろいろ面倒なんですね。
同じようなことはMIPSのABIでもあって、o32, n64, n32があるのだけど、マイナーなn32向けに命令拡張したCPUとライブラリがあって困った思い出がある。
１０年以上前なので今n32がどうなのかは知らない。
x86系では、そういう特殊なCPUはないだろうし、お金さえ出せば性能をあげられるので、労力に見合わないよなあ。
しかし、カーネルサポートをなくしてしまうのはちょっと寂しいかな。
x86_64カーネルをベースにi386ユーザランドのシステムを乗っけられるのと同様にx32の環境も作れると思うので、ドライバや基本的なアプリに関してはx86_64用があれば大丈夫なんじゃないかと。
Re: (スコア:0)
ぜひLinusにあなたの意見「寂しいから消さないで」を伝えてみてください！
封印されたはずの「Fxxx」を聞けるかもしれませんよ？
Windows用 (スコア:1)
boostのライブラリ、何故かx32とか入っていたのだけど、アレは何だったのか．．．。
メモリいくつ使えたっけ (スコア:1)
WoWはプログラムメモリが4GB使えて、古いjvmで移行の金なんか出ないときに、助かったな。
X32 ABIも似た効果があったはずだけど、流石に64bit jvm使ったので良くわからない。
むしろこっちを積極的に使うべきでしょう (スコア:1)
4GB必要かどうかなんて、ソフトを作る前に判断できるでしょう。その判断さえ間違わなければ、速度的にも容量的身も良いことだらけです。使わない理由がわかりません。ひとつひとつの節約効果は小さくても、地球全体で考えれば大きいです。
Re: (スコア:0)
どっちか、と言わず両方動くようにカーネル書き換えればいいんじゃないかな。それができるカーネルだってあるんだから。
Re: (スコア:0)
64ビットカーネル自体はix86,x86_64およびx32のABI全部サポートしてるんです。
問題はそのサポートに(無駄に見える)コストがかかる、ということなので。
32bitマシンは他にもあるから (スコア:0)
x86の32bit(としてつかう)モードに最適化したものでしょうか。
キリキリチューニングが必要なら各自自分でやってください、なのかな。
Re:32bitマシンは他にもあるから (スコア: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: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]
Re: (スコア:0)
キャッシュに載る量が多くなるから、若干速いのでは。
Re: (スコア:0)
> 4GBの壁はあるかわりにポインタが32bitなので若干省メモリ。
若干どころではない
ポインタとintなどのunionが軒並み8バイトになってx64化で倍のメモリを食うようになったアプリが少なくなかった
今は16GBとか32GBのメモリが当たり前なのでx32のメリットはかなり少ない
Re: (スコア:0)
> ポインタとintなどのunion
そんなデータ構造の大半を占めるようなアプリって、そんなにある気がしない。
Re: (スコア:0)
ほかの32bitといえばARMのThumb命令
密度とアクセスアドレスの局所化のためにARMより大きな犠牲を払ったABIなのかな
Re:32bitマシンは他にもあるから (スコア:1)
組み込みでは、ハードウェアのコストに直結するので、少容量であることは重要です。
組み込み用のコアテックスMではThumb命令の利用があたりまえです。というかもとから組み込み用途のためのThumb命令です。ルネサスの真似しやがって！
ちなみに組み込みではいまだにfarとかnearとかを駆使して速度と容量をケチるプログラミングスタイルは健在です。
Linuxそのものを廃止で (スコア:0)
いいんやで？
Re: (スコア:0)
いや、普通にLinux滅んだら殆どのネット上のサーバー滅ぶんですがそれは