В продолжение поста, теперь на столе коэффициент детерминации 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
tgoop.com/notes_of_programmer/646
Create:
Last Update:
Last Update:
В продолжение поста, теперь на столе коэффициент детерминации 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
BY 📓 Записки программера
Share with your friend now:
tgoop.com/notes_of_programmer/646