16 ms·

Pyston v2: Faster Python

262 points by kmod 6y ago

acrefoot 6y ago
It's exciting to see this reborn outside of Dropbox!
pwinnski 6y ago
I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.
- RandallBrown 6y ago
  Sure, but there's lots of people already using Python that would probably love some more speed.
- tgv 6y ago
  I feel you, but then again, Python applications tend to deployed anyway, so a speed boost can be welcome for some. Memory usage looks better, too.
- qorrect 6y ago
  I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!
  - wil421 6y ago
    The 20% speed up looked like it was for flask and Django. In their benchmarks PyTorch did not have a speed increase.
    - austinpena 6y ago
      Likely because pytorch uses C++ under the hood.
  - throwaway5752 6y ago
    Aren't all of those mostly implemented in C or C++ extensions? Not to minimize speeding up the glue code, but I don't know if they will see that large of an improvement.
  - ehsankia 6y ago
    Well that still goes in the "ease-of-use" bucket in my opinion. That being said, those libraries are already highly optimized and all the heavy stuff running on C anyways, so making the Python itself faster won't make that much of a difference in those workflows.
  - anakaine 6y ago
    I'm in 5he same bucket here. My other ecosystem products are built on top of python, so we make use of pandas, numpy, dask, and our vendors own modules (which have taken them 10+ years to put together with a reasonably full team).
  - hhas01 6y ago
    20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (<koff>Smalltalk, Lisp</koff>) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of Greenspun’s Tenth Rule, and a fundamental failure of courage. Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom. There is a much larger learning opportunity here, to get a whole lot better at migrating extant code bases from an old, popular, dead-ended language to a new, upcoming one. But it’s like finding your way to Carnegie Hall: it takes practise, practise, practise.
    - newen 6y ago
      I agree. Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages.
      - hhas01 6y ago
        Ah, sunk costs. Where the future goes to die. And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
      - coldtea 6y ago
        >Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages. Well, I, for one, use Python because "the actual language is appealing compared to modern languages".
      - dragonwriter 6y ago
- irrational 6y ago
  Maybe. One of my projects at work is supporting a legacy ColdFusion website that is nearly 20 years old (well, it was started 20 years ago, but has seen updates since). We'd love to move it to something faster, but it is huge and it would literally take years to rewrite it. Other things take priority so it will probably never be rewritten. I imagine there are Python projects in a similar boat.
  - pastage 6y ago
    Rewriting parts of it will not take years. Most of it can probably be thrown away, replaced by standard components. (only talking from personal experience, sure we had legacy systems running for years).
    - irrational 6y ago
      Unfortunately that wouldn't work with this site. Between the five of us in my group we have nearly 100 years of developer experience. We've talked a lot about if there is anyway we could divest of it a little at a time or replace parts of it, but we really can't.
- chrisseaton 6y ago
  > I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.
  - Shared404 6y ago
    > I don't get why people object to performance work on languages not intended for performance. Presumably because they see it as effort that could be better applied elsewhere. I don't know that I agree, but I can understand the viewpoint.
  - Narann 6y ago
    > I don't get why people object to performance work on languages not intended for performance. You're right, this objection is not relevant in general. But in the situation we talk about, having 20 % more performance requires you to choose a fork that can came with it's own limitation. It's definitely not free. This trade of makes the point about the language choice relevant.
  - mhh__ 6y ago
    > I don't get why people object to performance work on languages not intended for performance My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it. I like Python's syntax quite a bit but I feel bad watching people learn to program using it - partly because it's an oddly low-level language (It's closer to being C than Haskell) and there's no compiler to stop you shooting yourself in the foot (If I write something fundamentally unsound I want to know about it now not when the process has been running all day)
    - saluk 6y ago
      As someone who learned on python (many years ago), I think the balance of being allowed to shoot myself in the foot, while only having to learn complexity when complex concepts came up, was a good combination rather than a bad one. Trying to learn C++ and Java before, having to type everything was an impedement. On python, you find out that types still matter when you try to add a string to an integer, for example. The moment the type matters to you is when you need to dig into those details. I'm not sure I would have the career I do if it hadn't been around to be the one language that fit my 16-year old brain.
- coldtea 6y ago
  >I feel like anybody really searching for speed is using something other than Python. Well, anybody using Python for all its over benefits, still would very much like more speed.
- sally1620 6y ago
  It is not about searching for speed. It is about lowering the cost of large Python code base running in production.
- nerdtime 6y ago
  Why not make the languages that are easy to use speedy? That way I don't have to search for one or the other.
nickjj 6y ago
If anyone is curious, it is available on the Docker Hub but it seems it's a version from 4 years ago based on https://hub.docker.com/r/pyston/pyston/tags https://hub.docker.com/r/pyston/pyston/tags.
- kmod 6y ago
  Whoops, I forgot we had that up, I took it down until we can post an up-to-date image
Animats 6y ago
How about PyPy?
- deleted 6y ago
  [deleted]
