Разработчики проекта FFmpeg сообщили о реализации новых ассемблерных оптимизаций, в которых, благодаря применению инструкций AVX-512, удалось ускорить некоторые операции, применяемые при декодировании видео, в 94, 64, 43 и 4.24 раза по сравнению с кодом на языке Си. В оптимизациях на базе инструкций AVX-2 прирост по сравнению с Си-кодом составлял 67, 27, 55 и 4.38 раз, соответственно, а на основе инструкций SSSE3 - 40, 21, 29 и 2.49 раз. Изменения добавлены в состав библиотеки dav1d, предлагающей альтернативный декодировщик для формата кодирования видео AV1. Инструкции AVX-512 доступны в процессорах AMD на базе микроархитектур Zen 4 и 5, и в процессорах Intel на базе таких микроархитектур, как Skylake-X, Ice Lake, Tiger Lake и Rocket Lake...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62177
Молодцы! Вот есть же разработчики, которые кроме обвеса плюшками и раскабанивания ПО ведут его непосредственную тщательную полировку
AVX512 инструкции появились в 2016 году 8 лет назад внимание вопрос. Это так долго до разработчиков доходила весть что инструкции появились? Они так долго копили на проц с поддержкой данных инструкций? Они 8 лет разрабатывали алгоритм? Ответ на любой вопрос показывает что разрабы у ффмпег не очень скажем так.
когда тебе денег за работу не платят, то выбираешь сам когда и что делать по мере возможностей и желания.
Справедливо Интел должна доплачивать чтобы кто-то юзал их лишние инструкции.
Так интел уже официально не поддерживает AVX-512.
А что так? Не взлетело?
AVX-512 не реализовали в E-ядрах, поэтому интел инструкции отключил для всех потребительских процессоров (начиная с 2-й ревизии[1] 12 поколения). Разные наборы инструкций на разных ядрах то ли нельзя, то ли некрасиво.Здесь в любом случае идеология есть: интел сильно топит за гетерогенность (большие P-ядра + малые E-ядра), а AVX-512 на кристаллах без E-ядер и возможность отключения E-ядер ради включения AVX-512 будут антирекламой гетерогенности.
Интел говорит, что когда-нибудь решит проблему, заменив AVX-512 на AVX10.2 (перед которым ещё когда-нибудь AVX10.1)...
[1] https://wccftech.com/heres-how-to-tell-between-an-avx-512-no.../
Неужели не смогли с M$ договориться, чтобы помечать процессы, требующие avx512 и соответственно им автоматически проставлять аффинити на P ядра. Казалось бы, тривиальная вещь. Очень похоже на какой-то патент нарвались тут.
Скорей похоже на залочку маркетингово.
Механизм может периодически ошибаться с вылетами приложений. Покупатели могут слишком много думать о пользе AVX-512 на больших ядрах (читай - о бесполезности малых ядер). Если покупателям не дать пистолет, они не выстрелят себе в ногу (и в репутацию Intel).Хотя судя по wiki.osdev, может быть, даже возможно для ОС перенести процесс на P-ядро после исключения Invalid Opcode, то есть без пометок заранее: https://wiki.osdev.org/Exceptions#Invalid_Opcode
А про официально не поддерживает можно подробнее? Ну там ссылку на заявление Интел или что-то в этом духе
В серверных процессорах очевидно, что они есть и будут (и войдут в AVX10.1/512).В десктопах их нет, что-то войдёт в AVX10.2/256[1] (где-то пишут, что в Nova Lake в 2026-2027). Я выше неточно написал, новые инструкции появятся, операции над 512 битами - нет (примерно как AVX-512VL?): "converged vector ISA [AVX10/256] ... supported on all future Intel processors ... supported on both P-cores and E-cores ... limited to a maximum 256-bit vector length".
Почему AMD полноценно смог в 2022, а Intel только начнёт снова плодить фрагментацию в 2026-2027? И ведь будущий более фрагментированный подход (AVX10/128, AVX10/256, AVX10/512) опирается на то, что не будут на асме вручную писать как в новости?
InstLatX64 в твиттере публикует страшные диаграммы Венна, показывающие, как поддерживаются разными семействами процессоров разные части AVX-512, AMX и x64 SIMD в целом.
[1] https://cdrdv2-public.intel.com/828965/361050-intel-avx10.2-... Figure 1-2
в прошлом майкрософт доплачивала, чтобы винду везде ставили... и вот результат
Думаю и Intel и прочие, просто у первой раз в 1000 денег больше даже чем у AMD, не говоря про других. Достаточно оглянуться на то сколько всего неадекватно-тормозного...
Ты думаешь что все пользователи и все сервера сразу же в 2016 году обновились на новые процессоры с поддержкой AVX-512? Серьезно?
Массовыми такие процессоры стали далеко не в 2016.
А когда стали появляться, Intel отрубила в т.ч. из-за роста температуры :))
Под сокет АМ5 завезли.
А раз они есть, то надо их использовать. Зря чтоли апгрейдился.
Что там у интела не интересно и вообще пофик
Не находишь орным что сабж реализовали после деприкейта avx512?
То, что его депрекетнул идущий ко дну Интел - исключительно его проблемы. AMD пока AVX512 не депрекейтит. Интересно, еще существуют люди в здравом уме, кто покупает интел в 2024? Mindfactory отчитался, что среди их покупателей таких почти не осталось.> Mindfactory не продала за неделю ни одного Arrow Lake — похоже, немцам не нужны новые чипы Intel
Arrow Lake от следующих слов лучше, конечно, не станет, но Mindfactory - это вообще-то партнёр AMD, ему положено рекламировать AMD (что он и делает) и выгодные предложения делать тоже, наверное (правильная статистика продаж - хорошая реклама).
На 12400 попытались появиться, но интел быстренько резанули это дело. А проц 22-го года, если что.
Не, чувак, тут вопросы к чипмейкерам.
Я очень хотел проц с AVX512 а интел только завтраками кормило и в итоге зажало это для серверных камней.
АМД только вот только для ам5 сокета раздуплилось.
Потом там разные наборы этого AVX512 доступны, типа здесь одно - там другое. Я когда на AVX кодил мне часто из AVX2 не хватало инструкций, а с AVX512 я так понял что наборы ещё скуднее.А судя по тестам - мне и на обычном AVX2 производительности хватит :)
Да даже на коредуба с SSSE3 видимо есть жизнь :)
Даже спрашивать страшно где ты там на своей фряхе используешь avx. А я даже и спрашивать не буду.
Intel Core 2 Duo - это и SSE4.1.
Не все.
8 лет в контексте x86 это буквально вчера. Жизненный цикл процессора может быть весьма долгим. Судя по стимовской статистике (первое, что пришло на ум), AVX512 это где-то 15-20%. Не очень много. Хотя предположу, что на серверах с этим несколько лучше.
У интела жизненный цикл проца 1-2 года, как и платформы.
За 10 лет интел сменил целую кучу процов и сокетов, а ам4 появился, вырос и появился ам5.
Вопрос не в том, как часто обновы появляются, а как быстро старые уходят из употребления. Это же не смартфоны, где архитектура процев очень быстро обрастает добавками.
Смартфоны часто оборачиваются не из за процов а просто потому что экран или батарея или утопили.
> У интела жизненный цикл проца 1-2 года, как и платформы.Случайно вышло, вот, полгода :) потом проц выгорает нахрен. Народ не оценил и акции интела покатились куда-то вниз, и периодически снизу стучат.
Ну правильно, хрен с ними с нормальными процами и честными нанометрами - зато, вот, management engine напихать ресурсы были :)
Инструкции-то были, но были только в интелах где от них включался тротлинг по частоте, т. е. смысла из использовать было ноль
Инструкции то появились... ну где то. А когда они появились на твоём столе?
AV1 был впервые опубликован 28 марта 2018, то есть 6,5 лет назад. Это все-таки меньше, чем 8.
Тебе никто не обязан этого делать. Ребята сделали, почёт им.
Ассемблер стреляет тогда - когда этого никто не ждёт😏😏😏
Осталось только найти что конкретно сломали, лол
Нужно было писать на Java, там же волшебный jit который сам весь код оптимизирует!
Он и оптимизирует волшебный жор проца и оперативы. Станет жрать RAM и CPU в разы лучше. А вы разве сомневались? :)
Avx всё так же режет частоту процессора? Кто-нибудь уже составил сравнительную табличку того, чем придётся жертвовать при задействовании?
Вроде как, урезание частот при включенном AVX относилось только к ранним моделям "синих".
Они там повторяли с каждым новым avx.
В моих реализациях для AVX2, с использованием fixed-point арифметики, какой либо выигрыш перед наивной реализацией на float-ах, без AVX-а, полностью исчезает при выполнении задачи уже в 7-8 параллельных потоках.
Так что если нужна именно однопоточная скорость, то SIMD дают заметный выигрыш. А в многопоточке, чем больше потоков, тем меньше выигрыш. Я полагаю, что это из-за снижения частоты ядер процессора при использовании SIMD.PS: У меня AMD Ryzen 9 5950X, в нём нет AVX-512.
>>наивной реализацией
Может быть, он даже не ошибся. Называют же, например, реализацию преобразования Фурье в лоб, как по формуле, наивной.
> Может быть, он даже не ошибся.ошибся, ибо то что он описал это тупо замена последовательных вычислений на параллельные, сам алгоритм не изменился. А в случае с "наивностью", сравните, к примеру, "наивный" алгоритм сортировки (перебор) с алгоритмом "быстрой" сортировки, это два разных алгоритма.
Под "наивной" я имел ввиду без ассемблера и без вызова разных интринсиков. Исключительно на базовых возможностях языка программирования, наивно рассчитывая что компилятор сотворит волшебство и выдаст самый оптимальный код.
В реальности, по дефолту, если там и появляются на выходе какие-то SIMD, то максимум SSE2, который гарантируется архитектурой x86-64 и который компилятор может использовать.Алгоритм у меня один и тот же - берём пиксель, умножаем на коэффициент, результат прибавляем к аккумулятору. Кроме как распараллеливания там ничего особенно волшебного не придумаешь. Разве что fixed-point использовать вместо float-ов.
> Под "наивной" я имел ввиду без ассемблера и без вызова разных интринсиков.думаю, уместно было бы написать "нативной (простой) реализацией на float-ах"
> Кроме как распараллеливания там ничего особенно волшебного не придумаешь.
и оно со своими ограничениями (проблема ввода)
Можно ли объединить подходы с использованием fixed-point и расширений SSE2? Возможно, такой подход позволит достичь производительности, сопоставимой с AVX-512, и, вероятно будет более энергоэффективным. Не говоря уже о совместимости.
> Можно ли объединить подходы с использованием fixed-point и расширений SSE2? Возможно, такой
> подход позволит достичь производительности, сопоставимой с AVX-512, и, вероятно будет
> более энергоэффективным. Не говоря уже о совместимости.Если он будет более энергоэффективным, то он не будет такой же производительный как AVX-512. Иначе бы это означало что AVX-512 требует мощности на 146%, а отрабатывает только на 100% и потому SSE2 может его "догнать" по скорости.
У меня есть реализация для SSE4.1. Она быстрее чем "нативная", но медленнее чем AVX-2. Полагаю с SSE2 будет не сильно быстрее "нативного" решения, т.к. сам компилятор может использовать SSE2 при оптимизации. А вот SSE4 он уже не может без специальной опции.
Но я не вижу смысла использовать SSE2, т.к. это прям очень старое железо, раз оно не умеет в SSE4.
Это из-за снижения частоты процессора с ростом потоков. У меня в однопотоке такой же процессор бустится почти до 5.2, а во многопотоке до 4.4-4.6. Но у меня хороший кулер на процессоре и я довольно много потратил времени в биосе настраивая лимиты, чтобы он так работал. В стоке эти цифры ещё меньше будут.
У него АМД, вряд ли просадка с 4 до 3,4 даст заметное проседание скорости, а ниже базовой АМД не сбрасывает, только тротлить может при перегреве.Я у себя вообще везде бусты выключил чтобы не тратить время и силы на охлаждение, а местами ещё и частота ниже базовой установлена.
Поправку надо сделать. Я не внимательно посмотрел, не один процессор 128 ядер, а два процессора по 64 ядра, в сумме 128 ядер и в сумме 256 потоков.
https://habr.com/ru/news/784914/ Эх зря я покупал процессор от Intel с 128 (реальный процессор) ядрами - сарказм.
Лучше в 1 потоке в 8 раз быстрее считать, чем в 8 потоках с той же скоростью.
Не совсем так, мультипоток даёт прирост скорости даже при использовании SIMD. Просто относительное ускорение за счёт муторной ручной эквилибристики с SIMD инструкциями пропадает при каком-то числе потоков. Т.е. при необходимости можно выбирать что важнее: скорость в однопотоке, или простота написания и читаемость кода в реализации для мультипотока.
Таки ничего удивительного, учитывая что AVX позволяет более плотно загружать ИМЕЮЩИЕСЯ блоки, а у вас там гипертрединг ещё.
Поправку надо сделать. Я не внимательно посмотрел, не один процессор 128 ядер, а два процессора по 64 ядра, в сумме 128 ядер и в сумме 256 потоков. перепутал. Я на это отвеча: "задачи уже в 7-8 параллельных потоках"
На нормальных материнских платах можно регулировать оффсет частоты при выполнении AVX-инструкций, в т.ч. и ставить его в 0.
Сам по себе AVX на частоту не влияет никак. Частота снижается по средствам сторонних алгоритмов контроля потребления/температуры. Частота снижается не сильно 50-150Mhz, а некоторый код ускоряется очень сильно. https://www.techpowerup.com/review/amd-ryzen-9-9950x/
Я когда читал ваш тред, у меня рука от лица не отлипала.Это надо же было не только придумать, но и реализовать такое издевательство над покупателем ваших процессоров, как нестабильная частота процессора при работе над разными задачами.
Так это придумали еще 20 лет назад, до появления троттлинга процессоры просто сгорали при превышении температуры. Зато да, частота была стабильная.
Время перекодирования или только "некоторые операции"? ;)
Ps: и сравнение не с предудущим вариантом, а
"по сравнению с кодом на языке Си", то есть вообще без avx/sse.
Если б сравнили с i386, то прирост был бы еще больше.
Судя по скрину - некоторые операции... которые являются по сути базовыми для операций кодирования. Цельный результат оценить сложнее и скорее всего совокупный прирост небольшой, т.к. медленные операции того же чтения с диска быстрее не стали, да и в случае векторных расширений интересно на самом деле то, что там вообще кроме непосредственно одновременных вычислений есть куча расширений чисто для улучшения работы с кэшем, те же базовые load/store и вот тут предположу большую часть вклада внесли именно оптимизации работы кэша, а вычисления скорее довеском стали ибо будучи казалось бы более быстрыми они имеют высокие задержки и длятся дольше, ввиду чего задерживают конвеер не давая линейного прироста скорости.
> Время перекодирования или только "некоторые операции"? ;)Отдельные функции.
> Если б сравнили с i386, то прирост был бы еще больше.
Сравнили с тем, что использовалось до этого.
Вроде бы удаляли эти инструкции, но вообще интересно, для каких именно разработчиков эти наборы инструкций добавляли. Ибо авторы ффмпег сейчас совсем как мы, сторонние программисты - мы зашли в магазин автозапчастей и увидели, что на прилавке есть двигатель, который подойдет на замену нашему. Но ведь изначально-то движок был для какой-то другой ракеты, был разработан, сбалансирован, проверен для иного использования.
В идеале авторы кодеков должны делать брейншторм с авторами CPU. Если этого не делается, значит, с чипмейкерами брейнштормит кто-то другой.
> мы зашли в магазин автозапчастей и увидели, что на прилавке есть двигатель, который...Нет, мы взяли котёнка по кличке "ядро", у которого есть дверцы разного размера (от 64 до 512) и попробовали самую большую. Получилось хорошо.
> Но ведь изначально-то движок был для какой-то другой ракеты
Нет, это универсальные дверцы для любых законных целей.
> должны делать брейншторм с авторами CPU
Тебе должны? Откуда уверенность, что им не хватает новой специальной дверцы?
> Вроде бы удаляли эти инструкции
Только в интелах с E-котятами, потому у этих малых котят нет 512-дверцы. Дверцы малым и большим котятам положено иметь одинаковые.
Поэтому компания Интел и находится на грани банкротства с убытками 16 миллиардов в квартал. В квартал, Карл!
Не поэтому. С тем же успехом можно сказануть, что "у него хардварные кодеки лучше и энкодер AV1 в 15 поколении появился, за счёт них точно выкарабкается".
> ПоэтомуИз за этого покупатели не разбегаются.
А вот, скоропортящиеся лотерейные процесоры, это уже серьёзнее.
Проблемы у Intel начались задолго до фиаско с 13/14 поколением.
ссылку бы дать на квартальный финансовый отчет
На 3dnews.ru были новости, но там Интел писала, что это в основном разовые убытки из-за реструктуризации.
интел писала на 3dnews.ru?
Вот если интересно, аноним выше непонимает разницы между расходом (ускоренной амортизацией) и убытком.https://www.intc.com/financial-info
https://d1io3yog0oux5.cloudfront.net/_f78f77710807b13f2ecb12...
"""
and accelerated depreciation of $15.9 billion increased GAAP loss per share attributable to
Intel by $3.89.
"""
Ускоренная амортизация это такой же бред как отрицательный рост? Забавно это слышать от юзера который сам не мог найти ссылку.
> это такой же бредбанкрот, убытки, звон и вечерний му**звон, доон
> который сам не мог найти ссылку
ссылку на подачу заявления о банкростве не нашел, так что ты у нас определен коментом ниже.
> ссылку на подачу заявления о банкростве не нашелА зачем тебе ссылка? У анонима написано "на грани", не более. Ты придумал о подаче на банкротство, ты и представляй. Или ты споришь сам с собой?
помесячный график
Типа ты не верил в убытки или сам себе пытаешься доказать что у Интел все хорошо? ( у Интел все плохо ).
> Типа ты не верилпену у рта протри, и балон с водой слей в канаву, а после пойми разницу между определением расходы и убыток.
Убыток — отрицательная разница между полученными доходами и произведенными расходами. Интел в пресс-релизе у себя написала, что в третьем квартале у нее убыток $16,64 млрд, или $3,88 на акцию. Ты готов поспорить с юристами/аудиторами самой Intel? Серьезно?
Квартал ни о чём не говорит. Один может быть сильно более убыточный, другой - сильно более прибыльный. По году смотреть надо. Тем более, что финансовый год в сша кончается осенью
> Поэтому компания Интел и находится на грани банкротства с убытками 16 миллиардов
> в квартал. В квартал, Карл!Копейки, тем более они в фабы вложились. Интел too big to fail, надо будет, включат принтер специально для него.
И получишь очередные Жигули.
К сожалению, тут не котят в дверцы надо просунуть, но данные а) подготовить, б) выполнить инструкцию в) забрать. Если бы проблема была только в размерности, то данные оптимизации выполнялись бы сходу, при компиляции.
Смотрите, как на самом деле обстоит дело. Вам кажется,что разработчики ffmpeg играли в доту, смотрели ютуб, телегу читали, потом отвлеклись и быстро накатали код, что "в другую дверцу" подает трафик. Это упрощенное, свойственное вашему возрасту упрощение. по "тебе должны" тоже всё ясно с вами.
В реальности все немного сложнее.
> В реальности все немного сложнее.Конечно сложнее, дверцы находятся внутри котят.
> тоже всё ясно с вами"Когда в Интернете переходят на 'вы', в реальности давно бьют морду".
Меня тоже сильно удивила наивность - для AMD и Intel выгоднее продать новые CPU/GPU с аппаратными декодерами AV1, чем учесть потребности разработчиков dav1d. А при разработке очередного SIMD-расширения - смотреть, где деньги водятся (обычно не в свободных проектах).
>> тоже всё ясно с вами
> "Когда в Интернете переходят на 'вы', в реальности давно бьют морду".
> Меня тоже сильно удивила наивность - для AMD и Intel выгоднее продать
> новые CPU/GPU с аппаратными декодерами AV1, чем учесть потребности разработчиков dav1d.
> А при разработке очередного SIMD-расширения - смотреть, где деньги водятся (обычно
> не в свободных проектах).Согласен, не работал в Intel или Эльбрусе/Байкале, но это логично. Поговорить у доски с парой-другой алгоритмистов часок, попить чаю, подумать, таких встреч провести десяток - вот и готова пользовательская история, запрос на "оффлоад" вычисленийв цпу. Сторонние компании, где деньги водятся, более, чем охотно отпустят своих зубров на такие консультации.
Чует моё сердце, что тут 100 пудово есть какой-нить "нюанс", типа всё делаем в однопотоке или ещё чего-нить подобное.
Нюанс в том что не везде он теперь будет работать.
Я надеюсь они пользовались GNU assembler с синтаксисом AT&T.
Надеюсь, с синтаксисом Intel.
Надеюсь на раст.
На Rust надейся, а сам не плошай.
Не надейтесь. Там ассемблер. Но и не расстраивайтесь. Для раста много ниш открывается. По замене питона, бейсика и т.п.
По факту это питон всех заменяет и вырвался на первое место по частоте использования.
>> место по частоте использования.Так, это не осилили просто что то серьёзнее.
Вот на дорогах каких машин больше BMW ,или Лады? А что лучше?
Вот, и тут то же самое, среднестатистическому
большинству многое не по силам, и искренне радуются тому что есть. Но как только поячится возможность взять что то лучше, и возьмут, и польют грязью старое.
В Германии БМВ сильно больше. Сказать то чего хотел? Что в нормальных странах выбирают нормальные автомобили?
"частота использования" может указывать и на г0вно. И не только про авто вне Германии, вне системного программирования тоже пользуются тем что осилили, а не тем что лучше.
Фух, интеловский синтаксис, NASM.https://code.videolan.org/videolan/dav1d/-/blob/master/meson...
https://code.videolan.org/videolan/dav1d/-/blob/master/src/x...Количество ассемблерного кода угнетающее, как это вообще пишут.
> Фух, интеловский синтаксис, NASM.А вам не всё равно?
Зачем бы я тогда искал? От факта использования интеловского синтаксиса есть некое удовлетворение. Не всё потеряно в этом мире.
Не всё равно.
Ага, каталог blob у проекта, которое не относится к проекту ffmpeg.
Угу, умные комментарии на опеннете.Это часть гитхлабовских URL, алло: [1]
О том, что речь идёт о dav1d, написано и в новости.
FFmpeg - новость из их твиттера. Что именно они сделали - только фотографию на конференции[2] или доклад или сравнение производительности или коммит в dav1d - это не ко мне.
[1] https://stackoverflow.com/questions/39400848/in-github-urls-...
[2] https://www.videolan.org/videolan/events/vdd24/
кхм. а скомпилировать из си с использование указанных инструкций?
А компилятор смогёт?-))
А в чём проблема?
В неумении эксперта задать ключ -S транслятору?
На AVX2 главное не сильно хуже получилось.
по логике avx512 должен быть в 256 раз быстрее avx2, но intel и тут облажались
У интела с неймингом традиционно плохо :)
> в 256 раз быстрееВ 100500 же ж.
> 94, 44, 64 и 4.24 раза по сравнению базовой реализациейПредставил себе качество базовой реализации.
Рассуждать о качестве тут вообще не к месту.Правильнее называть это не базовой реализацией, а референсом. Этот код должен быть просто написан, чтобы исключить ошибки в нём. Референс этот используется для проверки правильности результата оптимизированных реализаций. Поэтому сравнение в скорости с референсом вообще некорректно. Даже на Си можно написать код быстрее, но код этот будет сложным, и его самого придётся чем-то проверять. Оптимизированный код с векторами (векторные интринсики) можно и на Си написать, но в ffmpeg предпочитают ассемблер.
Новость желтушная от названия до содержания.
А что там представлять?
Там видимо какая то простая операция, типа сложить однин кусок памяти с другим представив что это массивы uint8_t.
И код на си будет простым циклом проходящим по каждому элементу и делающему сложение.
Вот его переписали на SSSE и он стал за "одну операцию" складывать не 1 элемент а сразу 16, потом на AVX и там 32 а на AVX512 сразу 64 за раз.
Вот и вся магия, минус накладные расходы, а иногда плюс. Там есть всякие трюки с загрузкой в кеш и регистр и выгрузкой обратно в память, поэтому иногда на этом получается ещё немного выиграть скорости.Технически некоторые вещи и на С доступны, типа префетч подёргать чтобы пока один элемент обрабатывается проц уже следуюшие подтягивал в кеш из памяти.
Просто обычно на С таким не занимаются, и сразу уходят в SIMD.
> Просто обычно на С таким не занимаются, и сразу уходят в SIMD.Я не понимаю что на Opennet делают настолько необразованные люди. Которые не знают ни одной вещи о которой пишут. На Си можно писать код использующий векторные инструкции напрямую, и это не ассемблерные вставки, это называется векторные интринсики.
Intrinsics are just C-style functions that do something with these vector data types, usually by simply calling the associated assembly instruction.
Вы бы читать научились.
ОБЫЧНО на С не используют такие штуки, в том числе и инстрикты и префетчи и пр.
И обычно не пишут код под векторизацию - я про разворачивание циклов в ручную, например когда один шаг цикла делают в 4-8-16 и за раз столько складывают.Про инстрикты в С я лично знаю лет 10 как минимум и у меня есть пачка кода на этом.
И префетчем я баловался в С в коде без инстриктов и это даже давало какой то еле заметный эффект.
> ОБЫЧНО на С не используют такие штукиЧто значит обычно? Это как-то связано с тем что 99% случаев никто код не оптимизирует, это и делает вашу статистику? По моим наблюдениям в большинстве проектов, если занимаются оптимизациями, то пишут на Си с интринсиками, а не на ассемблере. Известный всем пример - OpenCV. Существуют мультиархитектурные обёртки вроде simde, чтобы под каждую архитектуру не писать отдельно. ffmpeg это как раз исключение, также в Intel любят писать на ассемблере (но с Intel это понятно). И даже в ffmpeg есть несколько архитектур где оптимизировано через интринсики на Си.
> то пишут на Си с интринсиками, а не на ассемблере.а разве есть разница?
Разница в чём? В производительности будет одно и то же. Если вы не мега-эксперт по ассемблеру, вроде сотрудника Intel, что знает все тайминги и особенности современных x86 процессоров. Если же плохо знать ассемблер, то компилятор векторные команды может расположить более оптимально.Си с интринсиками читать, писать, изменять и отлаживать быстрее и проще ассемблерного кода. К тому же ассемблерный код придётся писать для 32 и 64 версий архитектуры. Или городить горы костылей с макросами, чтобы один ассемблерный код компилировался для x86 и x86_64. А у ARM вообще ассемблер заметно отличается для 32 и 64-бит версий архитектуры, особенно для векторных команд. При этом при использовании векторных интринсиков на Си разница кода между 32 и 64-бит минимальная. Вот и думайте что лучше.
И еще в libjpeg-turbo используется ассемблер для x86. Между тем ARM на интринсиках, и несколько других архитектур оптимизированы на интринсиках.
> К тому же ассемблерный код придётся писать для 32 и 64 версий архитектуры.то есть я пишу на С и пихаю асм вставки векторных инструкций и мне надо будет задуматься о разрядности архитектуры? А в случае использования явных интринсиктов - думать не надо?
https://en.wikipedia.org/wiki/Intrinsic_function
> При этом при использовании векторных интринсиков на Си разница кода между 32 и 64-бит минимальная.
Так разница есть или нет?
> то есть я пишу на С и пихаю асм вставки векторных инструкцийГде в процитированный для виду википедии написано что интринсики это асм вставки? Загляни в хидеры, докажи что интринсики это лишь асм вставки. Потому что это не асм вставки, а builtin функции, что реализованы вне зависимости от адресации. В википедии прям в начале написано "also called built-in function or builtin function". Цитировать умеем, а читать? За редким исключением, когда команда реально зависит от режима, тогда в Си делают #if #else вставку, этого немного.
> Где в процитированный для виду википедии написано что интринсики это асм вставки?вам теперь скинуть ссылку на определение "built-in function"?
Чтобы оптимизировать код не обязательно опускатся на низкий уровень и писать инстриктами/SIMD код, это обычно самое последнее что делают.
Высокороуровневые оптимизации часто могут дать выигрыш намного больше чем SIMD.
Когда я возился с ECDSA то оказалось что там есть много интересных методов рассчёта дающих тот же самый математический результат за в разы меньшее время.Я веду к тому что написать memcpy() быстрее чем тот монстр что там сейчас включающий в себя SIMD реализацию не получится, но бывают случаи когда можно этот самый memcpy() дергать намного реже.
Я тут в качестве хобби возился с реализацией гост хэша на SEE/AVX.
После длительной возни я пришёл к выводу что проще на обычном С коде работать с тамошним uint512_t счётчиком битов чем мучатся с длинной арифметикой на SIMD. По скорости С вариант даже быстрее местами чем SIMD, и это позмолилось понизить требования до AVX1 и SSE который есть в коредуба.И в целом проектов где всё упирается в числодробилку, наподобии OpenCV, ffmpeg (кодеков) не так много.
Я часто возился с тормозящим кодом где была проблема в неоптимальном высокоуровневом коде, последние разы это были gtk3 и CodeLite.
В последнем проблемы с крестовой лапшой, когда с виду невинные конструкции порождают чудовищный код.
> в 94 раза ускоритьУжасно желтушный заголовок, потому что сравнивать надо не с Си, а с оптимизацией на предыдущих векторных инструкциях, то есть AVX2.
А там быстрее примерно в 1.5 раза, и это при увеличении длины векторов в 2 раза. И еще неизвестно как это влияет на процессор.
Скорее всего сравнивают то, что успели накодить для теста. Так то можно и Си заставить использовать любые инструкции.
Не, всё написано, последнее изменение полгода назад, почти сплошной асм отдельными файлами.https://code.videolan.org/videolan/dav1d/-/blob/master/src/x...
Базовые реализации у всех тестов кроме первого совсем медленные, может, вместо ускорения остальных реализаций были замедлены базовые, чтобы желтушники сообщили об огромном ускорении?
Очень похоже на то: https://news.ycombinator.com/item?id=42042706Но не совсем, ускорение всё же есть, просто чтобы получить заявленные 146% пришлось затормозить сишный код.
Еще бы найти где-то видео в формате AV1.
Уже давно YouTube и русские сервера с видео поставляют его. Смотрите техническую информацию в видео при воспроизведении
Не надо так.
Мне больше интересно насколько с AVX512 производительнее чем с AVX256 и стоит ли оно того?
См. тему про тестирование cpu в ffmpeg на форуме ixbt. Если коротко, бывает даёт +5-10% скорости кодирования. Это было до новой версии ffmpeg. Посмотрим, что изменится с новинкой.
А потом говорят, что Сишка быстрая.
Сишка не исполняется
Работают ли эти оптимизации на aarch64?
Нет кончено, это не для армов.