AVX очень «горячие» инструкции, из-за чего проц нехило сбрасывает частоты при их использовании.

Это как и зачем? Электричество чтоли за меня экономят?

Чтобы проц не расплавился

А смысл вообще есть их использовать тогда? Если один хер частота сбивается

Вот возьми померяй, потом нам расскажешь, есть ли смысл

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

Тебе известны процессоры, которые не сбрасывают частоты на AVX?

Не слушай никого

ЕМНИП, на многих процах есть пенальти, если с них переходишь опять на legacy SSE. А всякую чушь про «сброс частот» не слушай вообще

Вопрос лавсану и другим. Можно ли с помощью с помощью шланга работать с 3-х или 4-х векторами из синглов по типу как это сделано в OpenCL? Типа иметь функции select, min, max, итд., умножать, складывать вектора. Чтобы это всё компилялось в эффективный код

Это слишком низкоуровневая фигня. Сейчас мне приходится для некоторых функций иметь 2 варианта — с SSE-шнягой из этих хедеров и «обычный», где я работаю с массивами. А хотелось бы более кроссплатформенно и высокоуровнево. Чтобы если на машине нет SIMD-инструкций компилялся «обычный» код, если есть — SIMD

Кстати, а почему ты не дал сорс своего чтива, а то похоже на обычный вброс

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

Э, нет. Цикл по флоатам в векторизированные инструкции точно не переделается. Вот по целым — пожалуйста. А сложение/вычитание/умножение флоатов — не ассоциативная операция, так что увы. Разве что с -ffast-math

А вообще меня больше привлекают такие штуки как blendvps. Избавляет код от кучи ветвлений

Интересное чтиво про смешение AVX и SSE, даже когда ты ничего не мешал

https://stackoverflow.com/questions/41303780/why-is-this-sse-code-6-times-slo...

За 2 года уже пофиксили, наверно

Нет никакой магии, только тупой троттлинг. В худшем случае прироста нет.

Амуде. Там прироста от авх нет, потому и нагрева нет, много ходов очка.

Чего-то кроссплатформенного нет пока что, так как ещё не завезли simd в Стандарт

в gcc вроде как пофиксили

Но тут почитал, что AVX, и особенно AVX-512 делают какую-то черную магию с процессорами, при излишнем использовании

никакой черной магии, просто повышенный нагрев от использования

однако в серверных интулях, скорее всего, это не страшно, сильно страдает только десктоп оверклокеров

А сложение/вычитание/умножение флоатов — не ассоциативная операция, так что увы. Разве что с -ffast-math

Не знал, век живи — век учись.

а прироста нет, потому что 256битных FPU нет, со времён бульдозера там 2 блока по 128бит.

Однако, в ZEN2 исправят это досадное упущение

в целом же да, если код пишется не под определённую железку, лучше использовать SSE.

На каких-то моделях использование AVX влечет за собой троттлинг всех ядер сразу. Но серверных среди них вроде бы нету.

Почему систему тестируют (при разгоне) с помощью LinX avx? Поэтому, ага.

https://docs.opencv.org/4.1.0/df/d91/group__core__hal__intrin.html

Это слишком низкоуровневая фигня. Сейчас мне приходится для некоторых функций иметь 2 варианта — с SSE-шнягой из этих хедеров и «обычный», где я работаю с массивами. А хотелось бы более кроссплатформенно и высокоуровнево. Чтобы если на машине нет SIMD-инструкций компилялся «обычный» код, если есть — SIMD

У GCC есть vector extension, который поддерживается также и в clang. https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html https://clang.llvm.org/docs/LanguageExtensions.html#vector-literals. Но это не годится т.к. этот vector extension опять-таки работает далеко не на всех платформах, и надо будет мутить какие-то костыли с ифдефами

Интеловский компилятор ICC этого не поддерживает. Интели изобретали какой-то свой особый Intel® Cilk™ Plus https://habr.com/ru/company/intel/blog/204838/, однако из GCC его в итоге выпилили https://www.phoronix.com/scan.php?page=news_item&px=Cilk-Plus-GCC-Dropping

В Clang этот cilk никогда вроде бы и не поддерживался официально, http://cilk.mit.edu/download/ https://cilkplus.github.io/ вот что-то нагуглилось, там патченный LLVM используют.

Про всякие вижуалстудии и прочие проприетарные компиляторы ничего сказать не могу. Стандартного решения вроде как нет

Хотя не, вру. ICC это расширение поддерживает https://godbolt.org/z/g8Ccb7. И тот же GCC может это под всякие ARM компилировать. Но это все завязано на гнутое расширение, так что переносимым это не назовешь.

#pragma omp simd еще есть

https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/

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

Спасибо. Остановлюсь я на ext_vector_type с небольшой обвязочкой

Для Clang надо ext_vector_type а для GCC vector_size. Вот пример: https://stackoverflow.com/a/48538557

Вообще, можно ограничиться атрибутом vector_size - его и Clang и GCC и даже ICC понимает. А вот ext_vector_type понятен только для Clang. Можешь на godbolt потестить.