On Thu, 20 May 2021 at 04:58, Terry Reedy <tjreedy@udel.edu> wrote:
>
> On 5/13/2021 4:18 AM, Mark Shannon wrote:
>
> > If a program does 95% of its work in a C++ library and 5% in Python, it
> > can easily spend the majority of its time in Python because CPython is a
> > lot slower than C++ (in general).
>
> I believe the ratio for the sort of numerical computing getting bogus
> complaints is sometimes more like 95% of *time* in compiled C and only,
> say, 5% of *time* in the Python interpreter. So even if the interpreter
> ran instantly, it would make also no difference -- for such applications.
Not necessarily because if the interpreter is faster then it opens up
new options that perhaps don't involve the same C routines. The
situation right now is that it is often faster to do more
"computation" than needed using efficient C routines rather than do
precisely what is needed in bare Python. If the bare Python part
becomes faster then maybe you don't need the C routine at all.
To give a concrete example, in SymPy I have written a pure Python
implementation of typed sparse matrices (this is much faster than the
public Matrix class so don't compare with that). I would like to use
the flint library to speed up some of these matrix calculations and
the flint library has a highly optimised C/assembly implementation of
dense matrices of arbitrary precision integers. Which of these
implementations is faster for e.g. matrix multiplication depends on
how sparse the matrix actually is. If I have a large matrix say 1000 x
1000 and only 1% of the elements are nonzero then the pure Python
sparse implementation is faster (it can be much faster as the density
reduces since it does not have the same big-O characteristics). On the
other hand for fully dense matrices where all elements are nonzero the
flint implementation is consistently around 100x faster.
The break even point where both implementations take equal time is
around about 5% density. What that means is that for a 1000 x 1000
matrix with 10% of elements nonzero it is faster to ask flint to
construct an enormous dense matrix and perform a huge number of
arithmetic operations (mostly involving zeros) than it is to use a
pure Python implementation that has more favourable asymptotic
complexity and theoretically computes the result with 100x fewer
arithmetic "operations". In this situation there is a sliding scale
where the faster the Python interpreter gets the less often you
benefit from calling the C routine in the first place.
Although this is a very specific example it illustrates something that
I see very often which is that while the efficient C routines can make
things "run at the speed of C" you can often end up optimising things
to use an approach that would seem inefficient if you were working in
C directly. This happens because it works out faster from the
perspective of pure Python code that is encumbered by interpreter
overhead and has a limited range of C routines to choose from. If the
interpreter overhead is less then the options to choose from are
improved.
Also for many applications it is much easier for the programmer to
write an algorithm directly in loops rather than coming up with a
vectorised version based on e.g. numpy arrays. Vectorisation as a way
of optimising code is actually work for the programmer. There is
another tradeoff here which is not about C speed vs Python speed but
about programmer time vs CPU time. If a straight-forward Python
implementation is already "fast enough" then you don't need to spend
time thinking about how to translate that into something that would
possibly run faster (potentially at the expense of code readability).
In the case of SymPy/flint if the maximum speed gain of flint was only
10x then I might not bother using it at all to avoid the complexity of
having multiple implementations to choose from and external
dependencies etc.
--
Oscar
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/BBNEBYO42RAXUM526ZUA65SAQTKCS3QD/ Code of Conduct:
http://python.org/psf/codeofconduct/