Replace characters in a string using Vectorization - использование SIMD инструкций для векторизации замены символов в строке. Привлекла статья тем, что код хорошо комментирован - и понятно, где какие маски накладываются и какое действие производица над пачкой байт. В шапке статьи также ссылки на соседние интересные статьи по этой же тематике.

Аналогичным образом через векторные инструкции можно сделать ToLowerCase строке (код написан кстати с помощью #chatgpt :) - в этом коде особенно интересно то, что вместе с действием по модификации ushort элементов в векторе также применяются другие инструкции на весь вектор - And/Or.

#dotnet #simd #sse

Человек форкнул dotnet runtime, чтобы вырезать инструкции CMOV и SSE - чтобы запустить .net программу под DOS на 486м компе #dotnet #simd #sse

Имел неосторожност опубликовать в mastodon вопрос про SIMD - там где Vector128 был медленее Vector256, на что пришёл Alexandre Mutel (Director C#/.NET Tech Group at Unity) и потыкал меня носом в разные места этого кода. После чего он родил статью "10x Performance with SIMD Vectorized Code in C#/.NET"

#dotnet #simd #sse

Не для собственной имплементации (потому что это помоему уже везде реализовано), но просто для понимания как можно использовать SIMD (недлинная статья с примерами на сишечке). #simd #sse

Ещё один всратотест (gist) - проверка сортированный ли массив. Кандидаты:

* обычный цикл + с сохранением предыдущего
* Vector128<int> + с сохранением предыдущего
* Vector256<int> + с сохранением предыдущего

Даже циклы можно крутить быстрее :))

Что интересно - Unsafe.ReadUnaligned и MemoryMarshal.Cast<int, Vector128<int>> (в гисте его нет, но я пробовал) - совершено идентичны по скорости.

Вопрос - можно ли это назвать не O(n), а O(n/4) и O(n/8)? 😁

Надо попробовать алгоритм K-means завернуть в SSE, там должен интересный буст на большом количестве кластеризуемых точек. #sse #simd

Converting ASCII strings to lower case at crazy speeds with AVX-512 - всё это конечно хорошо, но я как-то ощущаю, что в основном строки, которым делают lower case они короче 64 символов (HTTP-заголовки например). Так что выигрыш конечно на синтетике будет адовейший, но в реальности для этого хватит и Vector<128> или Vector<256> #simd

Очень интересная статья про AVX512 - в частности как он был реализован AMD в ядре Zen4 и в Zen5 mobile (две операции по 256 бит) и как его сделали в ядре Zen5 (честные 512 бит). Но, есть конечно и физика, от которой никуда не деться:

Therefore, this behavior is consistent with the earlier observation that Zen5 can run AVX512 at full clock speed provided there is thermal headroom. Somehow Zen5 manages to keep all that extra hardware on standby and can wake it up instantly.

Но очень удивлён как это реализовано в Intel процессорах (далее мой перевод):

Для процессоров Intel эти переходы [от обычного кода к коду с AVX512] обрабатываются в два этапа:
1) При переходе от кода низкой интенсивности (low-intensity) к коду высокой интенсивности (high-intensity), код высокой интенсивности работает с резко сниженной пропускной способностью, чтобы уменьшить его интенсивность.
2) После длительного периода в ~50 000 циклов код с более высокой интенсивностью переключается на полную пропускную способность.

Как упоминалось ранее, процессоры Intel не могут запускать AVX512 на полной скорости, так как они выйдут из строя [ниже в статье есть упоминание про Vdroop и я пока не понял - то ли напряжение падает то ли наоборот подскакивает]. Поэтому, прежде чем он сможет запустить AVX512, ему сначала нужно снизить тактовую частоту.

Снижения тактовой частоты выполняется тактовым генератором и регулятором напряжения и это занимает время ~50 000 циклов. Также требуется дополнительные аппаратные модули, которые включаются и используются только с 512-битными инструкциями.
...
На более высоких тактовых частотах включены только нижние 128 бит 512-битных модулей. На этой [полной] скорости включение верхних 384 бит вызовет [повышение?] vdroop, которое может вывести ядро ​​из строя. Только на более низких скоростях могут быть включены все 512 бит. Но во время ожидания, пока процессор переключается на более низкую частоту - код может выполнять 512 битные инструкции, используя нижние 128 бит, что занимает в 4 раза больше времени, но это лучше чем вообще ничего не делать.

Вместо приостановки выполнения на ~50 000 циклов, процессоры Intel разбивают более широкие инструкции и "многократно перекачивают" (multi-pump) их в модули, которые уже включены и готовы к использованию на текущей тактовой частоте.
(конец цитаты)

🤦‍♂️ походу костыли не только в софте бывают :))) Буду искать подробности ещё. #simd

Тут на соседнем канале зашла речь про ускорение некоторых алгоритмов с помощью SIMD и я побыстрому накидал реализацию двух - косинусное сходство и корреляцию Пирсона (на скриншоте бенчи для него, для косинусного сходства - в камментах в gist). Алгоритмы как будто прямо таки созданы для Single Instruction/Multiple Data :)

Первый блок на скриншоте - просто мап на Vector<double> и дальнейшие операции, ничо сложного, но даже это даёт 6-кратный буст. Второй блок с float, тут ещё побыстрее, просто потому что элемент в 2 раза тоньше и за один чпок забирается в два раза больше элементов по сравнению с double.

Но вот дальше там был ещё один кейс, когда входные данные короче И double И float - например short. И вот тут становица всё ещё интереснее: отмапленый в Vector256<short> забирает сразу 16 элементов входного массива. Напрямую в Vector256<float> такое не смапиш конечно, поэтому операция двухэтапная - сначала GetLower/GetUpper по 8 элементов экспандяца до int (32 бита = 256 бит), а потом кастяца до float (тоже 256 бит).

Вроде выглядит некоторыми костылями, но это даёт 14-кратный буст даже на длинных массивах, которые гарантированно не влезают в L2 кэш. Если кастить в 32-битный float конечно, с double ситуация пожиже - там буст ровно в два раза хуже (~x7), что вполне логичо :))

Судя по всему выполнение SIMD инструкций тут отлично сочетается с асинхронностью L1/L2-кэша - пока локальные данные кастяца, множаца и складываюца - в кэш подтягиваются следующие порции данных и к моменту следующей итерации они уже там. #simd