- ralph87 6y ago
  PyPy is the awesomest thing created since sliced bread, but C extension interoperability is still a source of perf problems in a few scenarios AIUI. Glad to have Pyston in addition to PyPy
- mivade 6y ago
  They compare PyPy and CPython in their benchmarks.
EdSchouten 6y ago
Not that it's necessarily a bad thing, but it looks like the Pyston project isn't getting a lot of updates: https://github.com/pyston/pyston/commits/v2.0 https://github.com/pyston/pyston/commits/v2.0
- soperj 6y ago
  Project says: A faster and highly-compatible implementation of the Python programming language. The code here is out of date, please follow our blog
  - kapilvt 6y ago
    where is the code? the repo looks relatively untouched, the blog directs to this repo for filing issues. https://github.com/pyston/pyston https://github.com/pyston/pyston
    - soperj 6y ago
      I think it's private. Looks like a for profit fork.
    - mkl 6y ago
      Pyston v2 is closed source (for now?). From the blog post: > Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model.
- kmod 6y ago
  I updated the repo in the middle of this comment thread; it used to show the v1 code, but since that was confusing people now it's just a stub that redirects you to the blog.
jedberg 6y ago
I'm not versed in the details of the politics of CPython, but why did this project fork instead of just contributing to CPython? Is CPython really slow in integrating community contributions? Edit: I read the blog post closer, and found this: "Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model."
- simonh 6y ago
  They intend to monetise it.
  - deleted 6y ago
    [deleted]
- dwheeler 6y ago
  As far as I know CPython is quite welcoming. However, per the blog post, this version of Pyston is closed source. So CPython won't be interested, and many others won't be interested either.
  - rrdharan 6y ago
    Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769 https://news.ycombinator.com/item?id=11125769
    - toolslive 6y ago
      it's _still_ essentially the same switch(opcode) based interpreter it was 20 years ago. no threading, no super instructions, no jitting, nothing. https://github.com/python/cpython/blob/master/Python/ceval.c#L1568 https://github.com/python/cpython/blob/master/Python/ceval.c...
beervirus 6y ago
20% isn't nothing... but is it really worth switching to a non-standard, closed-source version of the interpreter?
- jedberg 6y ago
  Well it's a drop in replacement, so you can always just go back to CPython.
- sjansen 6y ago
  Depends on your scale. If each of your web servers has a hand picked name, definitely not. But if you stopped naming servers a long time ago, and if the pricing structure is favorable, it could mean a huge cost saving without an expensive rewrite.
  - Foober223 6y ago
    Electricity costs can far outweigh developer salaries. In some cases a rewrite may save more money than moving to a 20% faster python.
  - gnulinux 6y ago
    What does it have to do with naming servers, can you explain? Or do you mean if you have very few servers such that you can name each and every one of them, this wouldn't be worth it?
    - sjansen 6y ago
      Pretty much. If you’re spending $1000/month on servers, you’d only save < $200/month and the added complexity probably isn’t worth it. If you’re spending $100000/month on servers, saving ~$20000/month is probably worth it. Where is the tipping point between those two numbers? Depends on context. Rewriting in a more efficient language might seem even cheaper, but you have to factor in risk and opportunity cost. At some point it does become smarter to rewrite, but your app needs to be pretty simple or your server bill pretty huge before it’s actually the best option.
simonw 6y ago
"After the project ended, some of us from the team brainstormed how we would do it differently if we were to do it again. In early 2020, enough pieces were in place for us to start a company and work on Pyston full-time." I didn't know the Pyston team had split off to form their own company! Anyone know who's involved, or if they've raised money for it?
- simonw 6y ago
  Looks like https://www.linkedin.com/in/kevinmodzelewski/ https://www.linkedin.com/in/kevinmodzelewski/ is the founder, as-of May this year.
SoSoRoCoCo 6y ago
Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main projects and evolve into their own incompatible beasts. I hope they instead contribute to the main branch, instead of wandering off into NIH land.
- JoeAltmaier 6y ago
  An issue. But isn't that forking fundamental to the principle of Open Source? The market will choose what it wants, like some Genetic Algorithm where the fittest thrives and the rest go extinct. Else how does a project evolve at all?
- WesolyKubeczek 6y ago
  Disagree. Currently, many people have "Python" projects which only CPython can run, for some reason or other. Having a lot of competing interpreters/compilers helps define what the core of the language actually is, and which of your assumptions are hinged on that single implementation.
- rudi-c 6y ago
  That's not how progress happens in practice. First of all, it's not a known fact that a Python JIT implementation with reasonable maintenance cost, functionality, and performance can exist. Pyston is trying to prove that it is possible, but it's not exactly a weekend project. Even if you solved all the political issues around getting CPython maintainers to accept performance contributions (discussed already in this thread), adding a JIT to the main CPython codebase would surely slow the pace of development of other Python features. If the effort were to fail, then CPython's primary maintainers will have wasted a whole bunch of time coordinating with the JIT effort. I'm personally rooting for Pyston to succeed but it's admittedly an ambitious project. So forking off an experiment is the right move here. Pyston's existence as a side-project is pulling no resources away from the main project -- but it would if it was trying to send changes upstream. Hypothetically the Pyston developers could be making non-JIT contributions to CPython instead, but developers aren't interchangeable commodities. Pyston's engineers have expertise in optimizations -- they may not be as skilled or interested in language development.
