Python and the need for speed

[bartc]

On 11/04/2017 09:19, Steven D'Aprano wrote:
> 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. So let's look at what the experts
> have done:
>
> PyPy: a complete re-write, with a completely different approach (JIT
> compilation).

A massively complicated approach, that not many fully understand. It can 
give some good results, but it's no longer executing byte-code.

(Yet /I/ can get good performance, that can often match pypy, and still 
be executing a byte-code at a time. But that's because the language is 
smaller and less dynamic.)

> WPython (alas, now more or less abandoned): a complete re-write of the
> virtual machine, using 16-bit "wordcodes" instead of 8 bit "bytecodes",
> nevertheless this enabled a lot of good optimizations:

> http://repository.root-me.org/Programmation/Python/EN%20-%20Beyond%
> 20python%20bytecode.pdf

Yes, tightening up some bytecodes. But with limited results (I think up 
to 2x as fast based on their results).

Most of the projects you've listed work with the language as it is; they 
do the best they can with what's already there.

Removing stuff from the language could help, but that is not an option, 
unless you call it Python 4 and break all compatibility. At the moment, 
with:

   def fn(): print("Yes")

   exec(s)

   fn()

You can't tell if that fn call will print Yes, No, or do anything else, 
because the exec() could have redefined it.

/Adding/ things to the language might have to the way forward, but it's 
already groaning under the weight of add-ons. And you don't want a 
feature that adds clutter that is only there for performance hints.

Well, a little clutter might be OK:

  constant pi = 3.14159

Now 'pi' is /guaranteed/ to be the value you've specified (unlike 
math.pi). That sort of thing can help optimisation /and/ readability.

-- 
bartc