Группа исследователей из университета Юты (США) предложила оптимизатор Minotaur для набора компиляторов LLVM, использующий метод на основе решения задач выполнимости формул (SMT Solver) для выявления недостающих оптимизаций в промежуточном представлении кода (LLVM IR), генерируемом оптимизатором LLVM. Minotaur главным образом нацелен на оптимизацию целочисленных векторных инструкций (SIMD), как переносимых, так и специфичных для систем x86_64 (SSE, AVX, AVX2 и AVX-512)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59447
много человекочасов, пропукали не один стул, построили целую науку, добились повышения в 1.3%. Это прогресс ащетаю
Прогресс в навязывании avx2
Ты шутишь? Это целые 1.3%! Нука шляпу сними!
Так потратили человекочасы одна группа и один раз, а 1.3% прироста теперь будут всегда и для всех.Вполне себе выигрыш.
для всех, кто ЭТО использует. А кто будет использовать прилепленныетсбоку васяноподелки ради 1% производительности?
Например, любой крупный облачный оператор. Да и в целом, сэкономить 1% денег через несложные единоразовые телодвижения — хороший бизнес. Надо брать.
для некоторых задач и ускорение на 0.1% это миллионы доларов экономии в год
Ага - полезность науки это растет как длина фрактала к ометаемой площади ....
Покуда учёные не создали perpetuum mobile, как бы мы полезность не определили, она всё-таки конечна. )
Ты пропукал свой комментарий, это прогресс я считаю.
На больших масштабах это могут быть огромные деньги. К счастью они будут потрачены на рождение и воспитание детей не таких как ты
Для каких-нибудь видеоигр один процент - это целый кадр, если метишь в 120 FPS.
разве есть какая-то разница 119 и 120 fps ?
А они учитывают то что многие процессоры тут же включают троттлинг от таких инструкций?
околесицу и чушь про тротлинг при вызове таких инструкций не несите, хорошо? спасибо.
Может троттлинг и не точное определение, но то, что ядра снижают частоту при использовании AVX-* - факт.
Это то же самое и по той же причине. Своеобразный преемптивный троттлинг, avx легко отобрали пальму первенства по нагреву у sse и fpu. Особенно заметно, когда СО в итоге всё же не справляется и легко падает в полноценный троттлинг. Для примера, компиляция вебкита (и хромиума соотвественно) -- единственный процесс из всех пакетов, который выкидывал мой пк в защиту от перегрева (температура на ~20 градусов выше обычной максимальной).
То, что это в принципе самый долгособираемый пакет, вопрос отдельный, троттлить начинало довольно быстро и соответственно всё растягивалось на долго.
Пользуйтесь процессорами AMD, у них частоты одинаковые при любых инструкциях.
А как же быть с тем, что процессоры АМД не показывают реальную температуру на датчиках? Из-за того, что они склеены из различной отбраковки, результаты могут довольно разниться. У них намного жёстче ограничения по рабочим температурам, как из-за материала затворов, так и из-за клея.
какая разница что там на датчиках если процессор не пререгревается и работает нормально без тротлинга?
Это было на самых первых реализациях от интела. Этого уже нет, если укладывается в теплопакет - частота будет та же.Так и AVX-512 за троттлинг и снижение частоты гнобили, а *внезапно* это оказалось просто легкой болячкой первых интеловских реализаций, вон в Zen 4 никакого снижения частоты от AVX-512 не происходит. И теперь даже memcpy() с ним оказывается эффективнее воткнуть во всех программы, а то что когда-то Линус говорил против этого - оказалось частью истории и неактуальной частностью. Прошло время, ошибки изучили, сделали нормально. Вон, ознакомьтесь с бенчмарками phoronix с/без AVX2 и AVX-512.
В процессорах нет инструкций для копирования произвольных кусков памяти?
Нету, проще каждое поколение наращивать количество ядер и продавать. Ой, уже давно уперлись в потребление в пол-киловатта, поэтому чтобы добавить еще больше ядер, половину ядер урезают по частотам под соусом "энергоэффективности и экологии", так можно еще пару лет делать новые "инновационные" поколения процессоров и впаривать хомякам, не внося абсолютно никаких изменений в архитектуру и техпроцесс.
"Прогресс"
>> В процессорах нет инструкций для копирования произвольных кусков памяти?
> Нету,Прекратите распространять мракобесие.
Есть, начиная с 16-ти разрядных 8086.rep movs
В какие-то периоды времени она работала медленнее, чем цикл с предвыборкой из кеша (prefetchnta), но давно ускорили.
> Есть, начиная с 16-ти разрядных 8086.
> rep movs
> В какие-то периоды времени она работала медленнее, чем цикл с предвыборкой из
> кеша (prefetchnta), но давно ускорили.Зачем тогда avx используют для копирования?
И разве это не просто способ повторения копирования одного слова?
>> Есть, начиная с 16-ти разрядных 8086.
>> rep movs
>> В какие-то периоды времени она работала медленнее, чем цикл с предвыборкой из
>> кеша (prefetchnta), но давно ускорили.
> Зачем тогда avx используют для копирования?
> И разве это не просто способ повторения копирования одного слова?Не знаю, зачем. Может маркетинг, или очередной выигрыш на уровне погрешности измерений.
Вот цитата 64-ia-32-architectures-optimization-manual.pdf
2.6.6 REP String Enhancement
REP prefix in conjunction with MOVS/STOS instruction and a count value in ECX are frequently used to
implement library functions such as memcpy()/memset().
...
Fast string (ECX >= 76: excluding REP MOVSB): the processor implementation provides hardware
optimization by moving as many pieces of data in 16 bytes as possible. The latency of REP string
latency will vary if one of the 16-byte data transfer spans across cache line boundary:
...
In order for REP string to operate in “fast string” mode, previous microarchitectures requires address
alignment. In Intel microarchitecture code name Nehalem, REP string can operate in “fast string”
mode even if address is not aligned to 16 bytes.Обратите внимание на "аппаратная оптимизация" (hardware optimization).
Проблема со скоростью копирования была во времена Athlon XP и разобрана в http://files.rsdn.ru/23380/AMD_block_prefetch_paper.pdf
Смысл в том, что память читается не побайтно, а кратно размеру линии кэша, и лишнего загрязнения кэша желательно избегать.
В следующем поколении Intel оптимизировали REP MOVSB и она догнала по скорости оптимизированные циклы.
Там целая эпопея https://stackoverflow.com/questions/43343231/enhanced-rep-mo...
Ага, такой лёгкой болячкой оказалось, что вообще нафиг выпилили из новых процессоров.
Выпилили чтобы зеоны продавать, в них-то avx512 остался.
Выпилили по совершенно другой причине.
И пр какой же? Только не надо вот про зионы, как выше написали, эти рынки вообще не пересекаются.
В любом случае — это весьма стыдное в репутационном смысле решение. Вот представьте лет 20 назад: а давайте мы уберём SSE из наших пентиумов-3, и оставим его только в зионах! Дико? Дико.
Очевидно, потому что малые E-ядра не могут в AVX-512. Скорее всего, тупо не влезло по площади в кремнии и по энергопотреблению, даже если делать в double pumped варианте без добавления новых исполнительных устройств. Регистров больше, более сложный shuffle блок, 64-битный блок векторного умножения.А если спросите "а как же модели без E-ядер", то ответ тоже очевиден - сегментирование рынка. Да, чтобы брали зионы за конский ценник, кому оно действительно надо.
> В любом случае — это весьма стыдное в репутационном смысле решение. Вот представьте лет 20 назад: а давайте мы уберём SSE из наших пентиумов-3, и оставим его только в зионах! Дико? Дико.
С пробуждением. До недавнего времени в Pentium'ах и Celeron'ах не было AVX. Никакого, только SSE.
Так что ничто не ново под луной.
В zen4 avx512 выполняется в 2 инструкции так как ширина канала 256. По факту avx512 там не даёт существенных преимуществ над avx2
Phoronix потестил и смысл очень даже есть: https://www.phoronix.com/review/amd-zen4-avx512
а вот с 512бит шириной канала есть вопросы поскольку штука узкоспециализированная, у интел тоже не дураки чтобы выкинуть поддержку из гражданских моделей, ибо греется сильней и зря занимает полезное место. Можно конечно придумать куда впихнуть, но тут проблема курицы и яйца
Увеличение скорости на 10% против нормативных 2х раз.Avx512 там добавили для галочки. Кстати, как я понимаю многопоточность не будет работать с avx512 в линуксе, так как регистры не сохраняются при переключении задач?
> против нормативных 2х разuwot
https://www.phoronix.com/review/rocket-lake-avx512
https://www.phoronix.com/review/zen4-avx512-7700x> как я понимаю многопоточность не будет работать с avx512 в линуксе
Ну да, а HPC для которых всё затевалось на виндосервере работают. Вон Майкл даже на епике потестил и есть сравнение с "настоящим" avx512 на интелах
https://www.phoronix.com/review/amd-epyc-avx512
https://www.phoronix.com/review/intel-sapphirerapids-avx512/Может посмотреть тесты на железе сперва?
> Кстати, как я понимаю многопоточность не будет работать с avx512 в линуксе, так как регистры не сохраняются при переключении задач?Чего только не прочитаешь в комментах.
Не туда смотрите. Вот вам в TensorFlow и в два раза прирост: https://www.phoronix.com/review/amd-ryzen7040-avx512/7При совершенно том же теплопакете. Да, на райзене, потому что на Ice Lake старая реализация, которая так повышала энергопотребление и из-за этого мобильный CPU снижал частоту. Да, вне задач рендеринга и AI двухкратный выигрыш получить сложно, мало что еще параллелится до такой степени, чтобы 512 бит за раз перемалывать. Но когда что-то параллелится - выигрыш на чистом месте вплоть до двухкратного относительно AVX2 без доп. расхода энергии (8 страница).
> А они учитывают то что многие процессоры тут же включают троттлинг от таких инструкций?А многие не включают.
Вроде, это каждый раз повторяется. Добавляют новые SIMD, не вывозят по тепловыделению, и пока литография не обновится, все процессоры идут бракованные. И не предъявишь ведь как АМД -- ничего не падает.
У АМД была похожая история с совместными блоками -- вроде, ядер много, а используется только половина и остальные стоят ждут. Ещё что-то там с шиной межъядерного взаимодействия было. Всё лучше чем сегфолты, конечно. Но старое железо никуда не девается ведь.
Всё лучше чем проц сгорает если снять кулер.
Тут, конечно, пара человек с сокетом 462 найдётся, но в основном все обновились уже.
А то так можно вспомнить и «всё лучше, чем когда математику неправильно считает».
Они тогда решили сэкономить на блоках для плавающей запятой (1 на 2 ядра). В бульдозерах, вроде. Напрасно.
Работало вообще оно отлично для обычных задач.Да, на всяких расчётах не очень хорошо тянуло в сравнении, хотя там свои нюансы были.
Мне кажется бульдозеры незаслуженно ругали вообще.
Думаю маркетинг подкачал скорее.
А вы посмотрите обзоры и сравнения тех времен, и перестанет казаться.Разделяемый FPU не взлетел потому что, внезапно, программы его активно используют. Напомню, что в случае AMD FPU используется не только для вычислений с плавающей запятой, но и для векторных инструкций. А в Бульдозере, к тому же, использовался сырой процесс, в котором не смогли добиться высоких частот. Вот и получилось, что разделяемый FPU, расчитанный на высокую пропускную способность (throughput) в ущерб задержке (latency), работал на относительно низких частотах.
Смотрел обзоры, видел много некомпетентности.И успешно использовал эти апушки много много лет вплоть до войны.
Не знал с ними горя вообще, играл в танки в фулл аш ди, и прочие вещи делал, даже видео кодировал весьма успешно, хоть и долго.
CPU рендерингом не занимался.
Первой их апушкой у меня был
AMD A10-5800K
Разгонялся вообще отлично.
При этом был не особо то горячим, хотя я его скальпнул в итоге и на жм прилепил вначале так, а потом крышку на место вернул.>расчитанный на высокую пропускную способность (throughput)
Там подсистему памяти(или что-то такое) можно и нужно было гнать, не помню уже что у меня там стояло..
"расчитанный на высокую пропускную способность (throughput) в ущерб задержке (latency)" - вот это про архитектуру NetBurst. Те самые "кукурузные гигагерцы" первых Pentium 4, которые проигрывали ноутбучным Pentium 3 с меньшей частотой. Похоже, что эксперт просто прилепил запомнившуюся фразу куда пришлось.
Да нет, всё "прилеплено" куда надо. Да, NetBurst был расчитан на высокие частоты, ну так он их и брал. А Бульдозер не смог. И кстати, во времена Бульдозера у Intel уже был прорывной Nehalem и появился легендарный Sandy Bridge, которые рвали его как тузик грелку.Кстати, если интересно, вот статейка по Бульдозеру:
https://chipsandcheese.com/2023/01/22/bulldozer-amds-crash-m.../
https://chipsandcheese.com/2023/01/24/bulldozer-amds-crash-m.../
> Да, NetBurst был расчитан на высокие частоты, ну так он их и брал.Но толку не было, потому она (архитектура NetBurst) и породила мем "кукурузные гигагерцы".
> А Бульдозер не смог.
То есть "расчитанный на высокую пропускную способность (throughput) в ущерб задержке (latency)" не относится.
> То есть "расчитанный на высокую пропускную способность (throughput) в ущерб задержке (latency)" не относится.Относится. Почитайте статьи по ссылкам.
Вот сам читай их, подбирай цитаты и подтверждай своё заявление. Мне достаточно курса физики, арифметики, а так же понимания, что такое пропускная способность и частота.
> Вот сам читай их, подбирай цитаты и подтверждай своё заявление. Мне достаточно курса физики, арифметики...Всё понятно, удачи с вашим багажом знаний.
>> Вот сам читай их, подбирай цитаты и подтверждай своё заявление. Мне достаточно курса физики, арифметики...
> Всё понятно, удачи с вашим багажом знаний.Бгг, но ведь ты как то живёшь, не понимая индукцию.
>(SMT Solver)очень медленно будет.
с какого это перепугу? вы, судя по всему, вообще не понимаете, что это и как оно реализовывается в Minotaur. https://arxiv.org/pdf/2306.00229.pdf
почитайте источник исследований и то, откуда скопирована по своей сути статья.условно, вставляя более мощный двигатель в автомобиль вы говорите "медленно будет", потому-что там какя-то мембрана юзается или где-то какая-то реакция идет медленнее невесть бог где. мда уж.
компиляция медленная, не выполнение. SMT - это тяжёлая артиллерия для таких задач, как инверсия хэш-функций. По сути - оптимизированный ветвями и границами брутфорс. Они могут это решить в принципе, но никто не обещал, что за приемлимое время и при приемлимом потреблении памяти. На smt полагаются тогда, когда на всё остальное положиться уже нельзя.
Rewrite Generator -> Rewrites -> Rewrite Rules -> Rewrite
Знают толк в С++
Интересно было бы сравнить с GCC (O3+pgo).
Не заставляй афтаров LLVM посыпать себе голову пеплом. Спиды тестируются на O2 в любом случае.
>Пример оптимизации для Си-кода:Это очень круто, но бывает эти avx инструкции нужны для всяких векторных вычислений, всяких кодировщиком видео, и прочее.
А цикл заменяющий символы в строке может всеже стоит без avx делать?
Другими словами если всё так круто и быстро может вообще отказаться от обычных инструкций и все через avx считать?Правда были уже процессоры которые сразу умели несколько инструкций выполнять... Только же закопали их потому как слишком сложно было несчастным программистам думать, а компиляторы нешмогли.
Или шмогли.
Но процессоры то закопали.И вот опять.
Может я чего-то недопонимаю, но зачем в LLVM вообще для if (*--p == '.') приплетают векторные инструкции вместо примитивной инструкции CMP.
Они цикл разворачивают, как я понимаю.
Но многое остаётся загадкой да.
Внезапно, это прямое назначение векторных инструкций - выполнить одну операцию над кучей данных. А "примитивной" CMP вы будете долго и нудно ковырять эту строку по одному символу за раз.
Стоит ли вообще такое делать без явного указания программиста что именно так нужно делать большой вопрос.У меня есть много вопросов по конкретному примеру вообще.
Как приведенный в новости код векторизировать если неизвестен размер массива?
Если грузить память большими кусками то неизбежно будет захвачен кусок выходящий за пределы массива, и тут могут всякие чудеса вообще происходить.
Нормальная система такого позволять не должна.
Конкретно в этом примере не весь цикл, а только оператор сравнения. Фактически выбросили две бессмысленные операции.Реализовать можно по-разному. Например три цикла, где первый побайтовый до границы кэш линии, затем векторный, и финал опять побайтовый. Или другой вариант – маскировать load/store.
AVX это не сопроцессор. Компилятор может выдать REP MOVSB или использовать быстрые инструкции, благо они все выполняются последовательно и не создают проблем при переключении задач.
Проблемы начнутся если для копирования будут использовать DMA каналы, так как их мало и работают асинхронно.
PS. Процессоры, которые кичатся своей RISC-овостью, могут load/store только с машинными словами, и только выровненными по границе слова.
> PS. Процессоры, которые кичатся своей RISC-овостью, могут load/store только с машинными словами, и только выровненными по границе слова.Не совсем. Хотя у POWER VMX очень интересно сделано: оно игнорирует последние n бит, всегда загружает выровненное слово и отказывается выдавать ошибку. Как результат - программная невыровненная загрузка выполняется в 3 инструкции.
> Реализовать можно по-разному. Например три цикла, где первый побайтовый до границы кэш
> линии, затем векторный, и финал опять побайтовый. Или другой вариант –
> маскировать load/store.Для этого компилятору нужно знать размер массива.
> Стоит ли вообще такое делать без явного указания программиста что именно так нужно делать большой вопрос.Но откуда программисту знать, на каком процессоре код будет выполняться? Можно ли ему за раз 128 бит проверять или 256, а может и все 512?
Если оптимизатор не накладывает ограничений на кратность размера буфера - просто замечательно.
>Но откуда программисту знать, на каком процессоре код будет выполняться?Да просто не от куда, загадка!
Не говоря уже о том, что никогда никакой код и не пытается даже узнать это в рантайме прямо, это ведь невозможно.
Только компилятор может знать, или не может.
Кстати, откуда компилятору знать на каком процессоре будет код выполняться если программист этого не знает?>Можно ли ему за раз 128 бит проверять или 256, а может и все 512?
Программисту ненужно знать сколько там бит и какие конкретно инструкции, достаточно сказать что это должна быть SIMD операция.
Обычно делается это через спец векторные примитивы.
> Не говоря уже о том, что никогда никакой код и не пытается даже узнать это в рантайме прямо, это ведь невозможно.Очень даже возможно. Самый известный проигрыватель mplayer при запуске как раз об этом и сообщает: "Compiled with runtime CPU detection". И, самое главное, использует обнаруженные преимущества.
> Кстати, откуда компилятору знать на каком процессоре будет код выполняться если программист этого не знает?
Об этом ему может сообщить сборщик программы, который, в общем случае, не программист.
> это должна быть SIMD операция
Когда теперь чуть ли не каждый цикл можно автовекторизировать, то проще уже указывать обратное: вот именно тут, пожалуйста, никакой самодеятельности.
> Когда теперь чуть ли не каждый цикл можно автовекторизировать, то проще уже
> указывать обратное: вот именно тут, пожалуйста, никакой самодеятельности.Не знаю.
Я думаю это не такой простой вопрос.
> Как приведенный в новости код векторизировать если неизвестен размер массива?Очевидно, он известен, т.к. p указывает на конец, а name - на начало.
> Если грузить память большими кусками то неизбежно будет захвачен кусок выходящий за пределы массива, и тут могут всякие чудеса вообще происходить.
Никаких чудес, если в рамках страницы памяти. Да, всякие sanitizer'ы и valgrind будут вонять про выход за границы буфера, но на практике всё будет работать без проблем. Такой подход реально применялся раньше, пока sanitizer'ы не стали модными.
> Очевидно, он известен, т.к. p указывает на конец, а name - на
> начало.Да, вы правы, я как-то не так этот кот прочитал.
лучше уже на ассемблере программировать, чем этой фигней заниматься
Так программируй, кто тебе мешает? Покеж заодно что ты там уже наваял.
а я на ассемблере не умею
А что там уметь? Самое время научиться, можешь начать с игр типа https://store.steampowered.com/app/716490/EXAPUNKS/
> if (*--p == '.') *p = '_';Ауч, кэшу больно
>> if (*--p == '.') *p = '_';
> Ауч, кэшу больноМеня больше смущает:
> while (p != name);
Yup. Тоже это усмотрел, ну их нафиг.
Только ыксперты опеннета могут закопать 30-летний опыт Free Software Foundation, Inc. и,
конкретно Jean-loup Gailly.. https://ru.wikipedia.org/wiki/%D0%93%D0%...,_%D0%96%D0%B0%D0%BD-%D0%9B%D1%83:)
... For example, consider this loop, in C, from the compression/decompression utility gzip,
where name is the base address of a string and p is a pointer into the string:do {
if (*--p == '.') *p = '_';
} while (p != name);
https://git.savannah.gnu.org/cgit/gzip.git/tree/util.c#n356
/* ========================================================================
* Make a file name legal for file systems not allowing file names with
* multiple dots or starting with a dot (such as MSDOS), by changing
* all dots except the last one into underlines. A target dependent
* function can be used instead of this simple function by defining the macro
* MAKE_LEGAL_NAME in tailor.h and providing the function in a target
* dependent module.
*/
void
make_simple_name (char *name)
{
char *p = strrchr(name, '.');
if (p == NULL) return;
if (p == name) p++;
do {
if (*--p == '.') *p = '_';
} while (p != name);
}
Тут-то как раз всё нормально. Контекст.
Процессоры, выпущенные в последние лет 15-20 вполне могут распознать обратную итерацию. И даже итерацию в любую сторону с большим шагом, и даже несколько параллельных итераций. Так что с кешем всё в порядке, не переживайте.
Кто Генту хаял из-за ничтожных 3% прироста производительности? Наука - понимать надо.
1.3% - это ниже уровня стат. погрешности. Статья лежит не рецензированная. Такое достижение нормальные рецензенты не пропустят.
Вот не надо пытаться показаться умным, не зная значения термина.
Не, я к этим ребятам не зайду. Пример уж слишком весел.do {
if (*--p == '.') *p = '_';
} while (p != name);Если p не байт, а длина (p - start) в байтах не кратна sizeof(*p), будет интересно :D
Да и если p < start - тоже внезапно окажется не менее весело.
Но если до проверки p > start или установки p = start + X догонит каждый второй студент третьего курса аграрного, то вот с кратностью могут быть проблемы.
> Если p не байт, а длина (p - start) в байтах не кратна sizeof(*p), будет интересно :DЭто будет означать, что один из указателей не выровнен, что значит UB и косяк программиста. На практике надо явно постараться, чтобы этого добиться.
>> Если p не байт, а длина (p - start) в байтах не кратна sizeof(*p), будет интересно :D
> Это будет означать, что один из указателей не выровнен, что значит UBОн имел ввиду "не кратна размеру операнда SIMD инструкции", но сформулировал ошибочно. А указатели на char всегда "выровнены".
А кто сказал, что там char. Из вырванных из контекста строк не видно.
Видно. Там '_' вместо L'_'.
Фантазировать можно в любую сторону. Сравнивать с '_' можно хоть int, хоть double.
> Фантазировать можно в любую сторону. Сравнивать с '_' можно хоть int, хоть
> double.Аноним - игнорим.
Я читаю то, что написано, и написано там было совсем не то, что у вас. И сдаётся мне, что автор имел ввиду то, что он написал, а не то, что кажется вам.
Мне ничего не кажется - я посмотрел и понял листинг в статье. Проблема с гранулярностью касается размера операнда
%1 = icmp eq %0, <46, 46, 46, ... , 46>
Там наверняка отдельных два цикла: один обрабатывает байты пачкой, а второй остаток. Ну и поскольку средняя длина строки меньше размера пачки, оптимизированная часть за пределами синтетических тестов не работает.) Смотрите pdf - в ряде случаев оптимизация приводит к ухудшению результатов тестов.
Открою секрет, чтоб подсчитать определитель матрицы иль
повернуть тело на 146°, полюбасу нужно перебрать все элементы матрицы.
> Пример оптимизации для Си-кода:
>
> do {
> if (*--p == '.') *p = '_';
> } while (p != name);
> Для операции сравнения штатный оптимизатор LLVM сгенерирует биткод для использования инструкций AVX-2:
>
> %1 = shufflevector %0, <31, 30, 29, ... , 0>
> %2 = icmp eq %1, <46, 46, 46, ... , 46>
> %3 = shufflevector %2, <31, 30, 29, ... , 0>Cейчас кто-нибудь, вообще, ещё считает такты процессора?
А то ж окажется, что 250 раз cmp + jnz будет быстрее трех SIMD инструкций
Талантливые программисты:в среднем ускорение составило 2.2%. При тестировании набора SPEC CPU2017 ускорение составило 1.3%.
Патчи к ядру для защиты от очередной дырки в процессоре:
замедление 20..75%, на некоторых задачах до 400%, при применении защиты процессоры иногда взрываются, но, пожалуйста, не волнуйтесь, это только в очень редких случаях, которые хорошо описаны в документации