История Одного Теста Типа на питоне получилось так же как и на С++. Хотя уже доказано что С++ быстрей питона 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++ можно решить обратившись к фильму чужой против хищника. Сложность заключается в том, что нужно определить, кто из них двоих хищник, а кто ксеноморф. Кто победит, тот и победитель. И спорить тут не о чем.
Доделал свою демку, работает хорошо. ФПС около 8.5 на моём райзене 3600Х. Маловато будет, но сколько есть. Чисто рендер картинки с отключённой fillFramebuffer, аж 950 кадров. Так что рендер картинки очень мало занимает ресурсов, память всего 9.5 МБ. Использую SSE2 инструкции, cos, log2, log10 вычисляют FPU, сделал небольшие оптимизации в точности переставил циклы x и y местами(чтобы кэш меньше конфликтовал из-за разбега данных), что дало заметный прирост, точность по дефолту, возможно стоит задействовать флаги, чтобы уменьшить точность, вплоть до real4, чтобы быстрей вычисляло. Так что демка автора на питоне весьма впечатляет, а С++ удивляет, по идеи всё равно должен быть быстрей на несколько десятков %. Ну и конечно у него CPU по мощней будет. ЗЫ Надо ещё на чистой машине протестировать, отключить ВСЁ что не нужно, и в ТЕСТ! --- Сообщение объединено, 2 апр 2025 в 20:08 --- Кстати, а код можно здорово оптимизировать. Код (C++): const double res = mandelbrot(c_re, c_im); Можно предвычислить в таблицу, а косинус можно запараллелить чтобы сразу вычислять 3 значения, придётся сделать макрос-функцию cosps чтобы разом до 4 косинусов вычислять. Кстати, автор шарит, и неспроста добавил модификатор const для входных и выходных параметров, компилятор должен догадаться предвычислить все значения в таблицу: Код (C++): const double pre_mandelbrot[FormHeight][FormWidth]; //тут мы вычислили все значения для всех x и y По этому код на С++ заметно быстрей, получается и питон такое может, хм. Занятно всё. И всё равно, мне непонятно, какого хрена С++ так проигрывает чёртовому пихтону!!! --- Сообщение объединено, 2 апр 2025 в 23:45 --- В общем, реально С++ и даже этот питон, точней джиткомпиль догадался сделать таблицу mandelbrot. Дальнейшая оптимизация, это самостоятельное вычисление cos с заданной точностью, так как результат усекается до 8 бит, т.е. байта, значит вычислять результат косинуса больше скажем 16 бит, не целесообразно. Это реально ускорит в однопоточном тесте демку. У меня сейчас ФПС 18-25, да, вот так колеблется. У автора где-то так, но ФПС не откланяется. --- Сообщение объединено, 2 апр 2025 в 23:48 --- Кстати, попытался уменьшить точность, но оказалось для косинусов флаги точности не влияют. Только для FADD, FSUB, FSUBR, FMUL, FDIV, FDIVR и FSQRT.
