http://hilbert-space.de/?p=22Arm Неон Intrinsics против ручной сборки
На этом сайте, который совсем от его показывает, что рукописный ASM даст гораздо большее улучшение, то встроенные функции. Мне интересно, действительно ли это настоящая правда даже сейчас в 2012 году.
Итак, оптимизация компиляции улучшена для встроенных функций с использованием gnu cross compiler?
Мой опыт заключается в том, что внутренности не стоило проблем. Слишком легко для компилятора ввести дополнительные шаги разгрузки/загрузки регистров между вашими внутренними функциями. Усилия заставить его прекратить делать это сложнее, чем просто писать материал в необработанном NEON. Я видел такие вещи в довольно недавних компиляторах (включая clang 3.1).
На этом уровне я нахожу, что вам действительно нужно точно контролировать, что происходит. У вас могут быть всевозможные ларьки, если вы делаете что-то совсем не так. Выполнение этого в intrinsics чувствует, как операция с перчатками сварщика. Если код настолько критичен по производительности, что мне вообще нужны внутренние функции, то внутренние свойства недостаточно хороши. Может быть, у других есть различия.
Это соответствует моему опыту с ARM/Neon. Для x86/SSE и PowerPC/AltiVec компиляторы достаточно хороши, что код SIMD, написанный с помощью встроенных средств, довольно сложно превзойти ассемблером, но генерация кода Neon (с gcc по крайней мере), похоже, не так хороша, и это не сложно обыграть Neon intrinsics SIMD-код в 2 раза, если вы готовы к сборке ассемблера. –
2x соответствует моему опыту, тоже. Мы не говорим о маленьких хитростях здесь, и я даже не настолько хорош в этом. –
Ditto - Я заметил, что многие вещи, которые вы можете сделать в ассемблере, чтобы помочь производительности, не могут быть выражены через встроенные функции, поэтому, если компилятор достаточно умен, чтобы делать эти вещи (например, обновления регистра адресов), вам не повезло. –
Мне пришлось использовать функции NEON в нескольких проектах для переносимости. По правде говоря, GCC не генерирует хороший код из NEON intrinsics. Это не слабость использования встроенных функций, а инструментов GCC. Компилятор ARM от Microsoft производит отличный код из NEON intrinsics, и в этом случае нет необходимости использовать язык ассемблера. Переносимость и практичность будут определять, что вы должны использовать. Если вы можете обрабатывать язык ассемблера, напишите asm. Для моих личных проектов я предпочитаю писать критически важный код в ASM, так что мне не нужно беспокоиться о том, что компилятор с ошибкой/худшим образом испортил мой код.
Обновление: Компилятор Apple LLVM попадает между GCC (худшим) и Microsoft (лучше всего). Это не очень хорошо сочетается с чередованием команд и оптимальным использованием регистров, но по крайней мере он генерирует разумный код (в отличие от GCC в некоторых ситуациях).
Update2: Компилятор Apple LLVM для ARMv8 был значительно улучшен. Теперь он отлично справляется с созданием кода ARMv8 из C и внутренним.
Почему бы не назвать имя, которое вы нашли, работает хорошо? RVDS? Или что-то другое? –
Другая компания - Microsoft. Их компилятор ARM занимает верхнюю отметку. Люди GNU не любят слышать, как инструменты MS превосходят, но это правда. – BitBank
Я использую для работы с GCC, а оптимизация свойств довольно плохая. :( Я никогда не знал, что компилятор Microsoft настолько хорош в этом. Позвольте мне проверить мои коды и посмотреть, как это происходит. –
Так что этот вопрос четыре года, в настоящее время, и до сих пор появляется в результатах поиска ...
В 2016 году все гораздо лучше.
Много простого кода, который я транскрибируется от сборки встроенных функций теперь оптимизировано лучше составителями, чем мне, потому что я слишком ленив, чтобы сделать работу конвейера (за сколько различных трубопроводы в настоящее время?) , в то время как компиляторы просто нуждаются в том, чтобы я передавал право --mtune=.
Для сложного кода, в котором распределение регистров может быть затруднено, GCC и Clang оба могут производить медленнее, чем рукописный код, в два раза ... или три (иш). Это в основном на разливах реестра, поэтому вы должны знать из структуры вашего кода, является ли это риском.
Но они оба порой имеют неутешительные аварии. Я бы сказал, что сейчас это стоит того риска (хотя мне платят за риск), и если вам что-то ударит, то напишите ошибку. Таким образом, все будет улучшаться.
Возможно, вы правы, в наши дни компиляторы лучше, но это все еще недостаточно. Как я уже упоминал выше, вы можете написать достойно выполнение подпрограмм в intrinsics, при условии, что вы знаете NEON, и, к сожалению, сеть залита тусклыми примерами NEON, написанными во внутренности, особенно реализации AOSPs NEON - это плохая шутка. коды легкомысленно, не прочитав техническое справочное руководство ARM. –
Обновление состояния 2017: множитель с плавающей матрицей asm 4x4 запускается почти в три раза быстрее, чем версия встроенного программного обеспечения, также написанная мной. (Clang, Android Studio 3.01 встроенный, встроенный инструмент версии 27.0 .1, режим ARM) Все еще чистая трата времени. –
Эй, мой сайт не устарел. На данный момент у меня есть еще одна работа. :-) –
Ваш сайт потрясающий. Я провел там много времени, пытаясь понять это. –