Я і обіцяв, знайшов час погонятися з NumPy.
Відразу не вийшло, так як я статично влінкував Python в проєкт, що унеможливило таким надбудовам, як NumPy, користуватися нативним backend: його DLL вантажиться, не бачить python314.dll і відмовляє. Для тестів я увімкнув динамічну лінковку. Ну добре, тепер результати
Щоб бути трохи чеснішим до NumPy, я додав у свій тест такі самі реалізації для матриць повороту: там можно бачити таке:
# R = gu.Mat3.rotation_x(0.2).rotated_y(0.3).rotated_z(0.4)
R = rot_x(0.2) * rot_y(0.3) * rot_z(0.4)
Проєкт і Пайтон скомпільовані у release.
Дивимось:
Нативне перехоплення проти чистого Python
1.477 / 0.774 ≈ 1.91 рази
Нативне перехоплення проти NumPy
1.403 / 0.774 ≈ 1.81
Оптимізовані функції проти чистого нативного перехоплення
0.774 / 0.762 ≈ 1.016
Коротше, використання NumPy тут майже немає сенсу. Так, воно трохи прискорило, а не так, щоб Вау!
Знадобилося мені у моїй розробці на C використовувати тригонометрію у Python. Ну, тобто всякі форми перетворення однорідних координат тощо. Numpi такого не вміє. Python я використовую як скриптову мову для сценаріїв і повністю контролюю з C . Напевно, рідко хто таким займається, але я займаюся - можна підмінити Python-метод нативним.
І ось вам тести! Різниця у швидкодії виконання обчислень з використанням нативних врапперів та без них. Різниця приблизно у 2,3 раза на моєму залізі. 😱
Бенч писав ChatGPT бо я занадто лінивий для такого.