MIR vs. Numpy

[John Colvin]

On Wednesday, 18 November 2020 at 13:01:42 UTC, Bastiaan Veelo 
wrote:
> On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt 
> wrote:
>> Dear all,
>>
>> to compare MIR and Numpy in the HPC context, we implemented a 
>> multigrid solver in Python using Numpy and in D using Mir and 
>> perforemd some benchmarks with them.
>>
>> You can find our code and results here:
>> https://github.com/typohnebild/numpy-vs-mir
>
> Nice numbers. I’m not a Python guy but I was under the 
> impression that Numpy actually is written in C, so that when 
> you benchmark Numpy you’re mostly benchmarking C, not Python. 
> Therefore I had expected the Numpy performance to be much 
> closer to D’s. An important factor I think, which I’m not sure 
> you have discussed (didn’t look too closely), is the compiler 
> backend that was used to compile D and Numpy. Then again, as a 
> user one is mostly interested in the out-of-the-box 
> performance, which this seems to be a good measure of.
>
> — Bastiaan.

A lot of numpy is in C, C++, fortran, asm etc....

But when you chain a bunch of things together, you are going via 
python. The language boundary (and python being slow) means that 
internal iteration in native code is a requirement for 
performance, which leads to eager allocation for composability 
via python, which then hurts performance. Numpy makes a very good 
effort, but is always constrained by this. Clever schemes with 
laziness where operations in python are actually just composing 
operations for execution later/on-demand can work as an 
alternative, but a) that's hard and b) even if you can completely 
avoid calling back in to python during iteration you would still 
need JIT to really unlock the performance.

Julia fixes this by having all/most in one language which is JIT'd

D can do the same with templates AOT, like C++/Eigen does but 
more flexible and less terrifying code. That's (one part of) what 
mir provides.