Пишем код C на Cython

[gbg]

Пример не показательный: Векторные операции выписаны явно, в формулах легко запутаться и наделать опечаток, а конструкция:

s3 = sqrt(s.x * s.x + s.y * s.y)
s3 *= s3 * s3;

Заставила взгляд сперва запнуться, потом пришлось пораскинуть мозгами (зачем извлекать корень, а потом возводить в квадрат?), и только потом понять, что тут так хитро возвели в куб квадратный корень. Повеяло Индией.

На C++/Boost* это дело было бы в 4 раза короче и гораздо более надежно и масштабируемо (захотели больше координат — не проблема).

В целом, это одна из программистских идиосинкразий «пишу все на одном языке». Если к вам в 21 веке придет монтировать мебель плотник, у которого из инструментов только топор, как вы себя почувствуете?
___________________
*Здесь бы даже фортран бы справился лучше.

[mibori]

Не использую плюсы и питон в своей работе, но код на питоне, субъективно, выглядит читабельнее, чем код на плюсах.

[chersanya]

Работа с массивами — это всегда боль, зато они быстрые. Списки чрезвычайно удобны, но очень медленные.

Вы numpy использовали? Откуда там боль, всё отлично сделано, включая интеграцию с Cython (те самые typed memory views).

Приведённый код как-то не впечатлил: глубоко не смотрел, но на первый взгляд с использованием numpy в разы короче бы получилось. Выше пишут, что даже на сях короче получилось бы. А для достижения наибольшей скорости посмотрите всякие BLAS, MKL, IPP… — если проводимые вычисления хорошо раскладываются по функциям оттуда, то будет значительно быстрее. Их все можно нормально юзать из Cython.

[gbg]

Так как тут куча векторов складывается с кучей векторов и умножается на коэффициент, можно использовать BLAS Level3 (GEMV, HEMV).

Собственно, BOOST и реализует интерфейс к BLAS в манере C++, чем и приятна.

[chersanya]

Только *MV функции это матрица*вектор, т.е. level 2 :)

[gbg]

Опечатался, нужны все же функции *MM, там к каждому вектору прибавляется его ускорение.

[gbg]

Списки чрезвычайно удобны, но очень медленные.

Списки тормозят на произвольном доступе, а тут кругом — последовательный.

[chersanya]

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

Если же вы про питоновские списки, то они тоже проигрывают массивам в скорости — в них хранятся указатели на элементы, а сами элементы соответственно тоже разбросаны по памяти. Да и просто удобнее же с numpy-массивами работать для вычислений :)

[iroln]

Автор (не переводчик) о NumPy, похоже, не слышал. NumPy, собранный с MKL, и вся векторизация с оптимизацией доступна из коробки. Cython поддерживает работу с numpy-массивами и эффективную работу с numpy-данными в памяти через Memoryviews.

Не надо всё подряд писать на Cython. Просто зачем? Не понимаю. Автору оригинальной статьи нравится заниматься микрооптимизациями всего подряд?

[iroln]

Последний абзац статьи я прочитал, понятно, что автор знает о numpy, просто не понятно зачем весь код писать на Cython. :)

[Zerstoren]

Я не вижу потребности писать даже 1/10 кода на cython, потому что пайтон не самый тормознутый язык, но очень локаничный, что не скажешь о Cython.

Код на cython можно писать только тогда, когда вы встречаете узкое горлышко в вашем коде, сложная итерация или сложная математика и компилитть код в пакет пайтона.

Я замерял какую-то математику, которая абсолютно эквивалентна была на 3х языках: Python. Cython, C

Python был медленее С в 35 раз.
Сython был медленее С в 2 раза.

Но не уж-то у вас (относительно автора) в коде столько математики, что нужно использовать cython везде? Может уже проще переехать на С++?

[degs]

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

[Hixon10]

Извините, я немного не понял из статьи, зачем вы пишите на Cython а не на С/С++?