The_rationalist 6y ago
Interesting to see that it significantly outperform pypy on some metrics, but wouldn't have it been better to allocate the human resources towards pypy instead of a duplicated effort?
- Rochus 6y ago
  Do you mean the Pylint result? Was this confirmed elsewhere? It's unlikely that an interpreter is faster than a tracing JIT in geomean over a relevant set of benchmarks.
- jnwatson 6y ago
  They are completely different, incompatible approaches. Pypy in particular has a C compatibility issue.
ghj 6y ago
I stalked the author's linkedin and notice he has competitive programming experience: https://www.topcoder.com/members/kmod/details/?track=DATA_SCIENCE&subTrack=SRM https://www.topcoder.com/members/kmod/details/?track=DATA_SC... (and top 15 putnam, ICPC world finals, etc) I wonder if he would be interested in optimizing for purely algorithmic tasks? There are a lot active and successful CPython and PyPy users on https://atcoder.jp/ https://atcoder.jp/. For example: https://atcoder.jp/contests/practice2/submissions?f.Task=&f.LanguageName=Python&f.Status=AC&f.User=maspy https://atcoder.jp/contests/practice2/submissions?f.Task=&f.... (the user "maspy" is rated at 2750 using only cpython!!!) https://atcoder.jp/contests/practice2/submissions?f.Task=&f.LanguageName=PyPy3&f.Status=AC&f.User= https://atcoder.jp/contests/practice2/submissions?f.Task=&f.... (though pypy is more practical) I am linking to atcoder because their testing data is public so you can rerun contestants solutions using both pyston/cpython/pypy for benchmarking purposes: https://www.dropbox.com/sh/arnpe0ef5wds8cv/AAAk_SECQ2Nc6SVGii3rHX6Fa?dl=0 https://www.dropbox.com/sh/arnpe0ef5wds8cv/AAAk_SECQ2Nc6SVGi... Right now, other than a handful of people who figured out how to make numba's jit work, only pypy is viable for competitive programming. I wonder if you can do better than pypy? There are also a few red coders on codeforces.com who mostly use pypy (cpython is completely unviable there because numpy and numba is not installed) https://codeforces.com/submissions/pajenegod https://codeforces.com/submissions/pajenegod https://codeforces.com/submissions/conqueror_of_tourist https://codeforces.com/submissions/conqueror_of_tourist But codeforces' test cases aren't public anyway so it's not as relevant.
- kmod 6y ago
  All my CodeJam solutions are in Python :) While we could certainly go in this direction, we're not planning to, because in our experience optimizations for different workloads are largely distinct, and this use case is already handled well by PyPy.
  - ghj 6y ago
    Isn't this use case the scientific computing use case? That's a fairly large part of the ecosystem to give up on! I think it's still a relatively low effort way (just need to write a scraper) to create a benchmark on a diverse set of algorithmic tasks that have clearcut criteria on AC/TLE/WA. PyPy is often 10x faster than cpython on these problems (and just 2x slower than equivalent C++ solution) so it will be a much nicer headline too if you can achieve similar performances! Though I can also see how it can be completely irrelevant for server workloads. Pypy's unicode is so slow, some people on codeforces still use pypy2 over pypy3 just to avoid it. And c extensions is so bad on pypy, you can often get better performance on cpython if you need to use numpy.
tedunangst 6y ago
Everybody should note that the existence of pyston does not prevent you from making cpython or pypy faster if that's what you want to happen.
shadykiller 6y ago
I read this as Python V2 and thinking why would they make V2 faster than V3 :D
nickjj 6y ago
It's really awesome that it's not just a speed boost but a drastic decrease in memory usage too. Going from a 230mb Flask app down to 55mb is huge if it's really a drop in replacement. If you factor in gunicorn process count, the wins are even higher because if you had 4 gunicorn processes each using 230mb but now they use 55mb, you're really going from 920mb down to 220mb of RAM. Edit: This isn't true in the end, a brain malfunction mis-read the table thinking PyPy was actually the regular Python interpreter. It would be interesting to see how it compares to the default Python implementation for memory usage tho.
- shoo 6y ago
  From the benchmark numbers reported in the post, pyston uses slightly more memory than cpython for the flaskblogging benchmark. switching to pyston only a win in terms of reducing memory consumption if you're using pypy, and it would be more of a win to switch to cpython
  - nickjj 6y ago
    Wow thanks for the clarification. I don't know why but I read PyPy 7.3.2 as Python 3.7 in the table. Talk about a brain auto-complete failure haha.
