Комментарии 30
Вроде не первое апреля, а статья похожа на первоапрельскую шутку… В numpy/scipy уйма функций, и все они кому-то нужны. Ладно, давайте на примерах - вот у меня код собственной реализации robust trend estimator (для выравнивания стэка радарных космоснимков функция работает быстрее и точнее библиотечных) на питоне с использованием библиотек: https://github.com/mobigroup/gmtsar/blob/pygmtsar/todo/PRM.robust_trend2d.ipynb Покажите вашу реализацию без использования сторонних библиотек и сравнимой производительности. Сразу скажу, что понадобится целая пачка спецфункций, каждая из которых описана несколько по-разному в разных научных статьях, и во всех вариантах могут быть свои ограничения, ошибки или просто недочеты.
Интернет говорит, что вроде как есть библиотеки по типу pandas с применением gpu, например https://github.com/rapidsai/cudf (сам не использовал)
Что в планах?
Пожалуй, оставлю себе в будущем этот коммент. Вдруг через 100500 лет пригодится (или сколько там было суммарно вложено в разработку оригиналов).
Ииии ??
Ну, вот просто интересно, как вы думаете, через сколько лет вашей библиотеке начнут доверять ??
Если сравняюсь с numpy по некоторым бенчмаркам, то может быть и станут доверять, но и то не факт. В любом случае, пока я работаю над этим один, всё это скорее похоже на авантюру и ресерч-проект в стол, поскольку ресурсов сделать что-то конкурентоспособное нет. Можно попробовать не распыляться, и что-то одно хотя бы довести до ума, но у меня пока даже нет идей, на чем лучше сконцентрироваться - перф дожимать или функциональность наращивать.
Можно и одному делать конкурентоспособное, только нишу выбрать. Скажем, библиотека для легкого создания numpy-совместимых функций, исполняемых на GPU с поддержкой, в том числе, Apple Silicon платформы будет куда как интереснее ваших матричных операций на плюсах (кстати, в фортране это давно уже есть нативное и отлично оптимизированное, до появления numpy проще было именно на фортране написать).
Спасибо за идею @N-Cube! Нужна ниша, но-таки да, я не ориентируюсь в конкретных потребностях пользователей. А не скинете конкретный example чего бы вы хотели? Поподробнее о numpy-совместимых функциях? Лучше в личку. Спасибо!
Почему в личку, это же много кому интересно. Мой открытый проект это процессор радарных спутниковых снимков, написан на питоне с поддержкой отложенных вычислений, работает намного быстрее сишных реализаций и требует на порядки меньше памяти (имеется в виду десятичный порядок, на докерхабе есть пример, который на питоне работает в контейнере с 16 гигабайт оперативной памяти, а на си половина этого примера не работает при наличии 256 гигабайт). Так вот, было бы прекрасно иметь возможность просто подгрузить библиотеку, которая заменит часть базовых операций numpy на gpu-версии и выполнит их на любой ОС (макос эппл силикон и интел, линукс, опционально - виндоус). Как вариант похуже, иметь возможность самому реализовать нужные функции для выполнения на gpu - это потребует лишней работы, но тоже в определенных ситуациях годится. В принципе, уже есть подобные библиотеки, но заточенные на определенные видеокарты, так что проекту для широкой аудитории они бесполезны. Даже какие-то простые вещи типа аффинного преобразования больших растров будут полезны, если будут работать везде и стабильно.
библиотека для легкого создания numpy-совместимых функций, исполняемых на GPU с поддержкой, в том числе, Apple Silicon платформы
Звучит как jax, в эппл силикон вроде тоже умеет: https://github.com/google/jax/discussions/9847
Как минимум не раньше, чем с этим можно будет работать в Jupiyer Notebook или "импортозамещенном" аналоге.
В Jupyter можно работать и с C++ (https://github.com/jupyter-xeus/xeus-cling), и с Java, и с многими другими популярными языками, так что это не проблема.
У вас в статье опечатка, или рельно С++ версия сильно медленнее питона?
Претензии на AVX есть, но внутри для этого ничего нет, так что оптимизации там постольку-поскольку. numpy этим увы тоже страдает.
BlazeCpp гораздо быстрее и удобнее вашего np.
Вообщем импортозамещение в его классическом представлении.
На практике - берите Julia и забейте на плюсы, даже с крутейшим Blaze писать математику на плюсах все равно сложно и муторно.
В numpy и sklearn под капотом C и Fortran, если я не ошибаюсь, так что ничего удивительного. Но у меня есть шанс догнать и перегнать их.
Возможно, моя библиотека/ки будут полезны тем, кто страдает от неудобной интеграции с Python-ом и готовы немного пожертвовать перформансом.
А вообще посмотрим куда всё это пойдет. Пока не знаю.
Еще как удивительно, ведь уделать numpy по производительности на вашем примере задача тривиальная, попробуйте написать то же самое с использованием Blaze или на Julia и будете приятно удивлены
ok, спс, посмотрю как и что у них там сделано.
Если вы так рекламируете свое, как насчет сравнить производительность с питоном: https://pythonspeed.com/articles/speeding-up-numba/
Спс за ссылку. Цифры перфа с примерами можно использовать как бейзлайн. В статье говорится о вещах известных - кэш-миссы, branch misprediction, SIMD, но правильно вкрутить все эти вещи в софт (в смысле SIMD и побороться с первыми двумя) - та еще задачка. SIMD делает и компилятор как умеет, но он может делать это не оптимально. И можно вырулить на том, что ещё не очень многие хорошо научились делать это оптимально. И спасибо Intel VTune/Intel Advisor!
Сейчас, с появлением Pandas 2.0+, появилась новая точка отсчета - бэкенд pyarrow (Apache Arrow), который кратно быстрее читается, в разы быстрее пишет в файл и фильтрует чем numpy- и pandas-объекты. И все это почти не меняя код. Другое дело что его написаны тонны, но ведь и переходить никто не торопит.
Есть места где pyarrow медленнее чем Numpy/Pandas (работа с categorical-данными, агрегирование и по мелочи). Но в целом апачевские колоночные БД, форматы и DS-платформы уже стали промышленным стандартом и однозначно они скоро станут основными в DS и BI (года через 3).
Импортозамещаем numpy, pandas, scipy и sklearn
Импортозамещать не корректно т.к. нет ограничения в использовании на территории РФ.
Если выбирать либу - между старой, с открытым доступом и огромной community поддержкой, либо вашу, которую еще нужно изучать, а гарантии поддержки лет через 5 нет никакой, то выбор очевиден.
Надо было на Rust писать. Тогда хотя-бы с контрибутерами проблем не будет.
Когда понадобилось применять математику для вращения матрицами представления дрона о пространстве, не стал применять ни одну "библиотеку", а тупо перемножил руками. Матрицы 3х3 это всего ничего операций.. ;)
Осталось импортозаместить Github
пытаемся утилизировать преимущества C++
Не совсем понятно, зачем утилизировать преимущества. Чем они вам не угодили? Наоборот их нужно использовать, разве не так?
Импортозамещаем numpy, pandas, scipy и sklearn