Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Cython as easy as Python

github.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Making Cython as easy as Python

#31

Post by shoyer »

pathsjs wrote: post #20
shoyer wrote: post #14

Earlier quoted context omitted.

> The problem with the Python ecosystem is that there exist a lot of libraries for scientific computation mostly incompatible with each other (blaze, numpy, numba, numexpr, dask...). I actually disagree completely with your specific examples. These projects have mostly orthogonal goals and are actually quite compatible with each other -- they all speak NumPy arrays. In fact, three of them (Blaze, Numba and Dask) are…

I am not quite sure. Let me be more specific. Dask requires you to encode computations as a graph explicitly, essentially forcing you to write an AST manually. This means that you are sidestepping the normal language mechanisms to encode program flow, and doing so is essentially incompatible with anything else. Moreover, it does not use numpy arrays - it uses its own internal format that you can convert to a numpy ar…

I appreciate where you are coming from, but on many of these projects you are just misinformed.

The entire point of dask is to enable parallel and bigger than memory computations that are not be possible with NumPy arrays. It uses an internal graph representation for deferred computation because deferred computation is basically the only sensible way to do these computations. But in fact, a major point of dask is that users should not need to write these task graphs explicitly. The dask.array API is actually designed to be almost a perfect match for NumPy. The docs do a nice job of explaining the internal abstraction, but understanding it is by no means necessary to use it. (Dask is not my project, but I have made quite a few contributions to it.)

Numba certainly does deviate from mainstream Python, but in my experience it works very much in line with the needs and expectations of scientific python users.

As for Blaze, it's changed a long way since Travis wrote that blog post in 2012. This website provides a better overview of what Blaze is today: http://blaze.github.io/. Confusingly, the name is used for both an ecosystem and one of its major components more specifically. Dask is a component of the larger Blaze project.

> Jython, which is the only multithreaded Python interpreter.

This is not quite true. Python supports multithreading, and CPython's GIL is less of a obstacle to numerical computing than you might think: http://matthewrocklin.com/blog/work/2015/03/10/PyData-GIL/

Re: Making Cython as easy as Python

#32

Post by Matumio »

versteegen wrote: post #21
vegabook wrote: post #3

Cython, Numpy, Numba (and others) are what make me skeptical that any of the numerical computing competitors to Python (Julia, or to a lesser extent Lua/JS/Clojure even compiled Scala etc) can displace it at. Why would you abandon this wonderfully friendly, malleable language with easily the largest set of options for anything you might like to do, for something nominally faster on an artificial benchmark (which inev…

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 you…

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

Re: Making Cython as easy as Python

#33

Post by synparb »

dagw wrote: post #13
zzleeper wrote: post #4

Earlier quoted context omitted.

I've seen some very impressive Julia libraries that perform almost at the level of C code, so I'm not sure if the gap that Julia needs to fill is that large. Also, a quick question: which one is preferred nowadays, Cython or Numba?

Cython is much more mature, works on basically all python code and basically never leads to slowdowns compared to pure python. Unfortunately non of that can really be said about Numba. That being said, when Numba works it's great and is much easier to work with than cython.

I'll echo @dagw's comments. Cython has been rock solid for me for a long time and it is my go to for any sort of external c/c++ library interfacing. That said, I find myself using Numba more and more in the places that I can as Numba has gotten significantly better in the last 6 months or so. It's still not a complete replacement for cython (and I don't think it ever will or intends to be), but for hot spot numerical calculations it's really nice since it's much faster to test things out since it doesn't involve the boiler plate required by Cython, and doesn't require the (often slow) compilation times.

In Numba 0.21.0, on-disk caching of jit'd code was also introduced, which was one of the major sticking points for us to put Numba into production in areas where we needed faster start-up times. Before we could really only use Cython because we required the start-up times available only from AOT compilation.

That all said, Numba has been a bit buggy for me at times, although these get squashed pretty quickly. I've only found a single bug in Cython in all of the years I've been using it, and it's amazing how quickly Robert Bradshaw or Stefan Behnel respond and fix things considering Cython is not their full time job.

Re: Making Cython as easy as Python

#34

Post by versteegen »

Tarlitz wrote: post #30
versteegen wrote: post #21

Earlier quoted context omitted.

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 you…

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.

Re: Making Cython as easy as Python

#35

Post by versteegen »

Matumio wrote: post #32
versteegen wrote: post #21

Earlier quoted context omitted.

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 you…

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.

Re: Making Cython as easy as Python

#36

Post by vegabook »

pathsjs wrote: post #8
vegabook wrote: post #3

Cython, Numpy, Numba (and others) are what make me skeptical that any of the numerical computing competitors to Python (Julia, or to a lesser extent Lua/JS/Clojure even compiled Scala etc) can displace it at. Why would you abandon this wonderfully friendly, malleable language with easily the largest set of options for anything you might like to do, for something nominally faster on an artificial benchmark (which inev…

The problem with the Python ecosystem is that there exist a lot of libraries for scientific computation mostly incompatible with each other (blaze, numpy, numba, numexpr, dask...). Some of them try to reintroduce types in order to compile to native code, thereby losing the advantages of dynamic typing. In short, it is a mess, and everyone is trying to add on this because the existing ecosystem is big and the cost of…

I am intrigued by Nim. Does it have a REPL though? I think an official REPL (not a third party hack) is mandatory for scientific/numerical computing. Ocaml is the only compiled language I can think of which has a credible REPL, officially supported.

Re: Making Cython as easy as Python

#37

Post by hogu »

Tarlitz wrote: post #30
versteegen wrote: post #21

Earlier quoted context omitted.

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 you…

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.

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)

Re: Making Cython as easy as Python

#38

Post by hogu »

python_que wrote: post #7

I am using Python to solve combinatorial problems, and so my code relies heavily on the itertools library. My question is if I would still get a considerable speed-up if I rewrite some of my code in Cython, given my reliance on itertools?

it may be worth checking out cytoolz

Re: Making Cython as easy as Python

#39

Post by dkersten »

vog wrote: post #2

This strategy should be more common! In the source tarball, there should be one main program which you start. The compiling should be an implementation detail of the main program. The same for web applications. I never liked the idea of reintroducing a separate build (concat/minify/compress) process whenever the sources change. Instead, the production mode should be as simple as the debug mode: When the main page is…

I like to write my code to assume that it will run the same on dev and prod, but then precompile/minify prod code as part of the deployment.

That is, I like to set it up like you say, but then not rely on it in production. Mainly because I want as few moving parts as possible on prod (especially if it means I don't need dev tools/libs on the production server).

Re: Making Cython as easy as Python

#40

Post by mathnode »

hogu wrote: post #38
python_que wrote: post #7

I am using Python to solve combinatorial problems, and so my code relies heavily on the itertools library. My question is if I would still get a considerable speed-up if I rewrite some of my code in Cython, given my reliance on itertools?

it may be worth checking out cytoolz

Yup. Cytoolz. Some notes on performance of Cytoolz:

http://matthewrocklin.com/blog/work/2014/05/01/Introducing-C...

Post reply on HN