cbsmith 6y ago
Can we talk about the name?? Like, if you wanted to create a confusing name, I can't think of worse ideas than naming it "v2" for a runtime that is Python 3 compatible, particularly for a project that has traditionally been Python 2 compatible...
ihnorton 6y ago
> A very-low-overhead JIT using DynASM Interesting. DynASM [1] is the template assembler used in LuaJIT, so it sounds like they might be JIT'ing CPython bytecode. IIRC this is also what the first version of Pyston did. I'm curious how this is working out, both implementation and performance-wise compared to LLVM (used in Pyston v1). That could mean there is a lot of performance still on the table, at least for some kinds of code, but also a big complexity jump to get further gains. [1] https://luajit.org/dynasm.html https://luajit.org/dynasm.html
- kmod 6y ago
  We started with an LLVM-based JIT in Pyston v1. Our experience with the two jits is that it's very nice that DynASM is ~2 orders of magnitude faster, and also that we have not been able to extract enough high-level knowledge to make a powerful JIT like LLVM worth it. We do use LLVM elsewhere in our build process, and we hope to write some future blogposts about all of this.
fastball 6y ago
Now we just need a Python implementation re-written in Rust. (only kinda joking)
- Recursing 6y ago
  https://github.com/RustPython/RustPython https://github.com/RustPython/RustPython RustPython is still in active development, I don't know how compatible they are though
jasonhansel 6y ago
Just think: if CPython had been GPL-licensed, this would already be open source (and maybe even merged into upstream).
- pansa2 6y ago
  Or, it might never have been written at all.
oscargrouch 6y ago
Funny their choice over luajit's Dynasm, when you have something like Turbofan laying around. The V8 Javascript interpreter can generate machine code dinamically targetting the host arch for each bytecode instruction.. You can define the target assembly directly in C++ without resorting to any specific machine code. Maybe complexity or because they wanted to stick to C?
- kzrdude 6y ago
  Would it be easy to apply turbofan to Python? Do you have any details?
- rurban 6y ago
  They replaced dynasm in 2014 with llvm. Then there was no other good jit around. llvm is certainly not good either, but for specific workloads in companies it's doable, for benchmarks or short scripts not.
theamk 6y ago
Wanted to see redistribution rules, and was surprised to see there is no license anywhere for the binaries... The closest thing I found is "copyright" file inside .deb: Copyright: 2020 The Pyston Team <support@pyston.org> License: Closed source, all rights reserved. I guess it means no one should be touching the file, as they haven't even granted access to run it.
- bastawhiz 6y ago
  From the link: > Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model.
- globular-toast 6y ago
  > I guess it means no one should be touching the file, as they haven't even granted access to run it. Since when does someone need to explicitly grant you permission to run a program on your own computer?
  - theamk 6y ago
    Running is probably ok, but giving to others? I am not sure. Those limitations existed since before the computer time, when the copyright law was passed. For example, even you own a book, there are certain things you can not do, like duplicate it and sell copies. In case of software, here is how the law works [0] > When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. There are "fair use" terms, which allow some things without permissions -- but things like "copying the binary to company-internal repo so CI runners can pick it" really need explicit permissions if you want to be above the board. [0] https://choosealicense.com/no-permission/ https://choosealicense.com/no-permission/
    - globular-toast 6y ago
mshockwave 6y ago
My last impression on Pyston was that it got killed by Dropbox. Happy to see community efforts still continue on this project
xvilka 6y ago
There is another way. Since Pyston isn't generally compatible with the original Python, why not to use faster languages? Go for network services and console tools. Julia for AI applications, data and computational science.
ngcc_hk 6y ago
Always go back to python (and c) when in doubt. Problem is graphic user interface. TK, ... or even pythonista scene. So diverse and so non-standard.
CyberRabbi 6y ago
I thought this project was dead. Nice to see it’s alive.
yuskii 6y ago
Oh really?
sandGorgon 6y ago
Quick question - does pyston use the new PEG parser that cpython does? https://www.python.org/dev/peps/pep-0617/ https://www.python.org/dev/peps/pep-0617/ Because that's a long term risk on subtle differences that may crop up.
kzrdude 6y ago
There has been many faster python threads lately, I'm looking forward to improvements, especially, those that reach CPython! As others have been pouring out before, the new load attr opcache is maybe the most interesting recent performance improvement that was merged.
person_of_color 6y ago
What does everyone think of just switching to Julia?
jonstewart 6y ago
What is meant by “quickening”?
- rurban 6y ago
  The paper is gone. Maybe someone has a link. Looks like inline caching of some specific ops with certain types. Some arith and call ops are optimized this way. It also looks like dynasm was later replaced by the much slower llvm, so it needs heavy warmup.
  - kzrdude 6y ago
    I wonder if it's similar to Python 3.x's opcache for Load global and load attr? It would make a lot of sense to generalize those.
