Комментарии 14
НЛО прилетело и опубликовало эту надпись здесь
Ну что тут сказать. Да, в десктопных вариантах планируются лишь микроархитектурные изменения. Но вот когда выйдет серверный вариант с поддержкой AVX-512, то надо чтобы и ПО использовало эти инструкции. Я надеюсь эта статья и поможет разработать такой avx-512 код, причем с масками, это действительно очень эффективный инструмент.
Чтобы ПО использовало эти инструкции, нужны разработчики с опытом их применения и отладки кода на реальном железе, а не в эмуляторе.
Это верно. Но хотелось бы добавить, что количество инструкций на сегодняшний день и в AVX2 уже довольно велико, а когда будет AVX512 оно будет еще больше. И уже вообще сложно понять, где можно эффективно применить ту или иную инструкцию. Вот к примеру, понятно что раз в avx512 регистры в два раза шире то и данных за одну итерацию можно обработать в два раза больше. А вот маски можно применять в другом аспекте, как и рассказано в статье.
А разработчики должны отлаживать и тестировать всё исключительно на сервере?
Нет не обязательно. Для отладки AVX512 кода существует инструмент sde. Он позволяет выполнять код, содержащий AVX 512 инструкции.
Правильно ли я понимаю, что sde бесплатно для использования в коммерческих целях?
Даёт ли он равномерное замедление для поддерживаемых и не поддерживаемых на хосте операций, чтобы можно было оценить изменение производительности при использовании, например, avx512 против avx2?
Даёт ли он равномерное замедление для поддерживаемых и не поддерживаемых на хосте операций, чтобы можно было оценить изменение производительности при использовании, например, avx512 против avx2?
я боюсь насчет использования в коммерческих целях вопрос вне моей компетенции, но
sde использует другой инструмент — pintool
…
Intel SDE is built upon the Pin dynamic binary instrumentation system and the XED encoder decoder.
…
Distribution
Pin is proprietary software developed and supported by Intel and is supplied free of charge for non-commercial use.
Мысль кстати интересная измерять замедление вместо ускорения. Но тем не менее хотя с помощью sde можно исполнить avx512 код, но вот измерить производительность нельзя, поскольку в sde не заложено описание микроархитектуры.
sde использует другой инструмент — pintool
…
Intel SDE is built upon the Pin dynamic binary instrumentation system and the XED encoder decoder.
…
Distribution
Pin is proprietary software developed and supported by Intel and is supplied free of charge for non-commercial use.
Мысль кстати интересная измерять замедление вместо ускорения. Но тем не менее хотя с помощью sde можно исполнить avx512 код, но вот измерить производительность нельзя, поскольку в sde не заложено описание микроархитектуры.
Т. е. можно только гадать, будет ли ускорение на avx512 относительно avx2, а реальные оценки строить только по новым xeon'ам на skylake. А значит, значительной доле разработчиков фактически невозможно оценить прирост производительности от avx512, и оно пока нафиг не нужно.
Ну почему же гадать? Процессоростроение — очень строгая дисциплина, с кучей полезных инструментов, даже когда кристалл появится лет через 7, и у Интела всегда есть пара тузов в загашничке, чтобы померить изменения в производителности для измененного или планируемого new instructions set.
(И sde здесь очень важный инструмент, т.к. им занимается ровно тот же человек, участвующий во всех совещаниях по расширению instruction set, и пишуший декодер XED, используемый во всех ну или в большинстве интеловских симуляторах разного уровня подробности)
В данном случае flow предполагается таким: вы переделываете код с применением расширений (расширяя свой компилятор или через assembler), убеждаетесь на sde что все работает, запускаете там же его с PIN-LIT, записываете измененные трассы (LIT) исполнения, и уже эти трассы изучаете (не вы, скорее всего, а специально обученный performance engineer или microarchitecture engineer) в потактовом симуляторе типа keiko.
Если вы большой и важный клиент, типа Microsoft, то такое низкоуровневое взаимодействие давно налажено, и все инструменты у нужных людей уже есть, но если же пока нет настолько близкого контакта и у вас какой high-profile проект, то можно через SSG DRD запросить помощь и выйти на нижегородскую команду performance инженеров. Они помогут.
P.S.
Я уже пару лет не в Intel, т.ч. детали могли слегка измениться
(И sde здесь очень важный инструмент, т.к. им занимается ровно тот же человек, участвующий во всех совещаниях по расширению instruction set, и пишуший декодер XED, используемый во всех ну или в большинстве интеловских симуляторах разного уровня подробности)
В данном случае flow предполагается таким: вы переделываете код с применением расширений (расширяя свой компилятор или через assembler), убеждаетесь на sde что все работает, запускаете там же его с PIN-LIT, записываете измененные трассы (LIT) исполнения, и уже эти трассы изучаете (не вы, скорее всего, а специально обученный performance engineer или microarchitecture engineer) в потактовом симуляторе типа keiko.
Если вы большой и важный клиент, типа Microsoft, то такое низкоуровневое взаимодействие давно налажено, и все инструменты у нужных людей уже есть, но если же пока нет настолько близкого контакта и у вас какой high-profile проект, то можно через SSG DRD запросить помощь и выйти на нижегородскую команду performance инженеров. Они помогут.
P.S.
Я уже пару лет не в Intel, т.ч. детали могли слегка измениться
Если этого всё-равно не умеет компилятор, почему бы просто не взять видеокарту того же самого Скайлейка и не прикрутить OpenCL? Получится просто по дефолту энергоэффективнее и, скорее всего, быстрее. И код не будет напоминать сатанинские письмена. Если этим всем приходится заниматься вручную, то сакральный смысл AVX2 от меня ускользает.
Вот бы еще гиганты, например Adobe, занимались такой оптимизацией…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Приемы использования масочных регистров в AVX512 коде