Обновить
Комментарии 17
Для C/C++ использовался Clang? Почему не g++?

У Numba есть GPU support — что-нибудь про него будет?
.
.
Сначала создают какой-то язык простым/удобным/etc., он оказывается медленным (и + другие изъяны), потом его дополняют, доделывают,…, в итоге он уже вполне ничего. Но сложность возросла. И он уже не проще ранее создававшихся. Зато у него есть сообщество почитателей, которых в своё время привлекла простота, и они постепенно расли вместе с языком. Т.е. имеем манипуляцию сознанием способ управления сообществом (привлечение и удержание программистов).
Надеюсь, тут ниже ответят, чем Python много лучше Smalltalk (и прочее «новое против старого»).

Для C/C++ использовался Clang? Почему не g++?

Я взял верхнюю строчку из таблицы в статье про хаскелл. Там g++ тоже есть.


У Numba есть GPU support — что-нибудь про него будет?

Я его упомянул мимоходом в первой части, но, действительно, надо бы расширить.


Вряд ли Гвидо ван Россум ставил себе целью манипулировать чьим-то сознанием :)

Динамическая типизация, куча "батареек" в комплекте и еще более куча удобных библиотек — от такого очень трудно отказаться, когда распробуешь первую дозу.
Поэтому и пытаются приблизить C++ по удобству к питону, а питон — по скорости — к C[++] (образно говоря).
А счастья всё нет и нет...

Динамическая — это плохо. По разным причинам. Начиная от того, что это error-prone, кончая тем, что это очевидно влияет на качество компиляции/ интерпретации

"Python — язык для быстрого прототипирования приложений" ©
Для этого случая динамическая типизация — хорошо.

Только в этом случае numba не нужна… Т.к. мы быстро прототипируем, а не пытаемся костылить ускорение.....

… и вот мы напрототипировали себе на Django некий web-сервис, и работает он приятно и прельстиво.
Но нам надо в нем молотить математику какую-нибудь (ну там распознавание лиц например).
И что — всё ломать и переделывать на Java или С++ (ни к ночи)?
Если оно работает, работает нормально (кроме вычислений) и делается только в одном экземпляре.
Естественно в этом случае эффективнее прилепить костыль в виде numba и больше не возвращаться к этому вопросу.

Но нам надо в нем молотить математику какую-нибудь (ну там распознавание лиц например).

внезапно, но это тогда делается внешними программными модулями ) Так что именно про распознавание лиц — пример неудачный.


Если оно работает, работает нормально (кроме вычислений) и делается только в одном экземпляре.

так определитесь — это MVP, прототип, или продакшн решение ?

Так что именно про распознавание лиц — пример неудачный

Там приписка специальная — "например".
Выберите любую вычислительную задачу по своему вкусу.


MVP, прототип, или продакшн решение

Это прототип, выросший до production.
Как всегда.

Да основной юз-кейс numba для меня это использовать её для тех частей алгоритмов которые не ложатся легко на numpy. Но сейчас есть ещё xtensor для С++ который выглядит как питон и тоже легко интегрируется с массивами numpy через pybind11, пока не подвернулось случая опробовать.

Видимо, это зависит от склада ума.


Я пробовал писать на питоне. Честно. Но я начинаю теряться, и моя производительность как программиста начинает проседать, если у меня там больше 10 строк или двух функций.


Со статически типизированными языками такого нет (не с любыми, конечно). Там типы помогают.

Есть такое дело.
Однако в том же питоне — слава богам — до "1 — '1' = 0" не дошло.
(как в не будем тыкать пальцами некоторых других популярных языках)

НЛО прилетело и опубликовало эту надпись здесь

В numba есть альтернатива классам – custom dtypes из numpy (я их упоминал в первой части), они работают с нормальной скоростью, но там с синтаксисом, пока что, беда. Например, если для доступа к полям использовать обычный синтаксис полей класса (a.y2), то просто убрать @jit в процессе отладки не получится – придётся всё переписывать на a['y2']. Это можно было бы решить допиливанием numpy. Ну типа написать соответствующий враппер. Я попробовал – так сходу у меня не получилось, слишком уж много наворотили в np.ndarray.

Для меня одной из самых приятных вещей оказалось @njit(parallel=True)

НЛО прилетело и опубликовало эту надпись здесь
Одна из базовых проблем быстродействия Питона кроется в невозможности файнтюнить выделения памяти. Питон все время выделяет маленькие кусочки памяти и это сразу ложится грузом на быстродействие.

Особенно ярко это проявляется, когда пытаешься распарсить какой-нибудь XML. Для каждого нода, для каждого аттрибута будет выделение памяти даже в том случае, если 99% этих данных ты даже не будешь считывать. Как позорное напоминание, есть С++ библиотека RapidXML++ с кастомным менеджером памяти, к которому Питон даже близко не может подойти по быстродействию.

Однажды молодые инженеры делали робота и у них был итеративный модуль «смягчения» пути: по грубым точкам пути надо было сделать более плавный путь, вставив промежуточные точки, и при этом уложиться в две миллисекунды. Проблема решилась написанием кастомного модуля на Cython только после того, как убрали выделение памяти с кучи (вся память выделялась на стеке).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.