12

Rosetta 2 とエミュレーションを使用して Apple M1 プラットフォームで x86-64 バイナリを実行すると、パフォーマンス特性が大きく異なることに興味があります。たとえば、Docker Desktop が現在QEMUを使用して行っていることです。

エミュレーションが非常に遅い理由は理解していますが、Rosetta 2 が非常に高速である理由については、次の Twitter スレッドで詳しく説明しています: https://twitter.com/ErrataRob/status/1331735383193903104

その説明の要点は、通常の状況では、arm と x86 は反対の (そして互換性のない) メモリ アドレッシング スキームを持ち、かなりのエミュレーション オーバーヘッドを必要とするが、M1 チップは、両方のアドレッシング スキームを使用してメモリにアクセスできるようにするハードウェア最適化でこれに対処するということです。実際には、Rosetta 2 でエミュレートされた命令が実行されると、x86 スタイルのアドレス指定方式を使用するようにプロセッサに知らせるフラグが設定されます。

この説明が妥当であると仮定すると (そして、誰かが上記の Twitter スレッドよりも優れたソースのレポートを持っている場合は、コメントに含めていただければ幸いです)、この最適化を完全なハードウェア エミュレーション (x86 の実行など) に活用できることは技術的に妥当ですか? 64 個の Linux Docker コンテナ、またはVMware Fusion/VirtualBoxのように完全なx86-64 Windows デスクトップ仮想マシンを実行していますか? または、これらのシナリオではオペレーティング システム レイヤーが分離されているため、メモリ順序の最適化を利用できませんか?

これとは別に、このプロセッサ モード (フラグまたは命令) は文書化され、サードパーティの使用のために公開されていますか、それとも Apple だけに非公開ですか?

4

1 に答える 1

5

メモリのアドレス指定ではなく、メモリの順序付け。つまり、スレッド間同期に使用されるロックフリーのアトミックの場合 - x86 では、すべての asm ロード/ストアがそれぞれ取得/解放されます。(実際の x86 CPU では投機的な初期ロードを実行するため、他のスレッドが書き込みを行っていないメモリで単一のスレッドが動作している場合、通常の状態ではパフォーマンスが低下しません。)

M1 には、そのようなモードのハードウェア サポートと、ネイティブ AArch64 コードを最も効率的に実行するための弱順序モードがあります。見る

はい、https://github.com/saagarjha/TSOEnablerは、そのサポートを切り替えるためのオープンソース ソフトウェアです。しかし、これはカーネル拡張機能であり、コード署名により、MacOS で許可するのが難しくなり、署名するか、署名検証などを無効にする必要があります。

おそらく、カーネル拡張機能をビルドして署名し (KEXT 署名証明書を使用していない場合は SIP を無効にします)、/Library/Extensions にドラッグすると、これを使用できるはずです。ダイアログが表示され、[セキュリティとプライバシー] 設定ペインで拡張機能を有効にするよう求められます。そこから拡張機能を許可して再起動すると、インストールされます。(表示されない場合は、拡張機能のパーミッションが間違っている可能性があります。chown -R root:wheel を試してください。) 実際には、これは多くの点でうまくいかない可能性があります。以下を実行した後にインストールします。

[...] ステップのリストについてはリンクを参照してください

そうです、QEMU の x86 エミュレーションが、Rosetta-2 の x86 エミュレーションと同じハードウェア サポートを使用できる可能性はあります。 どちらも x86 エミュレーターです。

おっしゃる通り、主な問題は Apple が HW モードを有効にするためのパブリック API を提供しているため、このカーネル モジュールを手動でインストールする必要がありません。きっとほとんどの人はそうしたくないでしょう。私はソフトウェアの状況についてあまり知りませんが、CPU アーキテクチャの詳細に興味がありました。

于 2021-09-04T20:09:16.487 に答える