Arm Neon Intrinsics против ручной сборки

Question

https://web.archive.org/web/20170227190422/http://hilbert-space.de/?p=22

На этом сайте, который довольно устарел, он показывает, что рукописный асм дал бы гораздо большее улучшение, чем встроенные. Мне интересно, так ли это сейчас, даже сейчас, в 2012 году?

Так улучшена ли оптимизация компиляции для встроенных функций с использованием кросс-компилятора gnu?

Answer 1

Мой опыт показывает, что внутренняя сущность не стоила проблем.Компилятору слишком просто вводить дополнительные шаги выгрузки / загрузки из регистров между вашими внутренностями.Попытка заставить его прекратить делать это сложнее, чем просто написать материал на сыром NEON.Я видел подобные вещи в довольно недавних компиляторах (включая clang 3.1).

На этом уровне я считаю, что вам действительно нужно контролировать именно то, что происходит.Вы можете иметь все виды киосков, если вы делаете вещи только в неправильном порядке.Делать это по сути - это как операция с надетыми перчатками сварщика.Если код настолько критичен по производительности, что мне вообще нужны встроенные функции, то встроенные функции недостаточно хороши.Может быть, у других здесь есть разный опыт.

Answer 2

Мне пришлось использовать встроенные функции NEON в нескольких проектах для переносимости. Правда в том, что GCC не генерирует хороший код из встроенных NEON. Это не слабость использования встроенных функций, а инструментов GCC. Компилятор ARM от Microsoft создает отличный код из встроенных NEON, и в этом случае нет необходимости использовать язык ассемблера. Портативность и практичность будут диктовать, что вы должны использовать. Если вы умеете писать на ассемблере, пишите asm Для моих личных проектов я предпочитаю писать критичный по времени код в ASM, чтобы мне не пришлось беспокоиться о том, что компилятор с ошибками / неполноценным кодом испортит мой код.

Обновление: Компилятор Apple LLVM находится между GCC (худший) и Microsoft (лучший). Это не очень хорошо с чередованием команд и оптимальным использованием регистров, но, по крайней мере, генерирует разумный код (в отличие от GCC в некоторых ситуациях).

Обновление 2: Компилятор Apple LLVM для ARMv8 был значительно улучшен. Теперь он отлично работает, генерируя код ARMv8 из C и встроенных функций.

Answer 3

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

В 2016 году дела обстоят намного лучше.

Большая часть простого кода, который я переписал с ассемблера на встроенную, теперь оптимизирована компиляторами лучше, чем я, потому что мне лень выполнять работу конвейера (для скольких различных конвейеров сейчас?), в то время как компиляторы просто нуждаются во мне, чтобы передать права --mtune=.

Для сложного кода, где распределение регистров может быть затруднено, GCC и Clang могут по-прежнему генерировать код медленнее, чем рукописный, с коэффициентом два ... или три (иш). В основном это связано с разливами реестра, поэтому по структуре вашего кода вы должны знать, является ли это риском.

Но у обоих иногда случаются неутешительные происшествия. Я бы сказал, что прямо сейчас это стоит риска (хотя мне платят за риск), и если вас что-то поразит, тогда сообщите об ошибке. Таким образом, ситуация будет улучшаться.

Answer 4

К настоящему времени вы даже получаете автоматическую векторизацию для простого кода C, и встроенные функции обрабатываются правильно: https://godbolt.org/z/AGHupq