アカウント名:
パスワード:
これから同じように32bit版廃止の事例は増えそう。ARM版Windowsでx86のアプリが実用的な速度で動くらしいので、32bitバイナリはエミュレータで動かすようにして、CPUから32bitの互換性を削除すればいいのに、と思う。速度が必要なアプリは64bit版が出ているだろうし。困るのは古いゲームぐらいだと思う。
CPUから32bitの互換性を取り除くと死ぬハード屋はとても多いとおもう
ARM版だとx64アプリは、実用的というかネイティブARM版と区別がつかないぐらいの速度で動くけど、x86アプリはワンテンポというかツーテンポ遅くて、エミュレートで動いてんなぁって露骨にわかるよ。
へー。なんでx64アプリは早くて、x86アプリは遅いんだろ。x64のバイナリの方が効率的でエミュレートしやすいんだろうか。
x64では汎用レジスター数が倍になるのが効いてるんじゃないかな。x86のハードウェアはレジスターリネーミングで誤魔化しているけど、エミュレーションでレジスターリネーミングしても速くならないんだろう
System32にあるほとんどのDLLがARM64Xになっててシステム周りがネイティブで動いてるx64とCHPE化されてるDLLが数十個しかなくて大部分のシステム周りすらエミュレートで動いてるx86の違いは多分にある
・CHPE化されてるDLLに相当するCHPE化してないDLLも用意してトラブルシューティングにCHPEを使わないオプションを用意してるx86とそんなオプションを用意せず背水の陣でやってるx64・CHPEターゲットのコンパイラを使う方法を文書化していないがARM64EC/ARM64XはABIも公開している・intrinsic使うとx86命令生成するCHPEターゲットのコンパイラとintrinsicは相当するA64命令になるARM64EC/ARM64Xターゲットのコンパイラ・なんか変なことするとすぐinternal compiler errorになるCHPEターゲットのコンパイラMSのやる気がx86の方向に向いてないのをひしひしと感じる
Win11-ARMのエミュ性能に興味があって、 coremark-pro (https://github.com/eembc/coremark-pro) を使って、同一マシン上で arm64 と x86_64 と i686 のスコアを比較したことがあります。
x86_64 は arm64 の 40%、i686 は 33% のスコアでした。x86_64の方が速いっちゃ速いのですが、dll の違いの方が利いていそうですね。
# ちなみに macos だと x86_64 は arm64 の87%のスコアが出ていた
CPUの方は互換性に大きなコストが無いなら消す意味は無い。下手にいじると64bit動作の間で互換性切れるかもしれんし……詳しくは知らんが、AMD64はアーキテクチャ的には64bitコードからシームレスに32bitコードを呼べる作りらしいんで(但しWindowsもLinuxもその機能をほぼ使わんので特に意味がない)下手に削除して互換性が壊れる方が面倒くさい。どーせマイクロコードかなんかを挟むから32bit専用の演算回路とかがある訳でも無いだろし。
デコーダーは楽できないかね。
CPU的には16bitもまだあるんじゃなかったっけ？
IA-64のトラウマがあるので32bit命令デコードの削除はしないでしょう。最近発表されたx86-sでも32bitユーザーモードバイナリの互換性は確保されているし
AMDがしれっとMicrosoftと組んで32bitハードウェア削除したりして。さよならx86ってな感じで。
Microsoftにメリットが無いな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
Windows 11は64bit版しかないので (スコア:0)
これから同じように32bit版廃止の事例は増えそう。
ARM版Windowsでx86のアプリが実用的な速度で動くらしいので、32bitバイナリはエミュレータで動かすようにして、CPUから32bitの互換性を削除すればいいのに、と思う。
速度が必要なアプリは64bit版が出ているだろうし。
困るのは古いゲームぐらいだと思う。
Re: (スコア:0)
CPUから32bitの互換性を取り除くと死ぬハード屋はとても多いとおもう
Re: (スコア:0)
ARM版だとx64アプリは、実用的というかネイティブARM版と区別がつかないぐらいの速度で動くけど、x86アプリはワンテンポというかツーテンポ遅くて、エミュレートで動いてんなぁって露骨にわかるよ。
Re: (スコア:0)
へー。
なんでx64アプリは早くて、x86アプリは遅いんだろ。
x64のバイナリの方が効率的でエミュレートしやすいんだろうか。
Re: (スコア:0)
x64では汎用レジスター数が倍になるのが効いてるんじゃないかな。x86のハードウェアはレジスターリネーミングで誤魔化しているけど、エミュレーションでレジスターリネーミングしても速くならないんだろう
Re: (スコア:0)
System32にあるほとんどのDLLがARM64Xになっててシステム周りがネイティブで動いてるx64と
CHPE化されてるDLLが数十個しかなくて大部分のシステム周りすらエミュレートで動いてるx86の違いは多分にある
・CHPE化されてるDLLに相当するCHPE化してないDLLも用意してトラブルシューティングにCHPEを使わないオプションを用意してるx86とそんなオプションを用意せず背水の陣でやってるx64
・CHPEターゲットのコンパイラを使う方法を文書化していないがARM64EC/ARM64XはABIも公開している
・intrinsic使うとx86命令生成するCHPEターゲットのコンパイラとintrinsicは相当するA64命令になるARM64EC/ARM64Xターゲットのコンパイラ
・なんか変なことするとすぐinternal compiler errorになるCHPEターゲットのコンパイラ
MSのやる気がx86の方向に向いてないのをひしひしと感じる
Re: (スコア:0)
Win11-ARMのエミュ性能に興味があって、 coremark-pro (https://github.com/eembc/coremark-pro) を使って、同一マシン上で arm64 と x86_64 と i686 のスコアを比較したことがあります。
x86_64 は arm64 の 40%、i686 は 33% のスコアでした。
x86_64の方が速いっちゃ速いのですが、dll の違いの方が利いていそうですね。
# ちなみに macos だと x86_64 は arm64 の87%のスコアが出ていた
Re: (スコア:0)
CPUの方は互換性に大きなコストが無いなら消す意味は無い。
下手にいじると64bit動作の間で互換性切れるかもしれんし……
詳しくは知らんが、AMD64はアーキテクチャ的には
64bitコードからシームレスに32bitコードを呼べる作りらしいんで
(但しWindowsもLinuxもその機能をほぼ使わんので特に意味がない)
下手に削除して互換性が壊れる方が面倒くさい。
どーせマイクロコードかなんかを挟むから32bit専用の演算回路とかがある訳でも無いだろし。
Re: (スコア:0)
デコーダーは楽できないかね。
Re: (スコア:0)
CPU的には16bitもまだあるんじゃなかったっけ？
Re: (スコア:0)
IA-64のトラウマがあるので32bit命令デコードの削除はしないでしょう。最近発表されたx86-sでも32bitユーザーモードバイナリの互換性は確保されているし
Re: (スコア:0)
AMDがしれっとMicrosoftと組んで32bitハードウェア削除したりして。
さよならx86ってな感じで。
Re: (スコア:0)
Microsoftにメリットが無いな