Native apple silicon m1 support

Поддержка процессоров Apple M1 в .NET

17 ноября Apple официально представила устройства на базе своего нового ARM-процессора Apple M1. Естественно, это событие не могло быть не замечено со стороны компании Microsoft, которая с 2014 года начала активную экспансию .NET на новые платформы. Давайте посмотрим, что нас ждет в связи с этим в ближайшее время.

Начнем пожалуй с инструментов, а затем перейдем к самой платформе .NET, но если вам не терпится узнать, получат ли новые маки поддержку .NET, то вот вам небольшой спойлер:

Да, на новых маках будет .NET

Visual Studio Code

Команда разработчиков Visual Studio Code уже объявила о том, что работает над поддержкой новых процессоров. На странице загрузок Insider Preview для macOS уже появились опция для загрузки экспериментальной сборки с поддержкой ARM. Следить за работой команды можно на официальном аккаунте в GitHub.

Visual Studio for Mac

Если команда VS Code уже подготовила тестовые сборки с поддержкой Apple M1, то их коллеги из команды Visual Studio for Mac оказались не так расторопны:

Впрочем Visual Studio for Mac гораздо более крупный и сложный проект, поэтому портирование его на новый процессор может занять несколько больше времени. Сейчас эта версия IDE может работать при поддержке Rosetta 2.

На данный момент у владельцев новых ноутбуков Apple наблюдаются некоторые проблемы при отладке проектов на Xamarin.Forms для iOS. Соответствующий баг уже заведен в репозитории проекта Xamarin.iOS & Xamarin.Mac.

Rider

В JetBrains уже объявили, что они работают над переносом JetBrains Runtime (и всех продуктов, работающих на JVM, в том числе и Rider) на Apple Silicon. На данный момент IDE от JetBrains работают на чипах Apple Silicon через Rosetta 2. Правда не все функции работают в этом режиме стабильно. Так, например, многие жалуются на то, что отладка в Rider сейчас не работает.

Docker

Docker стал практически must have инструментом для современного разработчика. У Майкрософт есть обширный набор образов для .NET, но к сожалению, воспользоваться вы ими на ноутбуке с новым процессором от Apple пока не сможете.

Будем надеяться, что в ближайшее время поддержка M1 будет реализована в Docker.

А теперь перейдем к самому главному – получит ли новый чип поддержку .NET?

Те, кто подсмотрели спойлер в начале статьи уже знают ответ на этот вопрос. Команда разработки .NET активно работает над поддержкой Apple M1. Для этого даже был создан отдельный проект в трекинге платформы. Стоит отметить тот факт, что текущая версия платформы (а именно, недавно ушедший в релиз .NET 5) будет работать поверх Rosetta. А вот в .NET 6 уже будет нативная поддержка нового чипа. Согласно планам Microsoft, произойдет это не раньше, чем через год:

Из того, что уже выполнено, я бы отдельно отметил такие задачи:

Также запланирована поддержка нового процессора в ASP.NET Core.

Но несмотря на то, что официальной поддержки новых процессоров придется ждать почти год, уже доступна к загрузке альфа-версия .NET 6.0. На момент написания статьи, это версия 6.0.0-alpha.1.0562.6.

Проект Mono, который обычно был догоняющим (так как команде приходилось реализовывать те возможности, которые уже были в .NET) на этот раз оказался слегка впереди. Пулреквест с поддержкой нового процессора сделала сама Apple, которая ранее обещала помощь в поддержке M1 для проектов с открытым исходным кодом.

Проекты, которые вскоре должны получить поддержку Apple M1

Самое большое изменение, которое было сделано для поддержки процессора M1 связанно с тем, как работает JIT, а именно, с изменение состояния потоков. Это было реализовано с помощью новых макросов в mono/mini.h. Они были встроены в систему из соображений производительности.

Rosetta 2

В этой публикации не один раз упоминалась технология Rosetta 2. Для тех, кто не знает, что это, приведем пояснение, которое размещено на странице портала Apple Developer:

Rosetta — это процесс трансляции, который позволяет пользователям запускать приложения, содержащие инструкции x86_64, на микросхеме Apple. Rosetta призвана упростить переход на микросхему Apple, давая разработчикам время на создание универсального двоичного кода приложений. Если исполняемый файл содержит только инструкции Intel, macOS автоматически запускает Rosetta и начинает процесс трансляции. По окончании трансляции система запускает подготовленный исполняемый файл вместо оригинала. Однако процесс перевода требует времени, поэтому транслированные приложения иногда запускаются или работают медленнее.

Итоги

Новый процессор (а соотвественно устройства, которые будут на основаны на нем) без сомнений получит нативную поддержку в .NET, впрочем эта задача не является приоритетной в текущем роадмапе, поэтому ждать ее придется не раньше, чем в релиз уйдет шестая версия платформы. До того момента можно будет работать c .NET, используя возможности Rosetta 2. Что касается инструментария для разработчиков, то я могу предположить, что в ближайшие пол года основные проблемы будут решены (возможно даже с участием Apple) и уже к апрелю можно будет потихоньку присматриваться к компьютерам на базе Apple M1 в качестве рабочего инструмента.

