Опыт переноса пары приложений на Apple Silicon

Волею судеб и компании Apple пришлось тут перенести пару приложений на Apple Silicon (M1) и этот опыт хочется описать.

Я не думаю, что сделал какие-то фундаментальные открытия, но вдруг кому-то данный текст будет полезен…

Перенос на ARM/создание ARM64-приложения

По счастью, все используемые нами библиотеки умеют собираться под ARMv8, то есть там нет жесткой привязки к x86.

Многие из них умеют в оптимизацию под ARM-NEON и в этом месте возможна засада:  на Linux/Android принято получать информацию о возможностях ARM-CPU через getauxval() или через чтение в /proc/, ничего такого на macOS нет. Зато на macOS нет (пока!) разнообразия процессоров, весь (один) процессор который используется умеет NEON.

Соответственно, нужно поискать определение типа/возможностей ARM CPU и лишнее оторвать. Из используемых библиотек, это пришлось делать только у libdeflate, у остальных либо можно убрать определение возможностей CPU (libpng), либо оно уже убрано под #ifdef (libjpeg-turbo).

Библиотеки «без SIMD-наворотов» просто собираются.

Некоторое количество веселых минут доставила библиотека oneTBB (бывшая TBB): версия 2021.01 (актуальный релиз) собирается, но

1. Несколько тестов не проходит
2. Они еще и неустойчиво не проходят, ну скажем из десяти запусков теста  4 успешных, а 6 – нет.
3. Не проходят ВАЖНЫЕ для нас тесты (parallel-reduce, например).

Чтение issues как-то не помогло, ну то есть открытых issues для Apple Silicon я не увидел.

По счастью, master-ветка отличается в лучшую сторону: часть тестов все еще не проходит, но все они относятся к resumable tasks, которых мы у себя не используем (а значит и хрен с ними пока).

Теоретически, с TBB можно вернуться обратно на QtConcurrent, но мы только вот перешли в обратном направлении.

В остальном же: С++ приложение (RawDigger) просто собирается и просто работает. Изменения кода – две строчки, чтобы в About показывал, что оно ARM64.

SSE-код

C FastRawViewer все конечно веселее, потому что там МНОГО кода на SSE/AVX intrinsincs.

По счастью, весь AVX-код – под #ifdef (потому что для 32-битной версии мы AVX не компилировали), а значит надо перенести только SSE-код (который у нас SSSE3).

Опять же по счастью, есть готовые решения, из которых было рассмотрено два:

• SIMDe: переносимая реализация SIMD.
  Предполагается, что все _mm_... заменяем на simde_mm… (аналогично с типами переменных) и все работает.
  Соответственно, делаем глобальный поиск-и-замену и все работает.
  На деле – быстро закопались в ругань компилятора, что известные ему SSE-вызовы определены не так – ну и бросили.
• Sse2neon: оказалось прямо РЕШЕНИЕМ.
  Включаешь sse2neon.h вместо *intrin.h и все работает.
  Ну если совсем точно, то нужно в sse2neon.h еще убрать реализацию _mm_malloc/_mm_free, поскольку они в macOS есть и так – и на этом все
  Более не пришлось делать НИЧЕГО, весь SSE-код заработал и тесты проходят.

Помимо SSE-кода пришлось дотачивать

1. Конверсию из FP32 в FP16 и наоборот. Поскольку в  NEON есть готовые инструкции для этого, нужно было написать примерно 10 строчек кода.
2. (примитивное, поскольку процессор пока один) определение возможностей CPU, просто две однострочных функции, возвращающих «AVX нету» и «FC16 есть».
3. Прибить гвоздями GPU capabilities (что есть поддержка FP16)

На этом, опять же, все. Получилось примерно три десятка ‘#ifdef ARM’ на весь проект.

Результат работает несколько быстрее, чем бинарная трансляция, такой уж большой разницы нет потому что на Apple M1 мы явно GPU-bound.

UPDATE: ускоренная (с прочищенными тормозными местами) версия FastRawViewer в native-режиме работает примерно в полтора раза быстрее, чем при бинарной трансляции, есть за что бороться.

Создание Universal Binary

Если вы собрали приложение под ARM (а под x86 оно и так собирается), то создание Universal Binary (одного бинарника под две архитектуры) – это чисто техническая задача.

Ее можно решать двумя способами

1. Делать две сборки и склеивать результаты при помощи lipo
2. Склеить составные части заранее и собирать собственно приложение сразу под две архитектуры.

Мы пошли по второму пути. Идти по первому пути нужно в том случае, если x86 и arm64 версии собираются с разными версиями macOS SDK (например, если вы хотите совместимости с очень старыми версиями Mac OS X), но это не наш случай.

Общие слова

Сборка через clang -arch arm64 -arch x86_64 – это, на самом деле, две последовательные компиляции с одними и теми же параметрами компилятора, порождающие сдвоенный выход: бинарник (объектник, библиотека) один, а в нем две секции под архитектуру.

Соответственно, никаких -DHAVE_SSE или -DHAVE_NEON в командной строке компилятора быть не должно, все подобные архитектурно-зависимые куски должны разруливаться не в командной строке компилятора (линковщика, архиватора), а в компилируемых исходниках внутри (#ifdef __aarch64__ … #else), как именно это сделать – ну дело десятое.

Библиотеки

Как я уже писал ранее, современные системы сборки (cmake, qmake, configure) в общем случае не приспособлены для сборки универсальных библиотек под разные архитектуры (именно потому, что часть конфигурации платформы обычно засовывается в командную строку компиляторов).

Удобнее оказалось не чинить это в каждой отдельной библиотеке, а

• Собрать отдельно под каждую платформу (я это делал на родной платформе, но это не обязательно, кросс-компиляцию сейчас все умеют)
• Склеить в универсальные бинарники (через lipo)

В принципе, даже и клеить не обязательно, линкер умеет -L ../x86/ -lblabla_x86 -L…./arm/ -l blabla_arm, так вполне можно линковать статически (динамически, скорее всего, тоже, но не пробовал; естественно для динамической линковки dylib должны иметь разные имена). Линкер при этом предупреждает, что библиотеки не той системы, но это предупреждение можно смело игнорировать.

Для склейки больших проектов есть удобная утилита makeuniversal которая клеит прямо папки (то есть все бинарники, библиотеки, dylib которые найдет в подпапках), исходно изобретена для склейки (огромного) Qt, но успешно клеит и проекты поменьше.

Собственно приложение

Собственно, все сказано выше: выбор архитектурно-зависимого куска кода не должен производиться снаружи, в этом случае все соберется.

Все шаги после сборки (формирование полного app bundle без внешних зависимостей, подпись, нотаризация) ничем не отличаются от сборки под одну платформу.

До сих пор нет уверенности, что Universal binary лучше, потому что оно получается, очевидно, примерно вдвое больше. Плюс один – пользователю не нужно думать какую версию скачивать (а что он скачает на несколько /десятков/ мегабайт больше и что у него будет занято больше места на диске – ну переживет).