Тут на соседнем канале зашла речь про ускорение некоторых алгоритмов с помощью 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
Первый блок на скриншоте - просто мап на 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
👍11🤯5🔥4
В продолжение поста, теперь на столе коэффициент детерминации R² (gist). Тут что-то пошло не совсем так: если использовать прямой подход с мапом в Vector256<T> - то буст всего х4 на double и x6 на float (причем повторяемость практически не зависит от размера массива, а значит дело не в кэше который всё успевает и никак не влияет на перф, а в вычислениях).
Однако, если сделать финт ушами (второй скриншот) - и смапить в Vector512<T> - то всё становица чуточку лучше. И тут неважно, что процессор не умеет нативно AVX512, Vector512<T> здесь просто как контейнер для двух Vector256<T>. Здесь получается.... классический loop unrolling, когда за одну итерацию забирается два Vector256<T> (lower/upper) и дальше они ровно также как в ручном loop unrolling складываюца/умножаются в цикле в по прежнему в Vector256<T>.
Это помогает больше чем в 1.5 раза к обычному способу с Vector256 - буст с х4 до ~х5.5 (на double) и с х7.6 до ~x12.5 (на float). Причем на массивах больших, которые не помещаются в L1 кэш - разрыв в перфе больше. Подозреваю, что по причине как в предыдущем посте. #simd
Однако, если сделать финт ушами (второй скриншот) - и смапить в Vector512<T> - то всё становица чуточку лучше. И тут неважно, что процессор не умеет нативно AVX512, Vector512<T> здесь просто как контейнер для двух Vector256<T>. Здесь получается.... классический loop unrolling, когда за одну итерацию забирается два Vector256<T> (lower/upper) и дальше они ровно также как в ручном loop unrolling складываюца/умножаются в цикле в по прежнему в Vector256<T>.
Это помогает больше чем в 1.5 раза к обычному способу с Vector256 - буст с х4 до ~х5.5 (на double) и с х7.6 до ~x12.5 (на float). Причем на массивах больших, которые не помещаются в L1 кэш - разрыв в перфе больше. Подозреваю, что по причине как в предыдущем посте. #simd
🔥3👍1