25-50% has been hoped for many times in the past 3 decades. I don't find that very impressive.
CPython got big because of its relatively decent C-API and glue capabilities. 25% does not make a difference, decent C extensions have speedups in the order of 10-100 times (yes, times, not percent).
If I had a dollar for every time someone proposed a Python speedup ...
There have been many similar talks in the past decades. At some point Unladen Swallow was presented as "Google's project" (which is quite exaggerated).
It looks more like Microsoft has JIT envy now that Instagram and others have open sourced (quite restricted) JIT projects and has to show presence again.
I think every CPython JIT project will be full of corner cases in both performance and behavior, so it will add to the growing database of weird Python behavior that users have to memorize.
Indeed, it all boils down to the way Python community doesn't embrace such projects.
Usually Python's high dynamism comes into the picture as main reason, however Smalltalk and SELF are just as dynamic, you can change the whole image at any given point in execution.
In Smalltalk it suffices to send a become: message to change the complete meaning of an object, and references to it, across the whole image.
> If I had a dollar for every time someone proposed a Python speedup ...
Well, that's just the thing. Many have tried, many have succeeded, but their work hasn't been upstreamed so adoption is almost nonexistent. This is different. It's finally a mainline project. That's noteworthy, and long overdue given the plurality of proofs-of-concept.
Mark Shannon's involvement is more interesting. There is no evidence Guido will be especially good at optimizing CPython performance (and arguably lots of evidence to the opposite). And as he's no longer BDFL it's not clear what power he really has to get his changes in if the Steering Council still shares his previous aesthetic preferences and not his current ones.
Guido track record speaks for itself: he gives an announcement, he studies the problems, he implements, he releases something that kinda works but is meh, he improves on it for years, and then you have a new python feature.
He always delivers. That's a trademark.
So yes, it's a big deal. It means something will come out of it no matter what, in opposition to everything that happened before.
I have absolute trust in GvR's decisions in many areas, particularly about language design and teaching programming. But I don't see that he has any special insights into VM performance, let alone the low-level intricacies JIT design.
As mentioned elsewhere in the thread he really has egg on his face after denying Python's performance problems for so many years. I would have more respect if he had taken a firm stance that keeping CPython's interpreter simple had pedagogical value, but instead he (and other core devs) repeatedly argued that Python did not have a performance problem, and that's why it was OK to keep it simple. It took until major pref regressions early in the Python 3 lifecycle to break out of this mindset.
> But I don't see that he has any special insights into VM performance, let alone the low-level intricacies JIT design.
The guy had no insights into language design before creating python.
He also has Mark Shannon, has the entire MS team available on the phone if needed (including the .net team, with stellar JIT), time and a good brain.
> As mentioned elsewhere in the thread he really has egg on his face after denying Python's performance problems for so many years.
He spent 20 years maintaining a project with minimal resources, so you have to make hard choices on what to work with. Perfs were not the objective of Python, and for the majority of the use cases of the time, it didn't matter much.
Now that more important things are sorted out, like unicode handling, and that Python 3 is a smooth running project, he is been given the opportunity and resources to work on the problem, so he does.
Good for us.
Honestly, for me perfs are still NOT a priority, I'd rather him work on bootstraping, but I'm glad and excited that something good will come out of this.
> The guy had no insights into language design before creating python.
Well, except for working on ABC for years, right?
> He spent 20 years maintaining a project with minimal resources, so you have to make hard choices on what to work with... Now that more important things are sorted out, like unicode handling...
I don't see any evidence of this being GvR taking undeserved credit rather than it just being another of the weird cults that 4chan has built up around major programming figures from the late 1990s.
