Comments 21
SSE2 — это, конечно, здорово; и хорошо, что компиляторы подобрались вплотную к автоматической векторизации.
Но вот в чём вопрос — счас широко распространён такой девайс, Intel Core iX (3, 5,7), неважно. У него внутри свой хорошо оптимизированный под векторные инструкции RISC-агрегат. У этого агрегата есть ассемблер, называется SSE4.X + AVX. То, что этот девайс умеет ещё и x86 код «исполнять» (ну, как «исполнять», эмулировать в микрокодах) — это такое legacy, мало связанное с тем, что он хорошо умеет на самом деле. Intel рады бы отказаться от legacy, да пока не могут.
Так вот, суть вопроса: когда же хотя бы родные Intel-компиляторы смогут воспользоваться этими преимуществами? Счас кроме как раскладывать вручную алгоритм в базис из псевдофункций intrinsics, которые транслируются в этот самый SSE-ассемблер, путей нету никаких.
Непорядок, не находите?
Но вот в чём вопрос — счас широко распространён такой девайс, Intel Core iX (3, 5,7), неважно. У него внутри свой хорошо оптимизированный под векторные инструкции RISC-агрегат. У этого агрегата есть ассемблер, называется SSE4.X + AVX. То, что этот девайс умеет ещё и x86 код «исполнять» (ну, как «исполнять», эмулировать в микрокодах) — это такое legacy, мало связанное с тем, что он хорошо умеет на самом деле. Intel рады бы отказаться от legacy, да пока не могут.
Так вот, суть вопроса: когда же хотя бы родные Intel-компиляторы смогут воспользоваться этими преимуществами? Счас кроме как раскладывать вручную алгоритм в базис из псевдофункций intrinsics, которые транслируются в этот самый SSE-ассемблер, путей нету никаких.
Непорядок, не находите?
Первые два предложения комментария — истина. Остальное — никак нет. Объяснять подробнее здесь не буду.
Вам прямая дорога на мой вебинар. Если нет времени 27ого, то через несколько дней будет доступна его запись.
Вам прямая дорога на мой вебинар. Если нет времени 27ого, то через несколько дней будет доступна его запись.
Скажите, а на вебинаре будет затронута тема про SSE4.Х, или вы планируете ограничиться примерами SSE2, по которым, собственно, вопросов и нету?
Не смог найти этого на сайте
Не смог найти этого на сайте
я покажу пример AVX. Но если есть конкретные вопросы по SSE4 -давайте, отвечу.
Нет, ну что за хамство такое «Вы не правы, но объяснять я здесь не буду». Много ли читателей посмотрят тот вебинар? Объясните здесь, в чем braindamaged не прав.
Это не хамство, а невозможность объяснить в паре предложений то, что объясняется вкратце за час. Я же сказала, braindamaged не прав во всем :) Внутри процессора нет ассемблера; отказаться от скалярных инструкций нельзя, так как не весь код можно сделать векторизуемым, а компиляторы, причем, не только Intel давно и успешно автоматически генерируют векторные инструкции в подавляющем большинстве случаев из тех, когда это теоретически возможно.
и еще — фильм такой есть «День Выборов». Там одного персонажа просят убрать последнюю (нецензурную) строчку предвыборного стихотворения. Но он отказывается, говоря, что все оно только ради последней строчки и писалось.
Так вот, можете считать, что весь пост и писался ради заключительного приглашения на вебинар :)
Так вот, можете считать, что весь пост и писался ради заключительного приглашения на вебинар :)
Кто-нибудь может доступно объяснить, что такое векторизация?
я покажу пример AVX. Но если есть конкретные вопросы по SSE4 -давайте, отвечу.
Прямо здесь? Окей. Не секрет, что SSE4.x предназначается для ускорения процедур криптографии и обработки видеопотоков.
Скажем, есть задача нахождения двумерной разницы между двумя соседними кадрами (прямоугольные массивы), умноженных на некоторый коэффициент. Или задача размытия изображения.
Можете привести пример кода, который будет успешно свекторизован в SSE 4.1/4.2 компилятором Intel? Желательно указать использованные хинты, если они есть.
Скажем, есть задача нахождения двумерной разницы между двумя соседними кадрами (прямоугольные массивы), умноженных на некоторый коэффициент. Или задача размытия изображения.
Можете привести пример кода, который будет успешно свекторизован в SSE 4.1/4.2 компилятором Intel? Желательно указать использованные хинты, если они есть.
Давайте пойдем с другого конца. Можете привести пример кода, который НЕ будет свекторизован в SSE4.x, хотя, вроде-бы, должен? Будем разбираться.
А в общем случае, берем программу, скомпилированную с /QxSSE4.x, в которой точно НЕ используются интринсики и проверяем ее с помощью SIMD Check (про нее я упоминала здесь — habrahabr.ru/company/intel/blog/94381/ ). Программа показывает наличие векторных SSE4 инструкций, что и означает автовекторизацию.
А в общем случае, берем программу, скомпилированную с /QxSSE4.x, в которой точно НЕ используются интринсики и проверяем ее с помощью SIMD Check (про нее я упоминала здесь — habrahabr.ru/company/intel/blog/94381/ ). Программа показывает наличие векторных SSE4 инструкций, что и означает автовекторизацию.
А как на счет целочисленной (char, short, int) векторизации циклов — поддерживают ли ее компиляторы?
К вопросу о понимании фразы о преждевременной оптимизации.
Сначала померь — потом оптимизируй, но потом опять померь.
Сначала померь — потом оптимизируй, но потом опять померь.
Большинству современных компиляторов, похоже, можно задавать вопрос:
— Вам помочь или не мешать?
И компилятор, с большой вероятностью, попросит не мешать.
— Вам помочь или не мешать?
И компилятор, с большой вероятностью, попросит не мешать.
В нашем компиляторе есть оптимизация обратная развертке — свертка (reroll), но она почему-то здесь себя не проявила. Я посмотрел совсем простой пример — не работает.
Было бы интересно посмотреть, что сообщает компилятор о причинах, почему он не сделал векторизацию. (-Qvec_report3). Если цикл предварительно не свернуть, то наш автовекторизатор создает неэффективный код и заполняет векторные регистры поэлементно. Поэтому, на мой взгляд, #pragma simd — это ложная альтернатива для получения удовольствия от векторизации. Нужно выбирать — выгода от векторизации + развертка по умолчанию (ее делает сам автовекторизатор) или удовольствие от ручной развертки + неэффективной векторизации. Есть еще #pragma unroll (N), но у меня сложилось мнение, что для векторизованных циклов эта возможность не работает.
И много встречается таких примеров ручной развертки?
Было бы интересно посмотреть, что сообщает компилятор о причинах, почему он не сделал векторизацию. (-Qvec_report3). Если цикл предварительно не свернуть, то наш автовекторизатор создает неэффективный код и заполняет векторные регистры поэлементно. Поэтому, на мой взгляд, #pragma simd — это ложная альтернатива для получения удовольствия от векторизации. Нужно выбирать — выгода от векторизации + развертка по умолчанию (ее делает сам автовекторизатор) или удовольствие от ручной развертки + неэффективной векторизации. Есть еще #pragma unroll (N), но у меня сложилось мнение, что для векторизованных циклов эта возможность не работает.
И много встречается таких примеров ручной развертки?
Ошибся. #pragma unroll (N) учитывается автовекторизатором. Т.е. можно эксперементировать и выбирать уровень развертки оптимальный для обрабатываемого векторизованного цикла. Но N — будет число итераций уже векторизованного цикла.
Я смотрела причины невекторизации, но, за давностью лет, естественно, не помню. #pragma simd по моим воспоминаниям давала такой же ассемблерный код, как и свертка цикла. Но, опять таки, за давностью лет могу ошибаться. Зато точно помню, что производительность кода не отличалась. Иначе я бы этот способ не предложила :).
Подобных примеров немало — почти любой open source проект, заточенный на производительность и произвольный компилятор.
Подобных примеров немало — почти любой open source проект, заточенный на производительность и произвольный компилятор.
Sign up to leave a comment.
Помочь компилятору в векторизации? — Лучше просто не мешать