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...) Best, Mehdi 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 (https://github.com/serge-sans-paille/numpy-benchmarks/blob/master/evolve.py). 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 same. 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!