Источник

Native Apple Silicon M1 support

Apple Silicon proposed in PR586. It includes:

• m1 arm64 version of llvm , ilibmobiledevice , hfsconmpressor libraries to allow it being used with arm64 version of java;
• support for arm64 iOS simulator and arm64 MacOSX console target.

How fast it is (compiling classes using 8 threads):

(Mac Mini m1): Compiled 3317 classes in 36.45 seconds
(Mac Pro W3565): Compiled 3317 classes in 111.60 seconds
(MacBook Pro, i5-4278U @ 4 threads): Compiled 3317 classes in 219.09 seconds

How to use

Pre-build binaries were deployed as 10.1.1-SNAPSHOT to com.robovmx fork and accessible for testing using Idea plugin or with gradle:

Technical details

Compiling lib for m1 arm64

CMake pain

While running CMake on Apple platform it adds arch and sysroot parameters to compiler flags. However, there are CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET to control the beast, but it still doesn’t allow you to control completely build flags.
The only way to make it do what expected is to tell CMake we are doing cross compilation by specifying CMAKE_SYSTEM_NAME .
In this case it will try to provide SYSROOT but it can be controlled by overriding CMAKE_OSX_SYSROOT .

Adapting LLVM

commit
Once m1 introduced arch64 binary can be any of the following arm64 platforms: MacOSX on m1 , ios on device , ios on m1 simulator (with tvos it ever worse). A try to link arm64 files produced by RoboVM result in error:

building for iOS Simulator, but linking in object file built for iOS, for architecture arm64

To differentiate platforms Apple now uses LC_BUILD_VERSION mach-o load command:

LC_BUILD_VERSION replaced LC_VERSION_MIN_IPHONEOS . There is no support for this command in LLVM3.6 used with RoboVM. All required parts of code were borrowed from LLVM12 and added as a patch.

Fun fact 1

LLVM12 is not able to compile an apple asm file due missing corresponding branches in bool DarwinAsmParser::parseBuildVersion:

org.robovm.llvm.LlvmException: com.android.okhttp.HttpHandler:2:17: error: unknown platform name .build_version iossimulator, 14, 0

These were added to patch;

Fun fact 2

