17 ms·
Faster CPython (2021) [pdf]
- ledauphin 5y agowhat happened to the recent work that was apparently a successful elimination of the Global Interpreter Lock? My work would become an order of magnitude easier if I did not have to use multiprocessing to get parallelism across shared memory.
- digisign 5y agoThere are several projects at work, any of which should land if they are successful.
- vlovich123 5y agoYeah, that was my first thought. I think Sam Gross' work is being mainlined already so hopefully this is yet more improvements on top? Unclear.
- sigzero 5y agoI believe that is a continuing WIP.
- tryptophan 5y agoUgh yeah, I hope this eventually happens. If some fork of python that has no GIL becomes popular, another python 3 situation could emerge with the community splitting. This "reference implementation should be simple and easy to read" is the dumbest part of python, unnecessarily holding it back imo.
- mkoubaa 5y agoHPy is an interesting possibility. Make the C API opaque, let extension modules migrate to it, which then allows for competing runtimes to have all the libraries out of the box
- dvlws 5y agoThe guy again gets his name in the headline. There has been no shortage of plans how to speed up CPython in the past 20 years. How about delivering a working product when it is done?
- brokencode 5y agoHis name lends a lot of credibility to anything he does with Python, and that's why this effort is notable. He is the founder and longtime BDFL of the language, and presumably knows what he is talking about when he says he can get big performance improvements.
- IshKebab 5y agoI don't know if overseeing one of the slowest mainstream languages there is for decades gives me much hope that he knows what he's talking about when it comes to performance improvements.
- iqanq 5y agoTen years ago he didn't think Python was slow: https://lwn.net/Articles/486908/ https://lwn.net/Articles/486908/
- igouy 5y ago"InfoWorld: You answered critics who said that Python is too slow. You said every time you try to write something in Python, it is fast enough. Why is there criticism that it is too slow?" "At some point, you end up with one little piece of your system, as a whole, where you end up spending all your time. If you write that just as a sort of simple-minded Python loop, at some point you will see that that is the bottleneck in your system. It is usually much more effective to take that one piece and replace that one function or module with a little bit of code you wrote in C or C++ rather than rewriting your entire system in a faster language, because for most of what you're doing, the speed of the language is irrelevant."
- ITB 5y agoI personally think Python is nice to work with and I really like Django as monolithic web framework with no dependencies- a rare thing these days. But when thinking about long term projects I’m unable to reconcile things I like with the fact that Python is among the slowest modern languages. Why would I start with an unnecessary handicap?
- Mikeb85 5y agoCan't speak for Python/Django but I'm in the Rails world and the fact is on most Rails apps (even huge ones) the Ruby code isn't the bottleneck. IO and database operations are. You don't need a fast language for the things Python (and Ruby, PHP, Perl, etc..) does.
- OtomotO 5y agoTrue, but depending on the service I personally would like efficient languages, not only dev time wise, but also runtime wise. Especially with regards to the environment. You may laugh all you want, the ever expanding internet should become way more resource friendly.
- nickjj 5y ago> True, but depending on the service I personally would like efficient languages, not only dev time wise, but also runtime wise. I don't think this really exists today partly because of the comment you replied to. Rails, Django and Laravel are massively optimized for developer productivity to build web applications and use languages that have been around long enough where the community has created widely successful and popular libraries to implement mostly common features for things aren't included by default. Libraries that go beyond 1 developer maintaining them in their free time. If you can build a web app and host it for $40 a month on a single VPS that can sustain tens of thousands of users and you can make a million dollars a year as a solo developer what incentive is there to switch to a faster language? Your secret weapon here is being able to build things quickly and not have to single handily develop a bunch of common lower level libraries just to build the app features you want. For when you need to scale out we have Kubernetes which generally works the same to scale out most types of web apps. It seriously (honestly) doesn't matter if your hosting bill is $10,000 / month instead of $3,000 / month when you have a team of 8 developers ($240,000 / month) on payroll and your web app is happily returning p99 responses in under 150ms while your business profits tens of millions of dollars a year. What does matter is how fast you can build new features while maintaining your app and finding qualified developers.
- devit 5y agoCurrently it's 50x slower than JavaScript ([https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...], look at n-body which is just straightforward math), and apparently they are looking to achieve 2x speedup and maybe 5x later, so not very useful.
- jdowner 5y agoYeah, I doubt it's ever going to catch on.
- hiptobecubic 5y agoOne-liner jokes are frowned upon here, but this was pretty good.
- aix1 5y agoI'd be very interested to see what JAX can do on this problem.
- dekhn 5y agohttps://github.com/google/jax-md https://github.com/google/jax-md
- deleted 5y ago[deleted]
- brokencode 5y ago2x or 5x is very useful if it speeds up common web server applications. A company with 4 servers can run 2 servers with a 2x speedup. Math-heavy benchmarks are not really representative of what Python is used for. They benefit from things like SIMD and aggressive inlining and fine-grained control over memory layout, etc. If you need that with Python, you can use something like NumPy or implement the hot path with a native language.
- 5y ago
- humbleharbinger 5y agoSo tackling GIL is not on the table it seems
- code_biologist 5y agoThere's already progress on that from a different angle: https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=29005573
- asojfdowgh 5y agocan't wait for this to be rather successful in hitting goals but then do nothing and languish like everything else It seems absurd to not mention the API upstreamed by the Pyjion attempt, especially in the context of optimizing bytecode / touching into machine code? I dunno, maybe I'm just perturbed by the amount of duplicated effort on this singular topic
- ivoflipse 5y agoThis is from the latest 3.11 alpha 4 release just this week: The Faster CPython Project is already yielding some exciting results: this version of CPython 3.11 is ~ 19% faster on the geometric mean of the PyPerformance benchmarks, compared to 3.10.0. https://pythoninsider.blogspot.com/2022/01/python-3102-3910-and-3110a4-are-now.html?m=1 https://pythoninsider.blogspot.com/2022/01/python-3102-3910-... So this is definitely not languishing as they are getting these changes directly into main for Python 3.11
- Alex3917 5y agoThis is great, but at the same time 19% is still pretty far from 50%, and there are only ~3 months left until the feature freeze. It will be interesting to see how far they get in this release.
- ivoflipse 5y agoFrom following their issue tracker: some ideas didn't pan out (yet), some ideas turned out to break backwards compatibility, several pyperformance tests broke because of the changes made so they had to fix upstream (eg gevent and cython) and a lot of the work seems to be setting up future optimizations. They're also getting their changes merged directly into CPython main, so I reckon there's more red tape than if they had done the work on a fork. It does seem to inspire fellow core devs to pitch in and try some of their own ideas, so I can see the effort pick up steam as they make more headway.
- Alex3917 5y ago
- erwincoumans 5y agoSpeed is one reason why Google is using Jax. With decorators, vmap/pmap it jit compiles your Python/Numpy code for fast/vectorized execution on GPU, TPU and CPU
- jstx1 5y agoAnd Instagram have their own CPython fork called Cinder - https://github.com/facebookincubator/cinder https://github.com/facebookincubator/cinder
- kanaffa12345 5y agothese two things have nothing to do with each other. jax doesn't compile numpy, it reimplemnts the api using `ufunc`. in general, every single numerical kernel is always mapped to kind of compiled code.
- erwincoumans 5y agoIt does for the user who is familiar with Python and Numpy. With some effort your Python and Numpy code becomes orders of magnitude faster. Telling that those two things have nothing to do with each other is missing the point.
- kanaffa12345 5y ago>missing the point facts 1. this is a thread about cpython. jax is as relevant to users of cpython as CUDA or OpenCL or whatever. jax cannot do absolutely anything with e.g. django. 2. for all intents and purposes all numerical code always runs in a lower-level implementation (C++, CUDA, XLA, whatever). so from that perspective, jax is just a convenient way to get from numerical python (i.e., loops and muls and adds) to kernels.
- erwincoumans 5y agoI didn't claim Jax can accelerate Django, it all depends. A lot of our Python code is/was running partly in cpython and partly in extension modules such as Numpy. There are many ways to achieve faster Python execution. One is a faster cpython implementation, another is moving cpu intensive parts of the code to extension modules (such as Numpy). Yet another is to jit compile Python (and Numpy) code to run on accelerators.
- realitysballs 5y agoThe speed of Python code creates its use cases. If it were to get faster higher volume applications could benefit but for my low-volume applications it works plenty fast.
- coldtea 5y agoShouldn't it be: "The speed of Python code constrains its use cases"?
- taylorius 5y agoI read another commenter here mention that Python is 50x slower than Javascript. Now browser Javascript VMs underwent enormous speedup efforts over the last 12-15 years (Google chrome starting the race). Is there anything inherent to Python's design as a language (or any other technical reason) that prevents such a speedy VM being created for it as well?
- adgjlsfhk1 5y agoThe big difference is that lots of python libraries use C under the hood, and a lot of internals of the language are leaked via the C api. It's a lot harder to do fancy things with a JIT when there are more people observing and depending on the internals.
- gravypod 5y agoFrom a language design perspective I don't think there's much in the way of making up this ground. The hard part is not breaking any existing modules written in C/C++/Rust/etc that depend on the cpython ABI (memory layout and calling conventions of the runtime's implementation). There are jit compilers for python like pypy which are very fast (>5x they're attempting to gain here) but they often break things like numpy that have a lot of native modules.
- londons_explore 5y agoSounds pretty straightforward to get great speedups where no modules are used, and just make module calls slow (ie. you reconstruct the data structures the module will need on any entry to the module). Then release a new 'fast' module API, and all the performance critical modules will soon move over.
- gravypod 5y agoIt might sound easy but that would be a critical component of such a rewrite. Python's standard library is implemented using the same API so much of that would need to be rewritten. You then have the risk of introducing bugs, etc. This post is doing something similar. They're rewriting the internal implementation through progressive refactoring and will then look into more long term incompatible changes that can be wrapped in a translation layer. These projects are difficult as a lot of python code exists in the world and a minor change in behavior can have large unintended consequences due to Hyrum's law.
- bilal4hmed 5y agoThis is a few months old....Have there been any updates since then? Seems like there are some perf improvements that are being added in to 3.11 and for some cases 2x faster than 3.10 https://twitter.com/danielmilde/status/1484162983584575491 https://twitter.com/danielmilde/status/1484162983584575491
- maxerickson 5y agoIt's unfortunate how those results are presented. The worst result on the pybenchmark link is comparing a numpy based implementation to one that doesn't use numpy. If the latter can't use numpy or would be slowed down by it, that's a fair comparison, but it looks like they are just at different stages of optimization.
- The_rationalist 5y ago
- 1-6 5y agoKudos to Microsoft for hiring Guido. I wish Google had kept him.
- deleted 5y ago[deleted]
- theandrewbailey 5y agoHe left Google for Dropbox, where he was for several years before "retiring".
- makecheck 5y agoWhile I think it is always good to see progress in the performance of interpreters, ultimately it is a mistake if you have something that needs to be fast and you implemented it entirely in an interpreted language (beyond just prototyping). You have to be prepared to factor out the key parts of the code into faster languages like C++ with bindings, if necessary. Or you can virtually do this, e.g. learn more about the standard library, make sure you are choosing things that actually are implemented natively underneath instead of in pure Python, etc. And sometimes, you find that the cause of a slowdown is far more fundamental (e.g. the entire algorithm is not good, and you see huge gains by redoing it, even if everything is still interpreted code).
- pizza234 5y ago> You have to be prepared to factor out the key parts of the code into faster languages like C++ with bindings, if necessary Stripe had the innovative idea of compiling ahead of time parts of the code (taking advantage of type annotations). I think this is a very interesting approach that may make usage of faster language unnecessary in a certain amount of cases.
- staticassertion 5y agoDropbox has some projects around this. I think the idea is totally silly tbh and it flies in the face of Python's type annotations being just that - annotations. The generated code is pretty hilarious since you end up with HashMaps and dynamic dispatch everywhere. Much better gains can be made by simply not using Python.
- pjmlp 5y agoI learned that lesson with Tcl back in my first startup experience. Sure the language is great, and it is very easy to write extensions in C, however as the performance pressure keeps increasing, in the end it is a C application where Tcl was reduced to a configuration/orchestration language. Since then, if it doesn't have a JIT or AOT compiler in the box I am not interested, unless I am obliged to do so by higher levels.
- wheelerof4te 5y agoHow long until some smartasses propose typing to be mandatory, because "speed"?
- CalChris 5y agoThis slide deck matches up with this interview from Talk Python with Guido and Mark Shannon. https://www.youtube.com/watch?v=_r6bFhl6wR8 https://www.youtube.com/watch?v=_r6bFhl6wR8
- kmod 5y agoShameless plug: Python 3.11 comes out this October and is slated to be 10-20% faster, but Pyston is already available and is 30% faster. We do the things that are listed in this pdf, but also additional things that will probably never make it into mainline Python (such as adding a JIT) https://github.com/pyston/pyston https://github.com/pyston/pyston
- dataflow 5y agoDo you know when you might have Windows support? Since one of the main strengths of Python is its cross-platform support, but for Pyston I only seem to see Linux support.
- cuteboy19 5y agoWhy won't JIT compilation make it to Python? Are the reasons technical or political?
- bjourne 5y agoHigh-speed JITs are complicated and the CPython code base is meant to be kept simple. If you want JITted Python use PyPy (or JAX which is a JIT for tensor computation).
- fault1 5y agoGuido seems quite anti-JIT.
- Jasper_ 5y agoThe current CPython maintainers believe that a JIT would be far too much complexity to maintain, and would drive away new contributors. I don't agree with their analysis; I would argue the bigger thing driving new contributors away is them actively doing so. People show up all the time with basic patches for things other language runtimes have been doing for 20+ years and get roasted alive for daring to suggest something as arcane as method dispatch caches. The horror! This cements the CPython team as sort of a known "don't waste your time there" in PL research communities, distancing themselves from the people most likely and willing to help maintain their runtime.
- bjourne 5y ago99.9% of all software engineering is making it correct. The remaining 0.1% is about making it "fast". I.e. either reducing latency or increasing throughput. This is why Python wins. Once it is correct it is trivial to also make it fast.
- CharlesW 5y ago> 99.9% of all software engineering is making it correct. […] Once it is correct it is trivial to also make it fast. That sounds amazing but doesn't square with my experiences as a technical PM/PO. We might have different definitions of "fast", but generally speed-optimized code is very different than prototype code (enough so that prototype "correctness" is non-transferable), more difficult to create in comparison to the prototype, and is often rewritten in a different language (Rust, C, assembly). For example, you're never going to write anything other than a toy video encoder in Python.
- bjourne 5y agoActually my experience from 20+ years of software engineering is that 99.99% of it is about correctness and only 0.01% is about performance. I added one order of magnitude to be on the safe side. Any non-toy video encoder takes advantage of hardware specific features so if you can't write it in Python you can't write it in Rust or C either.
- oweiler 5y agoThe thing is that other languages are as correct but leaps and bounds faster.
- g42gregory 5y agoI used to be really bothered by the Python’s speed and were not enthused by Guido’s insistence that it’s a connector language. But now, everything is a library call, written in C/C++. I don’t ask a question about performance anymore.
- dandotway 5y agoQuestion for JIT experts: JS and Python are extremely hard to optimize because they both allow redefining anything at any time, yet V8 crushes Python by an order of magnitude in many benchmarks[1]: All times in seconds (lower is better) benchmark Node.js Python 3 Py takes x times longer ================================================================== regex-redux 5.06 1.34 ** Py3 is faster (PCRE C) pidigits 1.14 1.16 0.02 reverse-complement 2.59 6.62 2.56 k-nucleotide 15.84 46.31 2.92 binary-trees 7.13 44.70 6.27 fasta 1.91 36.90 19.3 fannkuch-redux 11.31 341.45 30.19 (wut?) mandelbrot 4.04 177.35 43.9 (srsly?) n-body 8.42 541.34 64.3 (no numpy fortran cheat?) spectral-norm 1.67 112.97 67.65 (Python for Science[TM]) (If Python is allowed to call fast C code (PCRE) for regex-redux, I don't see why Python shouldn't be allowed to call fast Fortran BLAS/etc for n-body, but rules are rules, I guess. V8 doesn't cheat at spectral-norm, it's 100% legit JS.) Both ecosystems have billions invested by corporations worth trillions; bottomless money exists to make Python faster. So why isn't Python faster? V8's tactics include dynamically watching which loops/calls get run more than (say) 10,000 times and then speculatively generating[2] native machine instructions on the assumption the types don't change ("yep, foo(a,b) is only called with a and b both float64, generate greased x86-64 fastpath"), but gracefully falling back if the types later do change ("our greased x86-64 'foo(float64,float64)' routine will be passed a string! Fall back to slowpath! Fall back!"). Why doesn't Python do this? Is it because Google recruited the only genius unobtainium experts who could write such a thing? Google is a massive Python user, too. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2] https://ponyfoo.com/articles/an-introduction-to-speculative-optimization-in-v8 https://ponyfoo.com/articles/an-introduction-to-speculative-... EDIT: HN commenter Jasper_ perhaps has the answer in another post[3]: "The current CPython maintainers believe that a JIT would be far too much complexity to maintain, and would drive away new contributors. I don't agree with their analysis; I would argue the bigger thing driving new contributors away is them actively doing so. People show up all the time with basic patches for things other language runtimes have been doing for 20+ years and get roasted alive for daring to suggest something as arcane as method dispatch caches. The horror!" [3] https://news.ycombinator.com/item?id=30047289#30050248 https://news.ycombinator.com/item?id=30047289#30050248
- pyuser583 5y agoSo this explains why he went from Dropbox to retirement to Microsoft.
- freediver 5y agoJust tested 3.11a4 with python-speed [1] About 14% faster than 3.10. Still at only ~80% performance compared to python 2.7 [1] https://github.com/vprelovac/python-speed https://github.com/vprelovac/python-speed