Comment by versteegen | Hacker News Reader

Comment by versteegen | Hacker News Reader

Parent Full thread

I disagree, and see the proliferation of all these performance-focused libraries/compilers as proving that CPython's slow speed is a huge problem. I haven't used Numba, but after my experience with others I conclude that you just can't totally escape the fact that CPython is slow. Having to use tools like Cython is a big tax that's cost me weeks or months of time.

Firstly numpy/scipy don't help if you can't write your algorithms in terms of operations on multidimensional arrays, and numpy overheads (creating and accessing ndarrays) are actually prohibitively large if the arrays aren't large, easy to be slower than straight Python. First I tried writing code (scientific stuff) in type-annotated Cython. But it turns out that data structures are the bottleneck if your algorithms need to read/write something other than a bunch of numpy ndarrays. If you try to use lists, dicts, etc, you still go through the Python runtime so get little speed benefit over Python. (Cython optimises ndarray accesses.)

So I ended up writing C++ code and interfacing to it using Cython. But now I have to write a huge amount of code to translate between the Python/Numpy and C++ datastructures. And it's bug prone due to memory allocation and ownership. Using multiple poorly compatible languages is a miserable experience. Julia sounds fantastic. Don't get me wrong though, I love Python, but it wasn't designed for scientific computing. And most of the time, numpy, scipy & friends are all that you need or want.

Your second point is spot on. I realized this when I tried to optimize my numpy code that does millions of dot products between 3x1 vectors and 3x3 matrices to no avail. I realized there is an awesome little library called tinyarray, that doesn't have the overhead of numpy, and is compatible with the basic numpy syntax. I exchanged all my numpy arrays for tinyarrays and got the easiest 10x speed up ever.

Thanks for mentioning that, very useful!

If you look in the numpy source you can begin to understand why the overheads are so large: for every operation it's first necessary to apply rules for broadcasting between different sizes and types, plus often being callable with a number of different function signatures (that includes __getitem__). And in many cases all of that is implemented in Python.

fwiw - the best you can do here, is probably implement the dots yourself as cdef functions. If your arrays get larger, you can get a C pointer to the blas routine from scipy and call it from cython (which can be faster than the dot you write when your arrays are larger)

I don't see why you would use Cython when you are writing C/C++ anyway. All the trivial data types and wrappers are easily handled by SWIG. Just don't try to wrap any non-trivial types with SWIG, instead declare them as `PyObject *` and use the Python/C API for those. Demo of this technique: https://github.com/martinxyz/python/tree/master/realistic

The main advantage of using Cython for glue code is that you don't need to touch the Python/C API, it generates the necessary code for you (in particular it handles the reference counting). (I like to think of Cython as 'C with easy access to the Python runtime'.) However, the API certainly doesn't look scary in these examples (I've never really used it). Admittedly I didn't consider SWIG, so thanks for that. It would be nice to be rid of the Cython glue layer, so I might try that. Of course that would mean writing much of the glue (sanity checking) in C++ or Python instead of Cython.

Reply on news.ycombinator.com