[pythran] Re: Trying to understand why Pythran does so well on the diffusion example

  • From: Mehdi Amini <mehdi.amini@xxxxxxxxxx>
  • To: pythran@xxxxxxxxxxxxx
  • Date: Sat, 12 Apr 2014 17:42:04 -0700

Hi Ian,

I checked the evolve.py test case and I didn't find any magic :)
I would even say that we should be able to do *a lot* better in such cases (lazy evaluation + fusion)...

Numpy is (only) two times slower but their implementation is in Python and the algorithm is different. Here is the numpy implementation: https://github.com/numpy/numpy/blob/master/numpy/core/numeric.py#L1314 Here is ours: https://github.com/numpy/numpy/blob/master/numpy/core/numeric.py#L1314
(yes our C++ is absolutely awful because of the lack of comments...)



On 4/12/14, 4:51 AM, Ian Ozsvald wrote:
Hi all (Serge - I'll reply to your other mail with a bug report+demo
shortly). I'm writing up my compiler/JIT chapter.

For Pythran I'm using a slightly modified evolve.py example
I'm trying to understand why it does so well against Cython. The
modification is only for the benchmark, the guts of the code are the

Here's my situation with a (8192, 8192) grid:
Pure numpy version (no pythran) 1 iteration of evolve() - 3.8 seconds
Same code, compiled with Pythran - 1.5 seconds
Same code, annotated in Cython 0.20.1 - 3.8 seconds
Same code using Numba - 3.8 seconds

I might have to write "these guys do magic" but I fear my readers
would find that unsatisfying. What's going on in here? I'm compiling
just with pythran, no omp, no other flags.

I've checked that the output of evolve is operating correctly (pure
py, pythran, cython evolve the same way). I had assumed pythran
couldn't do much as the calls to numpy are few and numpy does all the
work...so maybe you're rewriting/specialising some of the numpy calls?
Something to do with roll?

Any insight would be most happily received!

Other related posts: