NEON на ARM Cortex-A53 (Raspberry Pi 3)

собирай с march=arm-v8a+crc mtune=cortex-a53 mfpu=crypto-neon-fp-armv

подробости https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

мимокрокодил

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

Как не компиляй твой арм такое тормозное говно, что на бу штеуде скомпиленое без оптимизаций быстрее работает. Маняйнить это вообще nuff said. Опрос суксесс стори не интересен, тк на разном железе прирост разный.

Как не компиляй твой арм такое тормозное говно

Твой софт - говно (с)
ARM - заебца, но юзерам нужны свистоперделки, а разработчикам гигабайты json'а и xml'ей на каждый чих.

Ну да, и вселенная с её законами не та))

Тулчейн НЕ ТОТ

Ещё надо сказать что neon хорош только на Cortex-a8 (даёт наиьольший прирост чем без). На A7 и A15 neon несколько подрезали. Под neon часто компилер генерит не слишком хороший код и наибольший прирост утдаётся получить написав на ассемблере. Но это сильно зависит от задачи. Но односзначно даже при просто компиляции, при включённой векторизации, если завекторизовалось нормально - будет быстрее. К сожалению с векторизацией в последних компиляторах как-то не очень, во времена gcc-3.x было повеселее. Ещё надо учитывать что многие инструкции neon требуют строгого выравнивания, и новый gcc (>= 4.x) если не может выровнять, кладёт болт. Если оптимизация важна, нужно вручную постараться через __attribute__. Там достаточно много тонкостей.

Типичный случай - если gcc не знает заранее, что аргументы функции выровнены, он не будет векторизовать код с этими аргументами, их нужно специально маркировать, и иногда сплясать с бубном. Раньше это всё само делалось компилятором, но видать пришел кто-то умный и сказал, что так низзя и надо заставить народ работать.

mfpu=crypto-neon-fp-armv

вот ты олень ленивый, скопипастил даже по ссылке не сходил, очепятка там, ищи сам.

If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=‘neon’), note that floating-point operations are not generated by GCC’s auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.

Я обновил исходное сообщение - у меня оказался дефектный проц. Код с неоном даже приводит к завису, но при этом в три потока (вместо четырёх) есть и прирост в скорости, и не зависает.

Уверен, что не просто ПИЧОТ при полной нагрузке?

Уверен - бинарник без неона в те же самые 4 потока не вешает систему.

Припекание зависит от количества используемых транзисторов, которое на разных инструкциях отличается.

Интересно. Я думал что там в каждом вычислительном юните встроены все инструкции, а не где-то отдельно. Сейчас замерю на трёх потоках. Upd: с тремя потоками 66-69 градусов, с четырьмя ушло в ребут уже при 64.

Я уверен что проблема в процессоре, потому что при перегреве сначала был бы тротлинг (на RPi он есть). А тут - ребут в первые 5 секунд после запуска бинарника.

Векторизация перпендикулярна floating point, но да, и это тоже. Когда я этим активно занимался всё было гораздо проще - включаешь neon и векторизацию и получаешь ускорение в 5 раз на 1-ядерном Cortex-A8. Сейчас уже всё не так. Консерваторы, блин.