Note that this was one of the big ticket items in the 2019 NSF proposal
for the SciPy ecosystem:
https://figshare.com/articles/Mid-Scale_Research_Infrastructure_-_The_Scientific_Python_Ecosystem/8009441
For that proposal we got a lot of direct feedback from outreach to
prominent users in domains like economics, physics, and biology.
Example quotes:
"... my top-level concern as a person who supports users is whether
Python and the Scientific Python stack as a whole needs a rethink as
architectures become more parallel and individual cores become less and
less powerful. ... We don't have bright lines for Python users like we
have for C, C++, Fortran for performance portability. If your code is in
C++ we can talk about directive-based parallelism or specific libraries
or compilers that will help you minimize the amount of code you have to
rewrite to move across architectures (to be fair: it's rarely magic).
But things seem to lag in Python."
"Beyond individual features I think there's another issue worth thinking
about. Using things like numba efficiently is becoming more and more
useful to researchers, as special model types and solution methods may
not be written in vectorized form very easily or "beautifully". However,
since the whole chain has to be written using numpa for the JIT to fully
materialize itself, it's kind of an issue that scipy does not generally
support this way to solving problems in python (by that I mean something
that's not just fast because you're using Numpy and vector operations).
The leads to researchers writing their own optimizers, that are
essentially duplicates of well-known methods such as brent and golden
section search, multilinear interpolation and other methods, to speed up
their code. SciPy should handle this part of the problem-solving (it
does, but just not in a way that's efficient to the numba-users), but
currently we risk a lot of code duplication and bugs. I'm not involved
in scipy so I'm not fully aware of their stance of numba vs some of the
other possibilities out there, but the issue of being unable to
efficiently use @njit is a real issue in my opinion."
[ci skip]