rurban 6y ago
The latest open source repo, I believe, is at https://github.com/jmgc/pyston https://github.com/jmgc/pyston (latest Sep 11) 9f672c1bbb75710ac17dd3d9107da05c8e9e8e8f Maybe someone has something newer. At Oct 28 kevmod deleted all the history.

262 points by kmod 6y ago

It's exciting to see this reborn outside of Dropbox!

I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.

RandallBrown 6y ago
Sure, but there's lots of people already using Python that would probably love some more speed.
tgv 6y ago
I feel you, but then again, Python applications tend to deployed anyway, so a speed boost can be welcome for some. Memory usage looks better, too.
qorrect 6y ago
I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!
- wil421 6y ago
  The 20% speed up looked like it was for flask and Django. In their benchmarks PyTorch did not have a speed increase.
  - austinpena 6y ago
    Likely because pytorch uses C++ under the hood.
- throwaway5752 6y ago
  Aren't all of those mostly implemented in C or C++ extensions? Not to minimize speeding up the glue code, but I don't know if they will see that large of an improvement.
- ehsankia 6y ago
  Well that still goes in the "ease-of-use" bucket in my opinion. That being said, those libraries are already highly optimized and all the heavy stuff running on C anyways, so making the Python itself faster won't make that much of a difference in those workflows.
- anakaine 6y ago
  I'm in 5he same bucket here. My other ecosystem products are built on top of python, so we make use of pandas, numpy, dask, and our vendors own modules (which have taken them 10+ years to put together with a reasonably full team).
- hhas01 6y ago
  20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (<koff>Smalltalk, Lisp</koff>) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of Greenspun’s Tenth Rule, and a fundamental failure of courage. Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom. There is a much larger learning opportunity here, to get a whole lot better at migrating extant code bases from an old, popular, dead-ended language to a new, upcoming one. But it’s like finding your way to Carnegie Hall: it takes practise, practise, practise.
  - newen 6y ago
    I agree. Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages.
    - hhas01 6y ago
      Ah, sunk costs. Where the future goes to die. And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
    - coldtea 6y ago
      >Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages. Well, I, for one, use Python because "the actual language is appealing compared to modern languages".
    - dragonwriter 6y ago
irrational 6y ago
Maybe. One of my projects at work is supporting a legacy ColdFusion website that is nearly 20 years old (well, it was started 20 years ago, but has seen updates since). We'd love to move it to something faster, but it is huge and it would literally take years to rewrite it. Other things take priority so it will probably never be rewritten. I imagine there are Python projects in a similar boat.
- pastage 6y ago
  Rewriting parts of it will not take years. Most of it can probably be thrown away, replaced by standard components. (only talking from personal experience, sure we had legacy systems running for years).
  - irrational 6y ago
    Unfortunately that wouldn't work with this site. Between the five of us in my group we have nearly 100 years of developer experience. We've talked a lot about if there is anyway we could divest of it a little at a time or replace parts of it, but we really can't.
chrisseaton 6y ago
> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.
- Shared404 6y ago
  > I don't get why people object to performance work on languages not intended for performance. Presumably because they see it as effort that could be better applied elsewhere. I don't know that I agree, but I can understand the viewpoint.
- Narann 6y ago
  > I don't get why people object to performance work on languages not intended for performance. You're right, this objection is not relevant in general. But in the situation we talk about, having 20 % more performance requires you to choose a fork that can came with it's own limitation. It's definitely not free. This trade of makes the point about the language choice relevant.
- mhh__ 6y ago
  > I don't get why people object to performance work on languages not intended for performance My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it. I like Python's syntax quite a bit but I feel bad watching people learn to program using it - partly because it's an oddly low-level language (It's closer to being C than Haskell) and there's no compiler to stop you shooting yourself in the foot (If I write something fundamentally unsound I want to know about it now not when the process has been running all day)
  - saluk 6y ago
    As someone who learned on python (many years ago), I think the balance of being allowed to shoot myself in the foot, while only having to learn complexity when complex concepts came up, was a good combination rather than a bad one. Trying to learn C++ and Java before, having to type everything was an impedement. On python, you find out that types still matter when you try to add a string to an integer, for example. The moment the type matters to you is when you need to dig into those details. I'm not sure I would have the career I do if it hadn't been around to be the one language that fit my 16-year old brain.
coldtea 6y ago
>I feel like anybody really searching for speed is using something other than Python. Well, anybody using Python for all its over benefits, still would very much like more speed.
sally1620 6y ago
It is not about searching for speed. It is about lowering the cost of large Python code base running in production.
nerdtime 6y ago
Why not make the languages that are easy to use speedy? That way I don't have to search for one or the other.

nickjj 6y ago

If anyone is curious, it is available on the Docker Hub but it seems it's a version from 4 years ago based on https://hub.docker.com/r/pyston/pyston/tags https://hub.docker.com/r/pyston/pyston/tags.

kmod 6y ago
Whoops, I forgot we had that up, I took it down until we can post an up-to-date image

Animats 6y ago

How about PyPy?

