Python and the need for speed
Brecht Machiels
brecht__gmane at mos6581.org
Tue Apr 11 05:56:06 EDT 2017
On 2017-04-11 08:19:31 +0000, Steven D'Aprano said:
> On Sun, 09 Apr 2017 19:05:35 +1000, Chris Angelico wrote:
>
>> When people talk about making a restricted optimizable subset of Python,
>> the implication (if not the explicit declaration) is that it's done
>> strictly by removing, not by rewriting.
>
> Maybe *some* people have a naive, if not foolish, idea that all you need
> to do to speed up CPython is to go through the C code and hit delete over
> any functions you don't want. But that's hardly a technique that is going
> to work: not only will you break features, but merely removing code
> doesn't magically make the rest of the code base faster.
>
> At the very least, you have to re-write the code that depends on the
> features you have just removed.
>
> If we're going to talk about speeding up Python, we ought to talk about
> *serious* approaches to the problem, not the musing of random, ignorant
> bloggers and other naive commentators.
Hey! This random, ignorant blogger has feelings too! :-)
I don't know much about interpreter or compiler design, but I never
claimed that speeding up CPython would simply be a matter of deleting
some code. I merely suggested that approaches different from PyPy and
other JIT compilers should be explored, since I do not feel that these
projects are delivering satisfactory results. I am glad to see it got
this discussion started, at the very least.
> some are actively maintained and
> used in production by many people (cython, PyPy).
Are there any statistics on PyPy usage? I'm not convinced it is being
used widely. As far as I can tell, it really is only useful for server
applications because of the long JIT warm-up time.
> The Python ecosystem is actually quite healthy, if you need to speed up
> code there are lots of solutions, and some of them are even good
> solutions.
There seem to be no solutions for my use case (rinohtype). DropBox and
Google seem to agree that there are no good solutions, since they are
moving to Go.
> Nevertheless, it is interesting to discuss whether or not any
> of these features will go mainstream or make it into CPython.
Indeed! I initially wanted to include the following in the article, but
decided it would be too controversial. But now that I've been exposed
as an ignorant and naive blogger, I might as well share these thoughts.
I have the feeling that a faster Python will never materialise unless
the CPython core developers make performance a high priority. I
understand that high performance was never a goal in CPython
development (and Python language design!), but recent events (DropBox,
Google) might help to reconsider that standpoint.
Here's a wild idea: consider Python 3 feature-complete. Similar to how
Python 3 cleaned up the unicode and other warts of Python 2, Python 4
could clean up the performance warts, but retaining the "soul" of the
language. But that last part is a diffucult one, because it would lead
to endless discussions of what would still be Python. So it's better to
define an official "TurboPython" subset. This would also ensure
backwards compatibility, but of course complicate the implementation.
But who am I (or anyone) to suggest what the CPython core developers
should do? I can only supply food for thought.
Best regards,
Brecht
More information about the Python-list
mailing list