> Pyston is a fork of CPython with additional optimizations for performance. It is targeted at large real-world applications such as web serving, delivering up to a 30% speedup with no development work required.
I did not really found any information on what type of additional optimizations are done. Is there some documentation which goes into that?
Pyston originally started as an internal project at Dropbox and they had a couple of super interesting blogposts where they detailed their approach and findings[0]. After a a year or two, the project got axed, but the devs kept working on it and then released it on their own (I don't remember the details, but evidently the chosen license for the project allowed that).
Last year (I think it was last year, but can't tell if that was 2020 or 2019) they released it on their own, thinking of a commercial model. Now they have switched to OSS+services, which is interesting because it'llopen up more people using Pyston.
I tihnk this is interesting in its own right, but yesterday we got Facebook announcing Cinder[1] -- which is unsupported to outsiders, but significantly faster than Pyston. According to Facebook, they intend for parts of Cinder to be upstreamed (and have already upstreamed a few, apparently) to CPython. So again, and sorry for using such a vague word, it'll be interesting to see how all these things play out in time.
As someone with a fairly minimal understanding of the different open source licenses, I was a little confused on how you could fork Python to a commercial project, but it turns out it's permitted under the license [0]:
> Note GPL-compatible doesn’t mean that we’re distributing Python under the GPL. All Python licenses, unlike the GPL, let you distribute a modified version without making your changes open source. The GPL-compatible licenses make it possible to combine Python with other software that is released under the GPL; the others don’t.
Good question, we talked about it a tiny bit in our previous blog post and are planning on doing more in-depth blog posts in the future. I added a very brief summary to the github readme:
I'm still learning about Cinder, but my initial impression is that there are many similar techniques used, and maybe one interesting difference is that with Pyston we've focused more on out-of-the-box performance while Cinder has had an opportunity to co-optimize the runtime with a particular codebase and presumably gets better results if you're able to do that.
My understanding is that can is only half the question. Yes, the changes CAN be upstreamed but my understanding (through others, so take it with a grain of salt), is that the CPython doesn’t like to take optimization changes that obscure the CPython code base. As a result, they often deny merging optimizations in favor of readability in the C codebase. Again, just my understanding and may not be 100% accurate.
Are they not compatible solutions? I understand if the development is very fast you want to have focus, but the goal here is performance, it seems worth to at least coordinate. I hope it happens!!
How fast is that thing at HTTP serving? For example Python v3.x ThreadedHTTPServer can do 1,000 requests per second for hello world so 30% faster isn't much faster. On the other hand, redbean can do 1,000,000 requests per second on the same machine using a dynamic Lua handler. https://justine.lol/redbean/index.html redbean was also the top #3 show hn thread of all time. https://news.ycombinator.com/item?id=26271117 Lua isn't that much different from old Python. I'm also considering integrating js and scheme into redbean too, so people can have options in terms of personal aesthetics and programming taste when they achieve that million qps. For example, Fabrice Bellard's JS engine has already been checked-in to Cosmopolitan and it actually benchmarks faster at ECMAScript test262 than even v8 if I remember correctly.
Context matters. If you have an existing python app which is CPU bound, 30% faster means ~third of your web infra cost can go away. That may be very significant.
Also unless you have a very trivial app / use only your own code, Lua web environment isn't really comparable to what exists in the python ecosystem. Not yet anyway.
We're talking about Python 2.2 here which is literally twenty years old. You can't leverage what exists in the Python ecosystem using a version that old. Many libraries don't even permit using 2.7 anymore. I remember Python 2.2. It had so many things missing compared to what we grew accustomed to with Python 2.7's long lifetime. Going that far back with Python is a hair's width away from starting from first principles.
Oh wow I stand corrected. I saw Py..on 2.2 in and my head for some reason I thought it was a mad science experiment to gain a performance edge by resurrecting an old version without the bloat, because Python 2.2 is something I remember very well. If Pyston is really fully committed to going their own way with a fork, I'd recommend they just go for the gold and bump up the version to 4.x, since that sends a pretty clear message to the Python project about how valuable they feel the enhancements they've made are, while avoiding confusion. Python performance is truly something we all want to see improve so maybe things will change.
As a huge Python fan, I think now is the time for the leadership to start thinking about Python 4 (especially since the 2->3 migration headache seems to have mostly gone away).
I say this because v4 would be a good time to look at putting some of these speed improvements into the mainline code - something that would be largely backward compatible, but make those breaking changes that give big speedups (such as putting limits on the C interfaces and other big building blocks).
My gut (and really, it's just a half-assed guess) tells me that Python could easily see a 2x speedup in exchange for some of those incompatibilities, and an even bigger gain depending on how deep the changes went. [0]
If that's anywhere near correct, then doing a v3/v4 in parallel (like v2/v3 was) would probably be the only way to go, so that people would know there is a migration path. [1] [2]
[0] - There are really only two ways to do this - keep breaking things and introducing incompatibilities along the way, or make a bigger break for the sake of performance. Of course, doing nothing is also an answer, but probably one that we wouldn't really be happy with. There is also a variant of versioning where we do 4/5/6/... in relatively rapid succession, such as 2-3 year intervals, and make a fewer big breaks for each release, and that might even work better.
[1] - I suffered through the v2/v3 issues also, (as an end user more than a dev though), and it wasn't fun. But I'd do it all again if it meant a big jump in speed.
[2] - I know the perl team mucked this up (hindsight being 20/20), so having a working V4 on first release (not counting alphas & betas) would be key. Scoping that out well beforehand would probably be needed, but I think the team is broad and deep enough to do that.
Given how troublesome the 2->3 migration has been for large companies I wonder if a breaking 3->4 wouldn’t kill the language. I know of more than one big shop that still has a lot of Python 2 in house but has disallowed the creation of new Python code bases in favor of other languages.
Well, it's solvable in the sense that breaking language compatibility is a choice that doesn't have to be made, I guess. The 2->3 transition was managed as effectively as such a big thing could be but it's for left the industry littered with a bunch of weird self-maintained python2 forks, compatibility layers for the C side of python. A 2x theoretical performance improvement doesn't pay down the engineering costs to make a switch if you recoup it in lower hardware costs later.
50k person years of work represented in the code bases and up, as an approximation. Big enough that to do the work you'll have to coordinate across multiple departments with different incentives for multiple years to get the transition made.
I'd say 2x probably isn't worth causing major ecosystem pain. Maybe if it opened up potential for 10-100x speedup for some fairly common workloads or improved developer velocity.
I wonder whether it would be better to just go with the nuclear option and kill the C extension model as it currently stands.
It would take probably decades for libraries to catch up, and maybe kill the language, but if it survived, Python would be so much more attractive for many kinds of projects.
Conversely, Python has a lot of niches, and works well for them. Incremental improvements are probably fine, even with the dreaded GIL.
What would be gained by killing the C extension model? Making it easier for PyPy/GraalPython or the more recent Pyston and Cinder to outperform CPython?
HPy is in the process of creating a new C extension API that doesn't expose CPython internals and is easier for alternative Python implementations to support with high performance.
There was a different similar post a few days ago
from Facebook and this one stems from Dropbox and
they both are said to make Python code run faster.
I think the obsession with monocultures is unhealthy.
Python is a great language.
It is reasonably easy to learn, somewhat readable if you dont yet.
It is one of the most popular programming languages on the planet.
But it was not created to produce the fastest code possible.
There are other programming languages that are focused on speed.
Perhaps for the most critical parts use one of them.
Python can integrate pretty well with C with some magic i hear-
(Never tried it myself).
One programming language will never cover all use cases and they
should not have to.
Every programing langue is not made to be "functional" but they can
be tortured into it.
Every programming language is not object oriented, but they can be tortured
into it.
Every programming langue is not focused on being the fastest on execution
but they can be tortured into it.
There is a reason carpenters have more than one tool to build something.
For the longest time I programmed in C with some C++ mixed into it.
It is a great language. There are many problem domains I would not
recommend using C.
I think it was delightful ot pickup Python many years ago.
It is great. I can be very productive in Python in contexts were
Python is great.
It is not C, it should not want to be.
Now I am picking up Elixir, I am learning a lot.
It is neither Python or C and I am happy with that.
Suppose you are staring a startup. You know and like python so you build your MVP in python. 1k to 10k lines later you hire a few extra engineers to help bring your MVP to a real product. 100k to 1mill lines later you become very very successful and you now have 10s to 100s of engineers coding every day. They're all producing the same number of LOC you were. Maybe more now. Then you take a look at your bills and find that what used to run on a single box on your basement is now costing > 100k/month in compute.
So what do you do? Rewrite everything in C++? Well you can start but you have so much software it's hard to do. Maybe you can save a few percent of compute cycles across all of your code? Reduce the 100k/month to 80k/month.
Obviously this number is fall smaller than it would be in reality.
You do what you generally do with performance challenges: you profile and improve the hot-spots. Rewrite those parts if necessary.
Rewriting everything for performance reasons is silly. If you decide to rewrite everything, it would be for other reasons (e.g. maintainability, long-term viability, etc.)
How is that an advantage? A C compiler is needed in either case, either for using together with Nuitka or for compiling Pyston in the first place, right?
It should in theory. Cython generates modules using cpython API. As long as Pyston is compatible with existing C extensions (and it should be), there's not much difference between them and cythonized py source.
Because much of the power of python comes from its libraries, many of which depend on C(++) extensions tied to details of CPython interpreter. It's very hard to write a JIT without breaking this.
For example, all the numerical/scientific stack (numpy etc) is extremely fast by being written C, Fortran, etc with a Python interface. If you break this in a JIT then the plain python might be faster but actual useful code will be much slower.
Additionally, one of the reasons C-extensions are so fast is because the CPython implementation is very clean which has made it easier to write stable and performant extensions.
> I'm curious to understand, why is it so hard to write a JIT runtime for python?
First, the CPython reference implementation is supposed to be kept simple. Second, it exposes interpreter implementation details to extension writers, meaning alternative implementations with a radically different architecture might be unable to use some parts of the ecosystem or have to implement costly workarounds (see eg the PyPy FAQ [1]).
Interestingly Ruby decided to write a JIT despite exposing about as much of the interpreter to extension writers. So far their JIT is not very usegul for most real life workloads but I think that is mostly due to lack of development resources rather than any actual limitations.
A comment on another HN thread mentioned that the reason for CPython still being non-JIT was the developers wanted the interpreter codebase to remain simple and easy to understand.
This sounds like the only reasonable explanation to me. JIT with C interoperability is hard, but it's not that hard.
Cpython and pypy are pretty mature and battle tested. You can find a lot of information on them.
Cinder and Python are pretty new, it would be premature to say too much, we don't have enough background information about them.
GraalVM is between the 2: it's been there for some time, but it's still not much known. I don't know anyone using it in prod. I would be curious about a writing on this one.
Given it was created by / for Instagram, I’d say it’s likely that Cinder is (machine count wise) seeing far more production use than even Pypy, but perhaps you mean production ready for users other than its creator?
(E.g. hhvm at Facebook vs everyone else who tried to use it after it was first publicly released)
Pyston has been around for way longer, and even its post-Dropbox relaunch (v2) predates Cinder’s open sourcing by a lot, and has seen steady development. The only thing you can argue is they cut the v2.2 release in response to Cinder, which doesn’t really mean much.
Pyston is a fork of CPython and aims to maintain drop-in compatibility. PyPy is a completely separate implementation which is not fully compatible with CPython.
It's super-promising and actually looks pretty ergonomic in comparison, but it'll take rewrites of existing C API leveraging packages.
There's not really a way around that, since they have to interact with refcounting now vs a more abstract mechanism (eg. hpy's handles) that shield from the underlying GC mechanism.
My fear here is that this will be a cool project a few projects really looking for cross-interpreter python support leverage, but will otherwise be a non-issue.
It doesn't need to show performance improvement on PyPy or Pyston as much as <=0 performance degradation of CPython, which will stay everyone's primary target.
I guess when it shows to be mature, it'll just be a question for each library of whether the work is worth supporting alternative interpreters for their user-base or personal lives or job.
Pyston claims 30% performance improvement over cpython while maintaining compatibility, pypy claims it's 4.2x faster but has some compatibility issues irrc.
Pypy's claim comes from a set of common Python benchmarks. Pyston claim comes from company's webserver benchmarks. These may be comparable, but may be also apples-to-oranges.
It's pretty good in terms of compatibility these days. Conda-forge has builds of most packages available for both cPython and PyPy on macOS/Linux/aarch64/ppc64le: https://conda-forge.org/status/#pypy
We use completely separate benchmarks, where our Pyston benchmarks are quite a bit "harder" and PyPy is only 12% faster on them while using 4x the memory.
You can easily do that by simply running N instances and distributing requests among them. No need for all the complication that would come with removing the GIL.
> Working Pyston into your projects should be as easy as replacing “python” with “pyston.” If that’s not the case, we’d love to hear about it on our GitHub issues
> Pyston is a fork of CPython with additional optimizations for performance. It is targeted at large real-world applications such as web serving, delivering up to a 30% speedup with no development work required.
I did not really found any information on what type of additional optimizations are done. Is there some documentation which goes into that?