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

21–30 of 51 posts

Re: Making Cython as easy as Python

#21

Post by versteegen »

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 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.

Re: Making Cython as easy as Python

#22

Post by williamstein »

chuckbot wrote: post #18
cbsmith wrote: post #16

"Runcython aims to simplify the process of using Cython without sacrificing scalability." I know this is being a semantic weenie, but I hate when people use scalability when they mean efficiency.

And I hate when people use efficiency when they mean speed. Python -> Cython speeds up you program but does not change the complexity of your algorithm.

Sometimes it does. For example if you write a simple O(n) for loop in Python, then convert it to Cython, then compile it, the compiler may replace the for loop by an equivalent O(1) algorithm. I use this to surprise students when benchmarking Cython code for teaching purposes in my SageMath course.

Re: Making Cython as easy as Python

#23

Post by willvarfar »

Its an aside, but recently Python 3 has got annotations. It would be nice if cython supported annotation syntax, so that type-annotated cython was as much as possible valid python than can also be run through an interpreter.

I understand a lot of the nuances, particularly the lack of in-function annotations etc. My own foray into Python type annotations is obiwan https://pypi.python.org/pypi/obiwan/

Re: Making Cython as easy as Python

#24

Post by [deleted] »

oliwarner wrote: post #19
chuckbot wrote: post #18

Earlier quoted context omitted.

And I hate when people use efficiency when they mean speed. Python -> Cython speeds up you program but does not change the complexity of your algorithm.

How do you suppose it speeds it up then? I'll give you "the complexity of your algorithm" likely doesn't change, but how that algorithm is processed is usually more efficient when compiled through C, rather than running through a Python interpreter, if only because of how it's running.

[deleted]

Re: Making Cython as easy as Python

#25

Post by vog »

icebraining wrote: post #10
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…

It's practical, but on the other hand, that goes against the security practice of not allowing the executable zone (be it memory or filesystem) to be writeable. I personally prefer to precompile stuff, even running "python -m compileall" to create .pyc files, to avoid having to keep that path writeable by the user running the program.

Good point! However, if you go down that route in a web application, don't forget to pre-compile templates, and do the same for all other cached things that are "code-like".

More generall, I find W^X hard to enforce in typical web applications. Sure you can mount directory read-only, disable access to /tmp and observe what happens. But then they might use the database as template cache, or whatever.

In most (web) application I'd be happy if they had a central directory where they write stuff into (bonus points for making that directory configurable), instead of scattering generated files all across the source tree.

Re: Making Cython as easy as Python

#26

Post by chuckbot »

oliwarner wrote: post #19
chuckbot wrote: post #18

Earlier quoted context omitted.

And I hate when people use efficiency when they mean speed. Python -> Cython speeds up you program but does not change the complexity of your algorithm.

How do you suppose it speeds it up then? I'll give you "the complexity of your algorithm" likely doesn't change, but how that algorithm is processed is usually more efficient when compiled through C, rather than running through a Python interpreter, if only because of how it's running.

I agree it is faster by running it through compiled C code.

Saying "my code is more efficient than your code" might be acceptable, but saying "my code is efficient" drives me mad when it is used as a synonym for "my code is fast". Take a look at [1] and the note that this is not about optimization. Efficient algorithms are usually algorithms with close to optimal time or space complexitiy.

https://en.wikipedia.org/wiki/Algorithmic_efficiency

Re: Making Cython as easy as Python

#27

Post by Fede_V »

williamstein wrote: post #22
chuckbot wrote: post #18

Earlier quoted context omitted.

And I hate when people use efficiency when they mean speed. Python -> Cython speeds up you program but does not change the complexity of your algorithm.

Sometimes it does. For example if you write a simple O(n) for loop in Python, then convert it to Cython, then compile it, the compiler may replace the for loop by an equivalent O(1) algorithm. I use this to surprise students when benchmarking Cython code for teaching purposes in my SageMath course.

If it's just a matter of speeding up a tight loop, I find numba performs admirably and it's a lot more convenient than Cython.

When you need to wrap some c code, or use high-level data structures (that cython handles beautifully with STL integration) that's when it makes sense to drop to Cython.

Re: Making Cython as easy as Python

#28

Post by andreasvc »

zzleeper wrote: post #4
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'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?

The gap that Julia has to fill in terms of library ecosystem is definitely large.

Numba is specific to numeric/array-oriented code. Cython is general-purpose and can also be used to implement e.g. datastructures.

Re: Making Cython as easy as Python

#29

Post by rplnt »

chuckbot wrote: post #18
cbsmith wrote: post #16

"Runcython aims to simplify the process of using Cython without sacrificing scalability." I know this is being a semantic weenie, but I hate when people use scalability when they mean efficiency.

And I hate when people use efficiency when they mean speed. Python -> Cython speeds up you program but does not change the complexity of your algorithm.

Efficiency of the user is likely better with this tool.

Re: Making Cython as easy as Python

#30

Post by Tarlitz »

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…

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.
Post reply on HN