deleted 6y ago
[deleted]
ralph87 6y ago
PyPy is the awesomest thing created since sliced bread, but C extension interoperability is still a source of perf problems in a few scenarios AIUI. Glad to have Pyston in addition to PyPy
mivade 6y ago
They compare PyPy and CPython in their benchmarks.

EdSchouten 6y ago

Not that it's necessarily a bad thing, but it looks like the Pyston project isn't getting a lot of updates: https://github.com/pyston/pyston/commits/v2.0 https://github.com/pyston/pyston/commits/v2.0

soperj 6y ago
Project says: A faster and highly-compatible implementation of the Python programming language. The code here is out of date, please follow our blog
- kapilvt 6y ago
  where is the code? the repo looks relatively untouched, the blog directs to this repo for filing issues. https://github.com/pyston/pyston https://github.com/pyston/pyston
  - soperj 6y ago
    I think it's private. Looks like a for profit fork.
  - mkl 6y ago
    Pyston v2 is closed source (for now?). From the blog post: > Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model.
kmod 6y ago
I updated the repo in the middle of this comment thread; it used to show the v1 code, but since that was confusing people now it's just a stub that redirects you to the blog.

jedberg 6y ago

I'm not versed in the details of the politics of CPython, but why did this project fork instead of just contributing to CPython? Is CPython really slow in integrating community contributions? Edit: I read the blog post closer, and found this: "Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model."

simonh 6y ago
They intend to monetise it.
- deleted 6y ago
  [deleted]
dwheeler 6y ago
As far as I know CPython is quite welcoming. However, per the blog post, this version of Pyston is closed source. So CPython won't be interested, and many others won't be interested either.
- rrdharan 6y ago
  Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769 https://news.ycombinator.com/item?id=11125769
  - toolslive 6y ago
    it's _still_ essentially the same switch(opcode) based interpreter it was 20 years ago. no threading, no super instructions, no jitting, nothing. https://github.com/python/cpython/blob/master/Python/ceval.c#L1568 https://github.com/python/cpython/blob/master/Python/ceval.c...

beervirus 6y ago

20% isn't nothing... but is it really worth switching to a non-standard, closed-source version of the interpreter?

jedberg 6y ago
Well it's a drop in replacement, so you can always just go back to CPython.
sjansen 6y ago
Depends on your scale. If each of your web servers has a hand picked name, definitely not. But if you stopped naming servers a long time ago, and if the pricing structure is favorable, it could mean a huge cost saving without an expensive rewrite.
- Foober223 6y ago
  Electricity costs can far outweigh developer salaries. In some cases a rewrite may save more money than moving to a 20% faster python.
- gnulinux 6y ago
  What does it have to do with naming servers, can you explain? Or do you mean if you have very few servers such that you can name each and every one of them, this wouldn't be worth it?
  - sjansen 6y ago
    Pretty much. If you’re spending $1000/month on servers, you’d only save < $200/month and the added complexity probably isn’t worth it. If you’re spending $100000/month on servers, saving ~$20000/month is probably worth it. Where is the tipping point between those two numbers? Depends on context. Rewriting in a more efficient language might seem even cheaper, but you have to factor in risk and opportunity cost. At some point it does become smarter to rewrite, but your app needs to be pretty simple or your server bill pretty huge before it’s actually the best option.

simonw 6y ago

"After the project ended, some of us from the team brainstormed how we would do it differently if we were to do it again. In early 2020, enough pieces were in place for us to start a company and work on Pyston full-time." I didn't know the Pyston team had split off to form their own company! Anyone know who's involved, or if they've raised money for it?

simonw 6y ago
Looks like https://www.linkedin.com/in/kevinmodzelewski/ https://www.linkedin.com/in/kevinmodzelewski/ is the founder, as-of May this year.

SoSoRoCoCo 6y ago

Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main projects and evolve into their own incompatible beasts. I hope they instead contribute to the main branch, instead of wandering off into NIH land.

JoeAltmaier 6y ago
An issue. But isn't that forking fundamental to the principle of Open Source? The market will choose what it wants, like some Genetic Algorithm where the fittest thrives and the rest go extinct. Else how does a project evolve at all?
WesolyKubeczek 6y ago
Disagree. Currently, many people have "Python" projects which only CPython can run, for some reason or other. Having a lot of competing interpreters/compilers helps define what the core of the language actually is, and which of your assumptions are hinged on that single implementation.
rudi-c 6y ago
That's not how progress happens in practice. First of all, it's not a known fact that a Python JIT implementation with reasonable maintenance cost, functionality, and performance can exist. Pyston is trying to prove that it is possible, but it's not exactly a weekend project. Even if you solved all the political issues around getting CPython maintainers to accept performance contributions (discussed already in this thread), adding a JIT to the main CPython codebase would surely slow the pace of development of other Python features. If the effort were to fail, then CPython's primary maintainers will have wasted a whole bunch of time coordinating with the JIT effort. I'm personally rooting for Pyston to succeed but it's admittedly an ambitious project. So forking off an experiment is the right move here. Pyston's existence as a side-project is pulling no resources away from the main project -- but it would if it was trying to send changes upstream. Hypothetically the Pyston developers could be making non-JIT contributions to CPython instead, but developers aren't interchangeable commodities. Pyston's engineers have expertise in optimizations -- they may not be as skilled or interested in language development.

