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
--
https://mail.python.org/mailman/listinfo/python-list
