Блог

Мне любопытны совершенно разные характеристики производительности при запуске двоичных файлов x86-64 на платформе Apple M1 с использованием Rosetta 2 и эмуляции, например, то, что в настоящее время делает Docker Desktop с использованием QEMU.

Я понимаю, почему эмуляция происходит так медленно, но объяснение того, почему Rosetta 2 работает так быстро, было подробно описано в этой теме Twitter: https://twitter.com/ErrataRob/status/1331735383193903104

Суть этого объяснения заключается в том, что при обычных обстоятельствах arm и x86 имеют противоположные (и несовместимые) схемы адресации памяти, которые требуют значительных затрат на эмуляцию, но чип M1 решает эту проблему с помощью аппаратной оптимизации, которая позволяет ему получать доступ к памяти с использованием обеих схем адресации. Фактически, когда выполняются инструкции, эмулируемые Rosetta 2, устанавливается флаг, сообщающий процессору об использовании схемы адресации в стиле x86.

Предполагая, что это объяснение является разумным (и если у кого есть лучше-источников информации, чем выше в Twitter-нить буду признателен этом в комментариях для включения), это технически допустимо, что эта оптимизация может быть использована для полной аппаратной эмуляции, например, работает на x86-64 Linux и Docker-контейнеров, или работает на x86-64 для рабочего стола Windows виртуальные машины а-ля компания VMware фьюжн/в VirtualBox? Или отдельный уровень операционной системы в этих сценариях исключает возможность использования оптимизации упорядочения памяти?

Отдельно задокументирован и опубликован ли этот режим процессора (флаги или инструкции) для стороннего использования или он является частным только для Apple?

Не адресация памяти, а упорядочение памяти. т. е. для атомов без блокировки, используемых для синхронизации между потоками-в x86 каждая загрузка/хранилище asm соответственно приобретается/освобождается. (С реальными процессорами x86, выполняющими спекулятивные ранние загрузки, чтобы производительность не снижалась в обычных условиях, когда один поток работает с памятью, которую не записывают другие потоки.)

M1 имеет аппаратную поддержку для такого режима, а также слабо упорядоченный режим для наиболее эффективного выполнения собственного кода AArch64. Видеть

• https://singhkays.com/blog/apple-silicon-m1-black-magic/#performance-must-suck-when-trying-to-emulate-x86-on-arm-right
• https://www.reddit.com/r/hardware/comments/i0mido/apple_silicon_has_a_runtime_toggle_for_tso_to/.

И да, https://github.com/saagarjha/TSOEnabler является программным обеспечением с открытым исходным кодом для переключения этой поддержки. Но это расширение ядра, и подпись кода затрудняет разрешение macOS, и вам нужно подписать его или отключить проверку подписи или что-то в этом роде:

Предположительно, вы сможете использовать это, если создадите и подпишете расширение ядра (отключив SIP, если вы не используете сертификат подписи KEXT) и перетащите его в /Библиотека/Расширения. Должно появиться диалоговое окно с предложением включить расширение в области настроек безопасности и конфиденциальности, вы разрешаете его оттуда и перезапускаете, и оно будет установлено. (Если вы этого не видите, разрешения для расширения могут быть неверными: попробуйте использовать колесо chown-R root:.) На практике это может пойти не так во многих отношениях, и мне повезло, я «сбросил все» и попытался установить после выполнения следующих действий:

[…] см. ссылку для списка шагов

Так что да, вполне вероятно, что эмуляция x86 QEMU может использовать ту же аппаратную поддержку, что и эмуляция x86 Rosetta-2. Они оба являются эмуляторами x86.

И, как вы сказали, основная проблема заключается в том, что Apple предоставляет общедоступные API для включения режима HW, чтобы людям не приходилось устанавливать этот модуль ядра вручную; я уверен, что большинство людей не захотели бы этого делать. Я мало что знаю о ситуации с программным обеспечением, меня больше интересовали детали архитектуры процессора.