The_rationalist 6y ago

Interesting to see that it significantly outperform pypy on some metrics, but wouldn't have it been better to allocate the human resources towards pypy instead of a duplicated effort?

Rochus 6y ago
Do you mean the Pylint result? Was this confirmed elsewhere? It's unlikely that an interpreter is faster than a tracing JIT in geomean over a relevant set of benchmarks.
jnwatson 6y ago
They are completely different, incompatible approaches. Pypy in particular has a C compatibility issue.

ghj 6y ago

I stalked the author's linkedin and notice he has competitive programming experience: https://www.topcoder.com/members/kmod/details/?track=DATA_SCIENCE&subTrack=SRM https://www.topcoder.com/members/kmod/details/?track=DATA_SC... (and top 15 putnam, ICPC world finals, etc) I wonder if he would be interested in optimizing for purely algorithmic tasks? There are a lot active and successful CPython and PyPy users on https://atcoder.jp/ https://atcoder.jp/. For example: https://atcoder.jp/contests/practice2/submissions?f.Task=&f.LanguageName=Python&f.Status=AC&f.User=maspy https://atcoder.jp/contests/practice2/submissions?f.Task=&f.... (the user "maspy" is rated at 2750 using only cpython!!!) https://atcoder.jp/contests/practice2/submissions?f.Task=&f.LanguageName=PyPy3&f.Status=AC&f.User= https://atcoder.jp/contests/practice2/submissions?f.Task=&f.... (though pypy is more practical) I am linking to atcoder because their testing data is public so you can rerun contestants solutions using both pyston/cpython/pypy for benchmarking purposes: https://www.dropbox.com/sh/arnpe0ef5wds8cv/AAAk_SECQ2Nc6SVGii3rHX6Fa?dl=0 https://www.dropbox.com/sh/arnpe0ef5wds8cv/AAAk_SECQ2Nc6SVGi... Right now, other than a handful of people who figured out how to make numba's jit work, only pypy is viable for competitive programming. I wonder if you can do better than pypy? There are also a few red coders on codeforces.com who mostly use pypy (cpython is completely unviable there because numpy and numba is not installed) https://codeforces.com/submissions/pajenegod https://codeforces.com/submissions/pajenegod https://codeforces.com/submissions/conqueror_of_tourist https://codeforces.com/submissions/conqueror_of_tourist But codeforces' test cases aren't public anyway so it's not as relevant.

kmod 6y ago
All my CodeJam solutions are in Python :) While we could certainly go in this direction, we're not planning to, because in our experience optimizations for different workloads are largely distinct, and this use case is already handled well by PyPy.
- ghj 6y ago
  Isn't this use case the scientific computing use case? That's a fairly large part of the ecosystem to give up on! I think it's still a relatively low effort way (just need to write a scraper) to create a benchmark on a diverse set of algorithmic tasks that have clearcut criteria on AC/TLE/WA. PyPy is often 10x faster than cpython on these problems (and just 2x slower than equivalent C++ solution) so it will be a much nicer headline too if you can achieve similar performances! Though I can also see how it can be completely irrelevant for server workloads. Pypy's unicode is so slow, some people on codeforces still use pypy2 over pypy3 just to avoid it. And c extensions is so bad on pypy, you can often get better performance on cpython if you need to use numpy.

tedunangst 6y ago

Everybody should note that the existence of pyston does not prevent you from making cpython or pypy faster if that's what you want to happen.

shadykiller 6y ago

I read this as Python V2 and thinking why would they make V2 faster than V3 :D

nickjj 6y ago

It's really awesome that it's not just a speed boost but a drastic decrease in memory usage too. Going from a 230mb Flask app down to 55mb is huge if it's really a drop in replacement. If you factor in gunicorn process count, the wins are even higher because if you had 4 gunicorn processes each using 230mb but now they use 55mb, you're really going from 920mb down to 220mb of RAM. Edit: This isn't true in the end, a brain malfunction mis-read the table thinking PyPy was actually the regular Python interpreter. It would be interesting to see how it compares to the default Python implementation for memory usage tho.

shoo 6y ago
From the benchmark numbers reported in the post, pyston uses slightly more memory than cpython for the flaskblogging benchmark. switching to pyston only a win in terms of reducing memory consumption if you're using pypy, and it would be more of a win to switch to cpython
- nickjj 6y ago
  Wow thanks for the clarification. I don't know why but I read PyPy 7.3.2 as Python 3.7 in the table. Talk about a brain auto-complete failure haha.

cbsmith 6y ago

Can we talk about the name?? Like, if you wanted to create a confusing name, I can't think of worse ideas than naming it "v2" for a runtime that is Python 3 compatible, particularly for a project that has traditionally been Python 2 compatible...

