Comments on the points being made based on my experience
- without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed)
- No large PRs (how a 5x speedup can take place with small patches that no one figured out yet?)
- a small team (not enough money, less risky if they tried to adopt other pypy-esque projects that are more advanced speed wise, a more comprehensive plan that would invite donations, I would certainly give. For this presentation I don't know)
WRT large PRs, it doesn't sound like they expect all the improvements to be from small changes. I think the point is the code will be changed in increments so that even large changes (overall) will be easier to review and offer feedback.
I don't think "without breaking anyone's code" even needs to be a goal. Python has rolling deprecations and feature removals planned in the 3.x release series, and careful such feature transitions could be used to help JIT features or similar, too.
> without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed)
The Python 3 debacle is a beautifully worked example of why being backwards compatible is so important, and I can 100% sympathize with them not wanting to go through that again.
Well, glad he's coming around. Years back he seemed to stand by the notion that Python wasn't slow, showing a toy example. I remember thinking it was just condescending, whether intentional or not.
Nodejs is much faster than Python even for workloads where there's overlap in use-cases, like webapis and scripting.
The only production language with performance in the ballpark of Python is Ruby.
I agree that more often than not it simply isn't an issue, but CPython performance isn't much far ahead of toy languages, for a whole lot of reasons that we are all sick and tired of hearing.
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.
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 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.
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...
> 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.
Why do people in the Python community get so excited over announcements? I'd rather see working code, but no one cares about that in the Python universe.
It is always announcements, talks, conferences and if something emerges it is a bit weird like the pattern matching.
Meanwhile the Erlang people quietly produced a JIT without any advertisements.
> Why do people in the Python community get so excited over announcements?
When you like a tech, knowing people are brewing improved perfs on it is kinky. On Python, the motto has always been "it's fast enough", "if you want perfs, don't use python", "C extensions will solve this", "we don't want to make the main implementation complicated", "python dynamism and GIL make it a hard problem", etc.
So in the python world, it's particularly big news, especially given that previous attempts (gilectomy, unladen swallow, first pyston...) all died.
> So in the python world, it's particularly big news, especially given that previous attempts (gilectomy, unladen swallow, first pyston...) all died.
This is precisely the point you seem to be missing. All those things you mentioned were similar big announcements back in their day, and they all have just died by fizzling. What should be setting this one apart?
When Guido was the BDFL (but whom am I fooling, everyone still will blindly accept a PEP from him and his opinion will still weigh a ton, steering council or not), he was pretty actively against any kind of bytecode-level optimization even though a lot could be done that way, citing “simplicity” and “readability”. Most Python core developers have had pretty much a Pavlovian response to shut down any and all such discussions.
I think they could get away with it for a while because none of the competing implementation would readily steal Python’s darlings, namely NumPy/SciPy and Tensorflow. Now there is competition, and it can really push CPython away to being a niche “reference implementation”, thus we are seeing these twitches.
The track record of CPython core team in the last decade makes me very wary when it comes to bringing in such features. Ship it or it didn’t happen.
P. S. Microsoft once threw a large sum of money at Kenneth Reitz to work on Requests, anyone remembers how that story ended?
What track record does GvR have in terms of speeding up CPython? He did not care for 3 decades (which is a defensible position given C extensions) and has been literally called "the boat anchor" by another HN member many times.
Mypy was Jukka Lehtosalo's work, asyncio was fixed and extended by many.
So now he needs a project at Microsoft, he changed his mind (or had it changed under pressure) and this is the project. We'll see, I agree though that the first version will be underwhelming, the following versions will have a max speedup of 50% but will be celebrated at conferences and here.
Reitz is no core dev, true, but he serves as an illustration and a cautionary tale of what can happen if you throw large sums of money at seemingly-prolific people hyperactive on socmedia.
Namely, that it’s absolutely not guaranteed to work.
>Why do people in the Python community get so excited over announcements? I'd rather see working code, but no one cares about that in the Python universe.
Because almost everything you've seen as 'working code' started its life as an announcement.
And because to coordinate and discuss future work, there would need to be some announcements.
And because some announcements (based on the persons, e.g. here GvR is involved) or the funding (e.g. here MS is involved) or the specificity (e.g. here 3.10 timeframe is discussed) are more important than others.
>Meanwhile the Erlang people quietly produced a JIT without any advertisements.
Good for them. That's maybe because much fewer care for Erlang (and thus for the advertisements) related to Python (which has a much larger dev base), so the advertisements of the former are posted fewer times and discussed by fewer people.
Just to add on the coordination point. Python has a large user base, and that's not to say larger user numbers equals better/superior. So the broadcasting of intention or direction is certainly welcome.
Not only is it a large user base, but a varied one too. Flask, Django, FastAPI, Twisted...and that is just to name the web frameworks! We have scientific use, research use, cli tools. Perhaps in some cases end users (developers or not) of those tools may not be aware Python is the foundation of said tool.
Anecdotally the Erlang users I've met have been incredibly knowledgeable and in tune with the language features and development. I find that pretty cool.
In my opinion, an argument can be made that Elixir is the most prominent web framework for the language, so developers can just keep up with that and not the language if they wish. Compared to the Python ecosystem. As Erlang inevitably grows in popularity, it too may fragment.
I'd like to see optimizations targeting ctypes, or a successor to ctypes. I wish I could write elegant, performant C wrappers in pure Python. Right now the best choices are Cython, which is a hassle (separate, slow compilation, various warts), and ctypes, which is slow (and has some design problems of its own). Julia's ccall alone is a major selling point over Python right now.
CFFI [1] is a step in the right direction, inspired by LuaJIT's CFFI. It originated from the PyPy folks and is supported in PyPy [2]; it's also supported to some degree by Numba [3]. I don't know what level of C call optimization is available when using the JITs, so I can't speak to the performance, but I've used it casually via CPython and was impressed by the API. That said, it has been around for a while and the traction seems somewhat limited -- I would guess because most people who have this kind of problem also need more than "just" FFI.
@fdej: what successor to ctypes did you have in mind? Other than the names (I prefer i8 over c_int8, but easy to work around) and lack of ergonomic interop with python ints, are there other issues you're aware of?
My number one wish would be the ability to read definitions from .h files automatically. Other than that, I've had some issues with memory management with ctypes (objects being deallocated prematurely) that I never had with Cython, but that may just be my own fault. I agree about the lack of interop with Python ints.
> My number one wish would be the ability to read definitions from .h files automatically.
This was originally a feature of ctypes but was dropped before stdlib inclusion because it's difficult to solve in the general, "public distribution" case. Nonetheless I don't think there's any need to replace ctypes to reintroduce it, it was done as a library / external tool before and still could be.
I'm excited about WASM here. https://github.com/wasmerio/wasmer-python lets you call WASM binaries from Python, which means if you can compile a C library to WASM you can then call it from Python... without having to worry about introducing crashing bugs and security vulnerabilities thanks to the WASM sandbox.
It's good to see that python startup time is an explicit goal. Empty scripts taking 10-100ms is a problem if you use python in Makefiles, where you can have thousands of invocations in a build. This wasn't considered a use case upstream cared about for quite some time. I'm glad to see this is changing. Here's hoping the acknowledgement will result in concrete gains!
Just wondering, why is CPython a lot slower than JS? It seems to me that both languages are interpreted and comes with some reflection functionalities (like modifying object methods), but JS seems a lot faster in most of the benchmarks in https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Edit: Why is this being downvoted? Is my statement incorrect or offensive to some people?
I suspect Node is still quite a lot faster than Pypy because the former benefits from v8 which is a well-funded project which doesn’t have to worry about compatibility with the sprawling C-extension interface that CPython exposes.
JS have been heavily optimized by browser vendors, fueled by the intense competition on the browser space, and the huge resources invested by companies like Google.
IIRC Firefox 3 was the first browser to have what we would call a modern JS engine, with heavy emphasis on JIT compiling. Google Chrome soon followed and V8 dominated the JS perf story.
Python doesn't have such fierce competition of implementations. And besides, it has the "escape hatch" of being able to implement performance-critical code paths as C extensions, which is what heavy-lifting libraries like numpy do.
I think they were refering to a lack of interpreter competition. Sure there is pypy, jython, ironpython etc. But they arent competing. They are just used for different usecases.
In the browser space their has been a lot of competition to make the fastest js runtime because it makes the browser faster.
CPython has a C API. Any Python object may at any time be passed into a C extension that expects to see all its introspectible attributes, nicely type-erased. This inhibits inlining, elision and monomorphization, all essential optimization techniques available to the JavaScript JIT.
> Just wondering, why is CPython a lot slower than JS?
Because no FAANG has ever seen CPython performance as a central element of an effort central to the future of the firm, and thrown money at it accordingly.
I updated a large Django project from python2.7 to 3.9 recently. Afterward, I was pleased that the app was both faster and used less than half the memory. It was somewhat surprising that the new version was so much better - most software seems to typically get only heavier over time!
So, I take this as a good sign that progress will continue.
> most software seems to typically get only heavier over time!
It's often the case for end-user applications, but I find that most languages/runtimes tend to get better with time (and work of course !). There's a similar trend with the PHP runtime.
I can't think of a language/runtime that has actually gotten slower with time. The nearest I can really point to is the uptick in compile time that happens with languages like Rust/C++ every so often. That's not really a "language is slower" problem though.
rustc's trend the last twenty releases has been that the compiler is getting faster. I guess every dependency is slowly growing in size, offsetting this in your perception? The compiler benchmarks are of course held constant to be able to compare releases.
Development is taking place in the main cpython repo and bugtracker, mark shannon already has a few merged PRs during the last month and a few more in flight. I.e the project has already started. See for example https://github.com/python/cpython/pull/25152
BlockFi offers crypto interest-earning accounts with up to 8.6% APY. This allows clients holding crypto like Bitcoin & Ether to earn compounding interest. BlockFi also offers low-cost USD loans backed by crypto. Access crypto capital without selling.https://yazing.com/deals/blockfi/safi68
Guido's slides in the repo mention speedup targets, but there is no mention of benchmarks. What is measured gets optimized, but which benchmarks are important for Python users? I'm sure Django users and Numpy users have very different performance bottlenecks.
Stage 2 should've been the selling point of Python 3.
If there's really a 50% general speed boost sitting around in "normal" bytecode optimization work (and having read a decent amount of CPython I believe there could be), that's a criminal amount of energy over the past decade instead wasted dealing with what the type of a codepoint sequence should be named.
This project is dead already. Lua is 4x faster out of the box compared to Python (without LuaJIT!). Lua got fast by having ints and floats at the local side of values, not as a reference. That's in, the int and float value is in the variable itself, not as a reference with a pointer indirection. In Python, every time you do a=a+1 new memory allocation is made for the a+1 object. Java has the same performance issue with boxed types (new Integer), and this is why C# is faster in many benchmarks. (C# cheated with the hindsight advantage of knowing which were Java mistakes)
93 comments
[ 4.5 ms ] story [ 145 ms ] thread- without breaking anyone's code (did that for the print function etc and delayed py3 adoption for a decade but not for the most user requested feature which is speed)
- No large PRs (how a 5x speedup can take place with small patches that no one figured out yet?)
- a small team (not enough money, less risky if they tried to adopt other pypy-esque projects that are more advanced speed wise, a more comprehensive plan that would invite donations, I would certainly give. For this presentation I don't know)
To back up that fact: Python 3.10 will remove long-deprecated features, see issue tracker: https://bugs.python.org/issue41165 and What's new, the Removed section: https://docs.python.org/3.10/whatsnew/3.10.html#removed
The Python 3 debacle is a beautifully worked example of why being backwards compatible is so important, and I can 100% sympathize with them not wanting to go through that again.
Among interpreted languages python is/was one of the faster ones.
NodeJS has similar speed, and in some cases is faster. I don't know any other interpreted language though.
People are also complaining about GIL, but ironically NodeJS is single threaded.
The only production language with performance in the ballpark of Python is Ruby.
I agree that more often than not it simply isn't an issue, but CPython performance isn't much far ahead of toy languages, for a whole lot of reasons that we are all sick and tired of hearing.
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 ...
Microsoft is reactivating their JIT project for Python as well.
Their talk tomorrow:
"Talk: Restarting Pyjion, a general purpose JIT for Python – is it worth it?"
https://us.pycon.org/2021/schedule/presentation/52/
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.
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.
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.
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.
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.
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...
This is ahistorical nonsense in multiple ways.
So hopefully the combination of those two can make it work.
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.
In a way, it seems like Mark Shannon found someone to take him up on his offer on a plan for speeding up Python.
It is always announcements, talks, conferences and if something emerges it is a bit weird like the pattern matching.
Meanwhile the Erlang people quietly produced a JIT without any advertisements.
When you like a tech, knowing people are brewing improved perfs on it is kinky. On Python, the motto has always been "it's fast enough", "if you want perfs, don't use python", "C extensions will solve this", "we don't want to make the main implementation complicated", "python dynamism and GIL make it a hard problem", etc.
So in the python world, it's particularly big news, especially given that previous attempts (gilectomy, unladen swallow, first pyston...) all died.
This is precisely the point you seem to be missing. All those things you mentioned were similar big announcements back in their day, and they all have just died by fizzling. What should be setting this one apart?
If that is cause for excitement can be seen when a product is finished.
I think they could get away with it for a while because none of the competing implementation would readily steal Python’s darlings, namely NumPy/SciPy and Tensorflow. Now there is competition, and it can really push CPython away to being a niche “reference implementation”, thus we are seeing these twitches.
The track record of CPython core team in the last decade makes me very wary when it comes to bringing in such features. Ship it or it didn’t happen.
P. S. Microsoft once threw a large sum of money at Kenneth Reitz to work on Requests, anyone remembers how that story ended?
However, the first release will probably suck like asyncio or type hints did.
It will take time to become usable, but it's unlikely it won't happen.
Mypy was Jukka Lehtosalo's work, asyncio was fixed and extended by many.
So now he needs a project at Microsoft, he changed his mind (or had it changed under pressure) and this is the project. We'll see, I agree though that the first version will be underwhelming, the following versions will have a max speedup of 50% but will be celebrated at conferences and here.
Namely, that it’s absolutely not guaranteed to work.
Also, most of them released working code.
So I guess we shouldn’t be excited about that, either.
Because almost everything you've seen as 'working code' started its life as an announcement.
And because to coordinate and discuss future work, there would need to be some announcements.
And because some announcements (based on the persons, e.g. here GvR is involved) or the funding (e.g. here MS is involved) or the specificity (e.g. here 3.10 timeframe is discussed) are more important than others.
>Meanwhile the Erlang people quietly produced a JIT without any advertisements.
Good for them. That's maybe because much fewer care for Erlang (and thus for the advertisements) related to Python (which has a much larger dev base), so the advertisements of the former are posted fewer times and discussed by fewer people.
Not only is it a large user base, but a varied one too. Flask, Django, FastAPI, Twisted...and that is just to name the web frameworks! We have scientific use, research use, cli tools. Perhaps in some cases end users (developers or not) of those tools may not be aware Python is the foundation of said tool.
Anecdotally the Erlang users I've met have been incredibly knowledgeable and in tune with the language features and development. I find that pretty cool.
In my opinion, an argument can be made that Elixir is the most prominent web framework for the language, so developers can just keep up with that and not the language if they wish. Compared to the Python ecosystem. As Erlang inevitably grows in popularity, it too may fragment.
Er, no, they didn’t, they made plenty of announcements before the release, most of which even made their way to HN.
https://en.wikipedia.org/wiki/Mark_Shannon_(actor)
That mark shannon:
https://github.com/markshannon
He tried to do hotpy in 2011, and trigger the idea of FAT byte code which I believed inspired the FAT python attempt of Victor Stinner.
Now stinner is working on Hpy, dropbox on pyston, instagram on cinder, and pyjion just got a release.
Looks like Python is going to get faster one way or another.
[1] https://cffi.readthedocs.io/en/latest/index.html [2] https://doc.pypy.org/en/latest/extending.html#cffi [3] https://numba.readthedocs.io/en/stable/reference/pysupported...
https://github.com/adsharma/py2many/issues/62
This was originally a feature of ctypes but was dropped before stdlib inclusion because it's difficult to solve in the general, "public distribution" case. Nonetheless I don't think there's any need to replace ctypes to reintroduce it, it was done as a library / external tool before and still could be.
https://svn.python.org/projects/ctypes/trunk/ctypeslib/ctype...
Thanks, Guido and team!
https://docs.bazel.build/versions/master/skylark/language.ht...
Edit: Why is this being downvoted? Is my statement incorrect or offensive to some people?
Performance has always been a lower-tier priority for cPython and other, faster, implementations (like PyPy) have not seen much mainstream adoption.
Node.js uses the V8 engine for JavaScript which isn't just an interpreter - it includes a JIT compiler.
I think when GVR mentions "There's machine code generation in our future" that he is talking about a JIT
IIRC Firefox 3 was the first browser to have what we would call a modern JS engine, with heavy emphasis on JIT compiling. Google Chrome soon followed and V8 dominated the JS perf story.
Python doesn't have such fierce competition of implementations. And besides, it has the "escape hatch" of being able to implement performance-critical code paths as C extensions, which is what heavy-lifting libraries like numpy do.
Python have many competitions, but the language lack some sort of spec and the only reference is CPython.
In the browser space their has been a lot of competition to make the fastest js runtime because it makes the browser faster.
Because no FAANG has ever seen CPython performance as a central element of an effort central to the future of the firm, and thrown money at it accordingly.
So, I take this as a good sign that progress will continue.
It's often the case for end-user applications, but I find that most languages/runtimes tend to get better with time (and work of course !). There's a similar trend with the PHP runtime.
See the perf website https://perf.rust-lang.org/dashboard.html
3 packages will be installed:
Size required on disk: 18MB3 packages will be installed:
Size required on disk: 22MBhttps://github.com/faster-cpython/cpython
Looks like they've also got a repo with some tools for profiling bytecode:
https://github.com/faster-cpython/tools
PyPy is already a drop-in replacement for CPython with JIT and using a fraction of the memory.
https://dev.nextthought.com/blog/2018/08/cpython-vs-pypy-mem...
If there's really a 50% general speed boost sitting around in "normal" bytecode optimization work (and having read a decent amount of CPython I believe there could be), that's a criminal amount of energy over the past decade instead wasted dealing with what the type of a codepoint sequence should be named.
(relevant graphic: https://ibb.co/yV6bN9H )