On 5/13/2021 4:18 AM, Mark Shannon wrote:
Hi Terry,
On 13/05/2021 5:32 am, Terry Reedy wrote:
On 5/12/2021 1:40 PM, Mark Shannon wrote:
This is an informational PEP about a key part of our plan to improve
CPython performance for 3.11 and beyond.
As always, comments and suggestions are welcome.
The claim that starts the Motivation section, "Python is widely
acknowledged as slow.", has multiple problems. While some people
believe, or at least claim to believe "Python is slow", other know
that as stated, the latter is false. Languages do not have a speed,
only implementations running code for particular applications have a
speed, or a speed relative to equivalent code in another language with
a different runtime.
I broadly agree, but CPython is largely synonymous with Python and
CPython is slower than it could be.
The phrase was not meant to upset anyone.
How would you rephrase it, bearing in mind that needs to be short?
Others have given some fine suggestions. Take your pick.
[ship]
We want people to be able to write code in Python and have it perform at
the level they would get from a good Javascript or lua implementation.
I agree with others that this is a good way to state the goal. It also
seems on the face of it reasonable, though not trivial. I get the
impression that you are proposing to use python-adapted variations of
techniques already used for such implementations.
It is still important to speed up Python though.
I completely agree. Some application areas are amenable to speedup be
resorting to C libraries, often already available. Others are not. The
latter involve lots of idiosyncratic business logic, individual numbers
rather than arrays of numbers, and strings.
Numpy based applications gain firstly from using unboxed arrays of
machine ints and floats instead of lists (and lists) of boxed ints and
floats and secondly from C or assembly-coded routines
Python strings are already arrays of machine ints (codepoints). Basic
operations on strings, such as 'substring in string' are already coded
in C working on machine values. So the low-hanging fruit has already
been picked.
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.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/GFUISO3ZDYS7E3FV457AVRW2Q7B5BAVW/
Code of Conduct: http://python.org/psf/codeofconduct/
