История Одного Теста Типа на питоне получилось так же как и на С++. Хотя уже доказано что С++ быстрей питона 400-500 раз. Надо бы ещё на UASM эту задачу решить, графику рисовать OpenGL а может и GDI32 справиться.
Интересное сравнение C++ c C++. Потому что raylib не нейтивная притоновая библиотека, а бинарник, по иронии судьбы написанный на плюсах. И если по большей части производительность теряется в ней, то прямо ну очень показательно.
Так, я бы попросил, рейлиб не на богом проклятых плюсах написана, а чистой, как слеза младенца, православной сишечке.
Rel, на С++ можно написать так, что по скорости не будет отличатся от чистого С. Короче, использовать С++ как просто С с классами, как раньше он и задумывался.
В коде по сути тестируется функция fillFramebuffer, остальное с версией для питона работает почти одинаково: UpdateTexture //копирует массив пикселей в аппаратную структуру texture DrawTexture //рисует эту texture в окно Так что для теста кода можно сделать консольное приложение которое запустит fillFramebuffer, и проверит время выполнения. Тут даже можно printf можно использовать для вывода FPS. ЗЫ Переписал на UASM, но пока работает с ошибками.
Тестируется всё честно - а конкретно тестируется JIT-компилятор Numba: https://en.wikipedia.org/wiki/Numba Хороший инструмент чтобы ускорять функции пайтона занимающиеся интенсивными вычислениями над массивами завёрнутыми в классы numpy. Просто заточка конкретно под это - при вызове функции смотрим заходят ли в неё в качестве параметров типизированные массивы numpy и если так, то для них собираем на лету машинный код не хуже плюсов (да что там говорить - тем же самым LLVM). Собственно вычисление массива множества мандельброта не случайно видимо тут выбрано, как идеально ложащийся на целевое назначение пример - огромное число циклов с простыми числодробилками над типизированными массивами. Просто блеск. Ну вот да, есть такое. Ну и как в видео скромно замечается - подойдёт не только лишь всем.
aa_dav, получается питон компилятор, был интерпретатор, прикрутили намбу, стал компиляторный ЯП. Ну это так можно с любым, сделал транслятор; ваш скриптовый ЯП ---> С; Си компилируем; запускаем; профит!
Ну, справедливости ради, ты далеко не весь петухон-код можешь соптимизировать до уровня плюсов, вне зависимости от того, тот же ллвм у тебя или нет. Динамическая типизация мешает, почти всё должно находится на куче (даже None, True и False - по семантике это объекты синглтоны), числа нефиксированной разрядности, все циклы (формально) через энумераторы и тд. Это утверждение валидно только для какого-то сабсета, у которого типы заранее известны, для которых предопределен набор операций.
Ну так я же и говорю - для типизированных массивов numpy. На видео есть скриншот где такой массив функцией создаётся - тип в массиве скармливается через параметр, ничего другого туда не запихнёшь. Конечно всё чуток сложнее - типы параметров-скаляров тоже принимаются в расчёт, но уже сам этот анализ чреват накладными расходами и в полную силу концепция раскрывается когда числодробятся массивы. --- Сообщение объединено, 31 мар 2025 в 18:07 --- И если кто видео не смотрел - такие функции надо декорировать декораторами которые расскажут Numba к каким функциям надо пытаться применяться. К другим он применяться не будет, по крайней мере по умолчанию, т.к. бездумное его применение может всё только замедлить по вышеозвученным причинам.
Проблему python против c++ можно решить обратившись к фильму чужой против хищника. Сложность заключается в том, что нужно определить, кто из них двоих хищник, а кто ксеноморф. Кто победит, тот и победитель. И спорить тут не о чем.
