Комментарии 6
Значит скоро и докер под apple m1 обновится с новым эмулятором
0
Лучше напишите, как они вот этого достигают — «Благодаря особенностям эмулятора приложение в изолированном окружении выполняется почти с той же эффективностью, что и в нативном окружении.»
0
За счёт трансляции, а не эмуляции. Например аналогично работает WINE.
Вместо того чтобы эмулировать железо ARM (что было бы крайне медленно, из-за отсутствия аппаратной поддержки), — они превращают arm-инструкции в аналогичные x86-инструкции (виртуализация которых поддерживается железом).
Подход не новый. Тот же libhoudini в android-x86 появился лет 10 назад, который делал ровно тоже самое.
Вместо того чтобы эмулировать железо ARM (что было бы крайне медленно, из-за отсутствия аппаратной поддержки), — они превращают arm-инструкции в аналогичные x86-инструкции (виртуализация которых поддерживается железом).
Подход не новый. Тот же libhoudini в android-x86 появился лет 10 назад, который делал ровно тоже самое.
-1
Разве wine использует jit? Мне кажется вы путаете. Wine по факту это подмена системных вызовов и реализация поддержки запускаемых бинарников. Сам код запускается нативно без какой либо эмуляции. По этой причине к примеру невозможен запуск wine несовместимой архитектуры (x86_64 на x86 например)
+3
По факту — ситуация аналогичная, системные вызовы приложения подменяются на аналоги из хоста.
Ну, если мы не говорим про какой-нибудь hangover, например. Там ещё и трансляция x86 -> arm идёт.
Ну, если мы не говорим про какой-нибудь hangover, например. Там ещё и трансляция x86 -> arm идёт.
0
Там даже немного не так: системные вызовы не подменяются, такого функционала к сожалению пока нет в Linux. Вместо этого у wine есть своя реализация множества библиотек Windows таких, как user32.dll, которые в свою очередь имеют функции. Обычно программы для Windows не используют системные вызовы напрямую, а работают через такие библиотеки.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
После года разработки вышел эмулятор QEMU 6.0