Clang 3.6` is so old so doesn’t expect iOS version greater than 9.99;

Compiling ilibmobiledevice

commit
Where was only cross compilation issue same as in case of LLVM. NOTE: I was not able to test it with device as for development I rent m1 mac in cloud without ability to attach device to it.

Compiling libhfscompressor

commit Sources for this lib was missing in the project. Picked from https://github.com/robovm/hfscompressor, adapted to build using CMake and to use recent dependencies.
Added option to compile for both macosx-arm64 and macosx-x86_64 . HfsCompressor.java updated to load platform specific binary

RoboVM compiler adaptation

commit
This commit adds Environment (Native/Simulator) option that allows to make difference between targets of same arch (e.g. iOS arm64 vs MacOSX arm64).
For example build for arm64 now could be targeted to ios-arm64 , macosx-arm64 , ios-arm64-simulator . LLVM detects proper target from the triple, and it is being generated now with respect to Environment option. Also linker -miphoneos-version-min= parameter was replaced with —target= one that accepts the triple.

Changes were done to folder names: environment is being attached to every arch name where applicable. For example:

All code that used os + arch as key for platform now uses os + arch + env .

VM Native libraries adaptation

commit As linker now depends on LC_BUILD_VERSION separate set of VM native libraries were compiled for macosx-arm64 , ios-arm64-simulator targets.

Simulator pickup logic adapted

commit Logic adapted to following:

• simulator considered to have arm64 arch only on m1 host and if simulator’s version is 14+
• x86 simulator is not available on arm64 m1 host

Intellij Idea plugin changes

• auto simulator arch is set to the on of the host. E.g. on m1 will be set to arm64
• console target now has arch option that allows to select x86_64 / arm64 arch on m1 silicon;

Other fixes

commit These issues were discovered during run against debug version of llvm lib and crashes happened on assertions:

• llvm: changed Load/Store atomic access ordering from unordered to monotonic as it was crashing during AtomicExpandPass for x86 target. Line of code where it crashed getStrongestFailureOrdering . In release build were assertions removed it falls down into Monotonic case anyway.
• bug fixed: wrong calculation of struct offset for Vectorized Structs. Root case: vector was wrapped into single element struct like < >and any try to get offset for member 1+ returns garbage (or crash on assert in debug version of llvm). Workaround – getting element storage size and multiply by index

Bonus track: github action workflows to build native libraries

commit While macos-latest is still pointing to MacOSX 10.15 workflows are not able to build m1 macosx-arm64 target. x86_64 can be build today and arm64 will be available once macosx-11 is opened to public. Worflows allow to build libhfs , libmobiledevice , libllvm natives for MacOSX. In case of success build new branch with artifacts is pushed. Then it can be merged into master.
Build are triggered manually and are parametrized:

Источник

Новым Mac с Apple M1 пока не хватает нативного софта и сред разработки

MacBook Air, MacBook Pro и Mac mini с новым чипом Apple Silicon М1 с ARM-архитектурой уже поступили в продажу. MacBook Air на базе M1 эмулирует код x86_64 с помощью Rosetta 2. Однако, хотя Apple позаботилась о том, чтобы ее собственные приложения для MacOS Big Sur были готовы к моменту выпуска, многие проекты с открытым исходным кодом и коммерческие приложения еще не перестроились на работу с Arm64.

Microsoft выпустила универсальную сборку бета-версии Mac Office 2019, содержащую двоичные файлы x86_64 и Arm64. Но пока нет универсальной сборки выпуска Office с поддержкой M1. Точно так же популярный редактор кода Microsoft Visual Studio Code имеет экспериментальную сборку Arm64, а универсальная сборка запланирована только на конец этого месяца.

Adobe показала бета-версию Photoshop для Arm в Windows и macOS. В бета-версии пока отсутствуют некоторые инструменты. Adobe отмечает, что новые функции будут добавлены в ближайшие недели. Компания планирует к концу 2020 года выпустить встроенную версию Lightroom.

Google во вторник представила Chrome 87 с поддержкой Apple Silicon, хотя, похоже, встроенная в браузер система DRM Widevine по-прежнему полагается на Rosetta.

Тем, кто надеется запустить собственные версии профессиональных приложений для творчества, не приходится ждать многого. Avid, например, все еще работает над обеспечением поддержки Intel в macOS Big Sur для таких приложений, как Pro Tools и Media Composer.

Всем, кто хочет запустить Windows на Apple Silicon Mac, тоже не повезло: технология Apple Boot Camp недоступна в новом режиме. И обещанный новый уровень виртуализации для оборудования Apple Silicon еще не вышел, поэтому версии VMware Fusion и Parallels для Arm64 пока находятся в стадии разработки.

Oracle не сообщает, будет ли она переносить свой гипервизор VirtualBox на M1.

Docker, широко используемый разработчиками, хотя и может работать на оборудовании M1, но зависит от других проектов с открытым исходным кодом, таких как язык программирования Go и кроссплатформенный проект Electron.

Бенджамин де Сен-Паэр-Готч, главный менеджер по продукту в Docker, объяснил, что проект запускает виртуальную машину под Docker Desktop, но возможность будет недоступна, пока Apple не выпустит свой уровень виртуализации, а Docker не адаптирует свой код. Проблема с DTK присутствует и на старом процессоре A12Z.

Golang стремится к совместимости с Apple Silicon в феврале с выпуском Go 1.16.

Команда Rust предлагает кросс-компилятор уровня 2, который выводит собственный код Arm, подходящий для работы на Mac M1.

Тем временем Electron добавила поддержку Apple Silicon в версии 11.0.0-beta.1 в прошлом месяце и в последующих сборках. Версия 12.0.0 выйдет 19 ноября. Сэмюэль Аттард, старший инженер-программист в Slack и один из сопровождающих проекта Electron, посоветовал разработчикам включать собственный двоичный код Arm64 в сборки приложений. По его словам, хотя приложения x86_64 Electron будут работать под управлением Rosetta 2, «производительность будет значительно снижена».

Менеджер пакетов macOS Homebrew также еще не перешел на Apple Silicon из-за нерешенных проблем во многих пакетах, которые он обрабатывает. Около дюжины из них, включая Gradle, Maven и Jenkins, перечислены как ожидающие поддержки Apple Silicon в OpenJDK, который только что вышел.

Компилятор GCC еще не получил поддержки Apple Silicon, и это заставило некоторых утверждать, что всем, кто серьезно относится к научным вычислениям, следует избегать моделей Mac на основе M1, пока ситуация не улучшится.

Разработчики языка программирования R подтвердили, что он хорошо работает в режиме эмуляции, но пока недоступен для запуска на Apple Silicon, поскольку R зависит от наличия компилятора Fortran 90, совместимого с Apple Silicon. «Мы надеемся, что пригодный для использования компилятор Fortran 90 для Apple Silicon будет доступен относительно скоро, поскольку разрабатываемая версия GFortran, похоже, уже работает», — отметили Томас Калибера и Саймон Урбанек.

Аналогичная ситуация и с языком программирования Julia.

В ходе конференции WWDCэтим летом в Apple пообещали предоставить исправления в M1 примерно для 30 проектов с открытым исходным кодом.

Источник