ihnorton 6y ago

> A very-low-overhead JIT using DynASM Interesting. DynASM [1] is the template assembler used in LuaJIT, so it sounds like they might be JIT'ing CPython bytecode. IIRC this is also what the first version of Pyston did. I'm curious how this is working out, both implementation and performance-wise compared to LLVM (used in Pyston v1). That could mean there is a lot of performance still on the table, at least for some kinds of code, but also a big complexity jump to get further gains. [1] https://luajit.org/dynasm.html https://luajit.org/dynasm.html

kmod 6y ago
We started with an LLVM-based JIT in Pyston v1. Our experience with the two jits is that it's very nice that DynASM is ~2 orders of magnitude faster, and also that we have not been able to extract enough high-level knowledge to make a powerful JIT like LLVM worth it. We do use LLVM elsewhere in our build process, and we hope to write some future blogposts about all of this.

fastball 6y ago

Now we just need a Python implementation re-written in Rust. (only kinda joking)

Recursing 6y ago
https://github.com/RustPython/RustPython https://github.com/RustPython/RustPython RustPython is still in active development, I don't know how compatible they are though

jasonhansel 6y ago

Just think: if CPython had been GPL-licensed, this would already be open source (and maybe even merged into upstream).

pansa2 6y ago
Or, it might never have been written at all.

oscargrouch 6y ago

Funny their choice over luajit's Dynasm, when you have something like Turbofan laying around. The V8 Javascript interpreter can generate machine code dinamically targetting the host arch for each bytecode instruction.. You can define the target assembly directly in C++ without resorting to any specific machine code. Maybe complexity or because they wanted to stick to C?

kzrdude 6y ago
Would it be easy to apply turbofan to Python? Do you have any details?
rurban 6y ago
They replaced dynasm in 2014 with llvm. Then there was no other good jit around. llvm is certainly not good either, but for specific workloads in companies it's doable, for benchmarks or short scripts not.

theamk 6y ago

Wanted to see redistribution rules, and was surprised to see there is no license anywhere for the binaries... The closest thing I found is "copyright" file inside .deb: Copyright: 2020 The Pyston Team <support@pyston.org> License: Closed source, all rights reserved. I guess it means no one should be touching the file, as they haven't even granted access to run it.

bastawhiz 6y ago
From the link: > Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model.
globular-toast 6y ago
> I guess it means no one should be touching the file, as they haven't even granted access to run it. Since when does someone need to explicitly grant you permission to run a program on your own computer?
- theamk 6y ago
  Running is probably ok, but giving to others? I am not sure. Those limitations existed since before the computer time, when the copyright law was passed. For example, even you own a book, there are certain things you can not do, like duplicate it and sell copies. In case of software, here is how the law works [0] > When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. There are "fair use" terms, which allow some things without permissions -- but things like "copying the binary to company-internal repo so CI runners can pick it" really need explicit permissions if you want to be above the board. [0] https://choosealicense.com/no-permission/ https://choosealicense.com/no-permission/
  - globular-toast 6y ago

mshockwave 6y ago

My last impression on Pyston was that it got killed by Dropbox. Happy to see community efforts still continue on this project

xvilka 6y ago

There is another way. Since Pyston isn't generally compatible with the original Python, why not to use faster languages? Go for network services and console tools. Julia for AI applications, data and computational science.

ngcc_hk 6y ago

Always go back to python (and c) when in doubt. Problem is graphic user interface. TK, ... or even pythonista scene. So diverse and so non-standard.

CyberRabbi 6y ago

I thought this project was dead. Nice to see it’s alive.

yuskii 6y ago

Oh really?

sandGorgon 6y ago

Quick question - does pyston use the new PEG parser that cpython does? https://www.python.org/dev/peps/pep-0617/ https://www.python.org/dev/peps/pep-0617/ Because that's a long term risk on subtle differences that may crop up.

kzrdude 6y ago

There has been many faster python threads lately, I'm looking forward to improvements, especially, those that reach CPython! As others have been pouring out before, the new load attr opcache is maybe the most interesting recent performance improvement that was merged.

person_of_color 6y ago

What does everyone think of just switching to Julia?

jonstewart 6y ago

What is meant by “quickening”?

rurban 6y ago
The paper is gone. Maybe someone has a link. Looks like inline caching of some specific ops with certain types. Some arith and call ops are optimized this way. It also looks like dynasm was later replaced by the much slower llvm, so it needs heavy warmup.
- kzrdude 6y ago
  I wonder if it's similar to Python 3.x's opcache for Load global and load attr? It would make a lot of sense to generalize those.

rurban 6y ago

The latest open source repo, I believe, is at https://github.com/jmgc/pyston https://github.com/jmgc/pyston (latest Sep 11) 9f672c1bbb75710ac17dd3d9107da05c8e9e8e8f Maybe someone has something newer. At Oct 28 kevmod deleted all the history.