Я в этом году не выступал, но немного поучаствовал в докладе Дениса про SIMD инструкции. Хочу немного продолжить эту тему.

Два года назад, перед моим первым докладом про SIMD, я любил разбирать Capstone-ом бинарники и смотреть какая нагрузка идет на какие регистры. Мы в HPC часто концентрируемся на микро-оптимизациях вдоль горячего пути прохода данных, но часто забываем, насколько много кода остается вне нашего поля зрения. Я прогнал простенький скрипт на паре моих Linux/MacOS машине с процами двух последних поколений и достаточно свежими бинарями. Заняло несколько часов, просмотрено было около 4000 бинарников. В итоге, SIMD регистров касается менее 1% процента общего пула инструкций. Почти все приходится на 128-битные инструкции.  Подозреваю, что большая часть приходится на всякие memcpy примитивных стуктур вроде { uint64_t a, b; }.

В статье подробные свежие результаты, код и ссылки на мой доклад пару лет назад. Позднее думаю выложить подобные сравнения, но по категориям софта и по версиям компиляторов.  

https://unum.am/post/2021-11-21-simd-popularity/

Но при этом не стоит забывать, что в глубокой оптимизации нуждается не все 100% кода. Поэтому мне эта метрика кажется несколько странной :)

Yes, for sure. Not the best metric, but still a relevant one. Especially, once you build charts for SSE and AVX2 side by side. We have had AVX2 capable CPUs for 8 years, yet the compilers almost never generate those instructions for a miriad of reasons)

А "почти все приходится на 128-битные регистры" --- людям нужны переносимые бинарники, поэтому только SSE2 на 64-битных архитектурах

Yes, I wrote that in my post. Yet there is simdjson, which properly chooses the backend at runtime and ships will all optimizations out of the box.

To tell the truth, glibc and libstdc++ on Linux has runtime dispatching for per-architecture versions of its functions. That is, it will use AVX2 on AVX2-capable CPU for standard functions.

(which causes really hard-to-debug issues if ffast-math is enabled, and AVX might be disabled without ffast-math, because some of its functions are incompatible with c++ standard)

Btw, as far as I can tell from the brief look in the article, such libc-based dispatching will not be detected by the capstone, therefore it'll not be counted in the metric.

Would depend on linking I guess

The heaviest binary most likely link statically and should contain the AVX backends inside the distributed package, so it should be counted on top

Well, standard dynamic linking. Afaict, there are some of trampoline functions, which detect architecture on the first call. At least that is how it looks from the debugger side.

Static linking to libc is a recipe for disaster, afaik :)

Probably, not the best plan))) Still, when we open up Godbolt, the first thing we look at - is the number of assembly lines, and only then - whats in them.The first step is done, so now I am inviting everyone to join me analyzing them)

Godbolt doesn't show this dispatching. I checked that

It happens in /lib/libc.so

Godbolt just shows "jump to libc:rint"

/spam

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