31 ms·

Python 3.11 vs 3.10 performance

715 points by hyperbovine 4y ago

uniqueuid 4y ago
These speedups are awesome, but of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Having read about some of the changes [1], it seems like the python core committers preferred clean over fast implementations and have deviated from this mantra with 3.11. Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different language! [1] Here are the python docs on what precisely gave the speedups: https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpyth... [edit] A bit of explanation what I meant by low-hanging fruit: One of the changes is "Subscripting container types such as list, tuple and dict directly index the underlying data structures." Surely that seems like a straight-forward idea in retrospect. In fact, many python (/c) libraries try to do zero-copy work with data structures already, such as numpy.
- fastball 4y ago
  > Now let's get a sane concurrency story This is in very active development[1]! And seems like the Core Team is not totally against the idea[2]. [1] https://github.com/colesbury/nogil https://github.com/colesbury/nogil [2] https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-python_11.html https://pyfound.blogspot.com/2022/05/the-2022-python-languag...
- siekmanj 4y ago
  Python has actually had concurrency since about 2019: https://docs.python.org/3/library/asyncio.html https://docs.python.org/3/library/asyncio.html. Having used it a few times, it seems fairly sane, but tbf my experience with concurrency in other languages is fairly limited. edit: ray https://github.com/ray-project/ray https://github.com/ray-project/ray is also pretty easy to use and powerful for actual parallelism
  - uniqueuid 4y ago
    I have used asyncio in anger quite a bit, and have to say that it seems elegant at first and works very well for some use cases. But when you try to do things that aren't a map-reduce or Pool.map() pattern, it suddenly becomes pretty warty. E.g. scheduling work out to a processpool executor is ugly under the hood and IMO ugly syntactically as well.
    - tandav 4y ago
      > scheduling work out to a processpool executor is ugly under the hood and IMO ugly syntactically as well. Are you talking about this example? https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.run_in_executor https://docs.python.org/3/library/asyncio-eventloop.html#asy...
  - deleted 4y ago
    [deleted]
  - BugsJustFindMe 4y ago
    I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Thread/ProcessPoolExecutor is personally much nicer to use and universally applicable...unless you need to accommodate Ctrl-C and then it's ugly again. But fixing _that_ stupid problem would have been a better expenditure of effort than asyncio.
    - coldtea 4y ago
      >I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Do you compare it to threads and pools, or judge it on its merits as an async framework (with you having experience of those that you think are done better elsewhere, e.g. in Javascript, C#, etc)? Because both things you mention "demands on how you build your code" and "limited scope" are part of the course with async in most languages that aren't async-first.
- MrYellowP 4y ago
  I don't wonder. For me it seems pretty clear. I believe the reason is that python does not need any low-hanging fruits to have people use it, which is why they're a priority for so many other projects out there. Low-hanging fruits attract people who can't reach higher than that. When talking about low-hanging fruits, it's important to consider who they're for. The intended target audience. It's important to ask ones self who grabs for low-hanging fruits and why they need to be prioritized. And with that in mind, I think the answer is actually obvious: Python never required the speed, because it's just so good. The language is so popular, people search for and find ways around its limitations, which most likely actually even increases its popularity, because it gives people a lot of space to tinker in.
  - uniqueuid 4y ago
    I see your point, but it directly conflicts with the effort many people put into producing extremely fast libraries for specific purposes, such as web frameworks (benchmarked extensively), ORMs and things like json and date parsing, as seen in the excellent ciso8601 [1] for example. [1] https://github.com/closeio/ciso8601 https://github.com/closeio/ciso8601
    - dagmx 4y ago
      I disagree that it conflicts. There's an (implied) ceiling on Python performance, even after optimizations. The fear has always been that removing the design choices that cause that ceiling, would result in a different, incompatible language or runtime. If everyone knows it's never going to reach the performance needed for high performance work, and there's already an excellent escape hatch in the form of C extensions, then why would people be spending time on the middle ground of performance? It'll still be too slow to do the things required, so people will still be going out to C for them. Personally though, I'm glad for any performance increases. Python runs in so much critical infrastructure, that even a few percent would likely be a considerable energy savings when spread out over all users. Of course that assumes people upgrade their versions...but the community tends to be slow to do so in my experience.
    - mywittyname 4y ago
- KptMarchewa 4y ago
  Answer is very simple. Amount of people who got paid to make python fast was rounded to 0.
  - dekhn 4y ago
    Not really. There were a couple engineers working at Google on a project called unladen swallow which was extremely promising but it eventually got canceled. The developer who worked at Microsoft to make iron python I think that was his full-time project as well and it was definitely faster than cpython at the time
    - pstrateman 4y ago
      Neither of those projects were ever going to be accepted upstream though.
      - dekhn 4y ago
        My hope was that iron pythonreplaced cpython as the standard but for a number of reasons that was never to be.
    - switch007 4y ago
      Was the project run by a team based in Africa or Europe?
      - dekhn 4y ago
        I don't know! [Whoosh]
    - dragonwriter 4y ago
      Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.
      - coldtea 4y ago
- missblit 4y ago
  So we have: * Statically allocated ("frozen") core modules for fast imports * Avoid memory allocation for frames / faster frame creation * Inlined python functions are called in pure python without needing to jump through C * Optimizations that take advantage of speculative typing (Reminds me of Javascript JIT compilers -- though according to the FAQ Python isn't JIT yet) * Smaller memory usage for frames, objects, and exceptions Dang that certainly does sound like low hanging fruit. There's probably a lot more opportunities left if they want Python to go even faster.
  - dagmx 4y ago
    Things may seem like low hanging fruit in the abstract bullet point, but the work needed may be immense.
  - FartyMcFarter 4y ago
    > Inlined python functions are called in pure python without needing to jump through C Given that Python is interpreted, it's quite unclear what this could mean. Also, what does it mean to "call" an inlined function?? Isn't the point of inline functions that they don't get called at all?
    - liuliu 4y ago
      It seems to be just previously, it does: switch (op) { case "call_function": interpret(op.function) ... } Now it does: switch (op) { case "call_function": ... setup frame objects etc ... pc = op.function continue .... } Not sure if they just "inlined" it or use tail-call elimination trick.
    - enragedcacti 4y ago
      It's a little confusing but I don't think they meant inlining in the traditional sense. its more like they inlined the C function wrapper around python functions. > During a Python function call, Python will call an evaluating C function to interpret that function’s code. This effectively limits pure Python recursion to what’s safe for the C stack. > In 3.11, when CPython detects Python code calling another Python function, it sets up a new frame, and “jumps” to the new code inside the new frame. This avoids calling the C interpreting function altogether. > Most Python function calls now consume no C stack space. This speeds up most of such calls. In simple recursive functions like fibonacci or factorial, a 1.7x speedup was observed. This also means recursive functions can recurse significantly deeper (if the user increases the recursion limit). We measured a 1-3% improvement in pyperformance.
- Alex3917 4y ago
  > Of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Because it's developed and maintained by volunteers, and there aren't enough folks who want to spend their volunteer time messing around with assembly language. Nor are there enough volunteers that it's practical to require very advanced knowledge of programming language design theory and compiler design theory as a prerequisite for contributing. People will do that stuff if they're being paid 500k a year, like the folks who work on v8 for Google, but there aren't enough people interested in doing it for free to guarantee that CPpython will be maintained in the future if it goes too far down that path. Don't get me wrong, the fact that Python is a community-led language that's stewarded by a non-profit foundation is imho its single greatest asset. But that also comes with some tradeoffs.
  - mgaunard 4y ago
    first, there are lots of volunteers that want to mess with assembly language. second, CPython is just a C interpeter, there isn't much assembly if any. third, contributing to CPython is sufficiently high-profile you could easily land a 500k-job just by putting it on your CV. No, those are not the real reasons why it hasn't happened before.
    - Angostura 4y ago
      Go on then - what are the real reasons, in your mind?
      - coldtea 4y ago
        Unfriendly core team?
        mgaunard 4y ago
        Why should major technology projects be "friendly" to random people? I think the word you're looking for is "politics".
- int_19h 4y ago
  > one wonders why they haven't been a low-hanging fruit over the past 25 years. From the very page you've linked to: "Faster CPython explores optimizations for CPython. The main team is funded by Microsoft to work on this full-time. Pablo Galindo Salgado is also funded by Bloomberg LP to work on the project part-time."
  - ChuckNorris89 4y ago
    Hmm, looks like corporate money gets sh*t done.
    - deleted 4y ago
      [deleted]
    - lmm 4y ago
      Yep. That's the thing about the open source dream; especially for work like this that requires enough time commitment to understand the whole system, and a lot of uninteresting grinding details such that very few people would do it for fun, you really need people being funded to work on it full-time (and a 1-year academic grant probably doesn't cut it), and businesses are really the only source for that.
- simias 4y ago
  I suspect that the amount of people and especially companies willing to spend time and money optimizing Python are fairly low. Think about it: if you have some Python application that's having performance issues you can either dig into a foreign codebase to see if you can find something to optimize (with no guarantee of result) and if you do get something done you'll have to get the patch upstream. And all that "only" for a 25% speedup. Or you could rewrite your application in part or in full in Go, Rust, C++ or some other faster language to get a (probably) vastly bigger speedup without having to deal with third parties.
  - ketralnis 4y ago
    > you can either dig into a foreign codebase ... > Or you could rewrite your application Programmers love to save an hour in the library by spending a week in the lab
    - prionassembly 4y ago
      Everyone likes to shirk away from their jobs; engineers and programmers have ways of making their fun (I'm teaching myself how to write parsers by giving each project a DSL) look like work. Lingerie designers or eyebrow barbers have nothing of the sort, they just blow off work on TikTok or something.
      - fragmede 4y ago
        TikTok’s got some fun coding content, if you can get the algorithm to surface it to you.
  - LtWorf 4y ago
    There was some guarantee of result. It has been a long process but there was mostly one person who had identified a number of ways to make it faster but wanted financing to actually do the job. Seems Microsoft is doing the financing, but this has been going on for quite a while.
  - dubbel 4y ago
    You are right, that's usually not how it works. Instead, there are big companies, who are running let's say the majority of their workloads in python. It's working well, it doesn't need to be very performant, but together all of the workloads are representing a considerable portion of your compute spend. At a certain scale it makes sense to employ experts who can for example optimize Python itself, or the Linux kernel, or your DBMS. Not because you need the performance improvement for any specific workload, but to shave off 2% of your total compute spend. This isn't applicable to small or medium companies usually, but it can work out for bigger ones.
- Jasper_ 4y ago
  > one wonders why they haven't been a low-hanging fruit over the past 25 years Because the core team just hasn't prioritized performance, and have actively resisted performance work, at least until now. The big reason has been about maintainership cost of such work, but often times plenty of VM engineers show up to assist the core team and they have always been pushed away. > Now let's get a sane concurrency story You really can't easily add a threading model like that and make everything go faster. The hype of "GIL-removal" branches is that you can take your existing threading.Thread Python code, and run it on a GIL-less Python, and you'll instantly get a 5x speedup. In practice, that's not going to happen, you're going to have to modify your code substantially to support that level of work. The difficulty with Python's concurrency is that the language doesn't have a cohesive threading model, and many programs are simply held alive and working by the GIL.
  - dekhn 4y ago
    Yup. Sad but true. I just wanted c++ style multithreading with unsafe shared memory but it's too late. I was impressed by the recent fork that addresses this in a very sophisticated way, but realistically gil cpython will keep finding speed ups to stave off the transition.
    - pca006132 4y ago
      wondering how that interacts with c/c++ extensions that presumes the existance of the GIL
      - dekhn 4y ago
        A good place to start learning about this https://www.backblaze.com/blog/the-python-gil-past-present-and-future/ https://www.backblaze.com/blog/the-python-gil-past-present-a...
- staticassertion 4y ago
  Guido stepping away from the language will have a lot of impact on changes that were culturally guided.
  - mjw1007 4y ago
    Guido is one of the people leading the current performance efforts.
    - staticassertion 4y ago
      That's interesting. Thanks.
  - deleted 4y ago
    [deleted]
- gostsamo 4y ago
  A few people tried to excuse the slow python, but as far as I know the story, excuses are not necessary. Truth is that python was not meant to be fast, its source code was not meant to be fast, and its design was not optimized with the idea of being fast. Python was meant as a scrypting language that was easy to learn and work with on all levels and the issue of its slowness became important when it outgrew its role and became an application language powering large parts of the internet and the bigger part of the very expensive ML industry. I know that speed is a virtue, but it becomes a fundamental virtue when you have to scale and python was not meant to scale. So, yes, it is easy for people to be righteous and furious over the issue, but being righteous in hindsight is much easier than useful.
  - atwood22 4y ago
    > Python was meant as a scrypting language that was easy to learn and work with on all levels. Being fast isn't contradictory with this goal. If anything, this is a lesson that so many developers forget. Things should be fast by default.
    - BeetleB 4y ago
      > Things should be fast by default. In over 90% of my work in the SW industry, being fast(er) was of no benefit to anyone. So no, it should not be fast by default.
      - vorticalbox 4y ago
        Being first to market is usually more important than being faster then those who got there first.
      - uoaei 4y ago
        Ha! Good luck convincing end-users that that's true.
        BeetleB 4y ago
        I don't need to. Less than 10% of end users have put in requests for performance improvements.
- Fiahil 4y ago
  > Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different language! Yes, and I would argue it already exists and is called Rust :) Semi-jokes aside, this is difficult and is not just about removing the GIL and enabling multithreading ; we would need to get better memory and garbage collection controls. Parts of what's make python slow and dangerous in concurrent settings are the ballooning memory allocations on large and fragmented workloads. A -Xmx would help.
- oaiey 4y ago
  There is a race right now to be more performant. .NET, Java, Go already participate, Rust/C++ are anyway there. So to stay relevant they have to start participate. .NET went through the same some years ago. And why they were not addressed: because starting a certain points, the optimization are e.g. processor specific or non intuitive to understand. Making it hard to maintain vs a simple straight forward solution.
- tambourine_man 4y ago
  That’s something that has always puzzled me as well. Given the popularity, you’d think Python would have had several generations of JITs by now and yet it still runs interpreted, AFAIK. JavaScript has proven that any language can be made fast given enough money and brains, no matter how dynamic. Maybe Python's C escape hatch is so good that it’s not worth the trouble. It’s still puzzling to me though.
  - dragonwriter 4y ago
    > JavaScript has proven that any language can be made fast given enough money and brains, Yeah but commercial Smalltalk proved that a long time before JS did. (Heck, back when it was maintained, the fastest Ruby implementation was built on top of a commercial Smalltalk system, which makes sense given they have a reasonably similar model.) The hard part is that “enough money“ is...not a given, especially for noncommercial projects. JS got it because Google decided JavaScript speed was integral to it's business of getting the web to replace local apps. Microsoft recently developed sufficient interest in Python to throw some money at it.
    - tambourine_man 4y ago
      Yes, I’m aware of the Smalltalk miracle. Google wasn’t alone in optimizing JS, it actually came late, Safari and Firefox were already competing and improving their runtime speeds, though V8 did doubled down on the bet of a fast JS machine. The question is why there isn’t enough money, given that there obviously is a lot of interest from big players.
      - dragonwriter 4y ago
        > The question is why there isn’t enough money, given that there obviously is a lot of interest from big players. I'd argue that there wasn't actually much interest until recently, and that's because it is only recently that interest in the CPython ecosystem has intersected with interest in speed that has money behind it, because of the sudden broad relevance to commercial business of the Python scientific stack for data science. Both Unladen Swallow and IronPython were driven by interest in Python as a scripting language in contexts detached from, or at least not necessarily attached to, the existing CPython ecosystem.
- Sesse__ 4y ago
  Because Guido van Rossum just isn't very good with performance, and when others tried to contribute improvements, he started heckling their talk because he thought they were “condescending”: https://lwn.net/Articles/754163/ https://lwn.net/Articles/754163/ And by this time, we've come to the point where the Python extension API is as good as set in stone. Note that all of the given benchmarks are microbenchmarks; the gains in 3.11 are _much_ less pronounced on larger systems like web frameworks.
  - LtWorf 4y ago
    Yeah breaking compatibility kills a language. He did the right thing.
    - gpderetta 4y ago
      yet breaking compatibility in the 2->3 transition so that we can use print in lambdas was perfectly fine.
      - LtWorf 4y ago
        People learn from mistakes
- emmelaich 4y ago
  Perhaps they took a lesson from Perl; its code base was so complex as to be near unmaintainable. In addition to the other point here about speed not being a target in the first place.
gfd 4y ago
Did anyone try running this benchmark with other python implementations? (Pypy etc)
- pen2l 4y ago
  Too many things with Pypy (and other supposedly faster implementations) don't work, so it's a no-go for a lot of projects to begin with. In the last 10 years, I looked into pypy I think three or four times to speed things up, it didn't work even once. (I don't remember exactly what it was that didn't play nice... but I'm thinking it must have been pillow|numpy|scipy|opencv|plotting libraries).
londons_explore 4y ago
This looks like incremental performance work rather than a ground-up new approach, like an optimising compiler or JIT...
- int_19h 4y ago
  Python JITs were tried before, more than once. The usual problem there is that the gains are very modest unless you can also break the ABI for native modules. But if you do the latter, most users won't even bother with your version.
  - cglace 4y ago
    I believe a JIT is planned for 3.12
imwillofficial 4y ago
That’s wild, do we typically see such gains in dot releases? I don’t remember the last time this happened. Great news.
- dagmx 4y ago
  Programming language dot releases can tend to be significant. Semver often means that major is the language version, and minor is the runtime version
  - luhn 4y ago
    To nitpick a little bit, Python does not follow semver and does not claim to follow semver. Minor versions are mostly backwards compatible, but do include breaking changes.
- dswalter 4y ago
  Python dot releases are significant releases. Perhaps you recall the last python integer version number change? As a result, it will be quite some time before we see a version 4.
- wheelerof4te 4y ago
  Python's versioning has been misleading ever since 3.0 shipped. There was a heap of features added between 3.5 and 3.11, for example. Enough to make it a completely different language.
tasubotadas 4y ago
Cool improvement but changes very little when Python is x100 times slower than other GC languages.
- woodruffw 4y ago
  This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)
  - TuringTest 4y ago
    > 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.) And that's even assuming that the code would have existed at all in another language. The thing about interpreted GC languages is that the iterative loop of creation is much more agile, easier to start with and easier to prototype in than a compiled, strictly typed language.
    - z3c0 4y ago
      I think this is the best explanation for its popularity. Sure, it runs slow, but it's very fast to write. The latter is usually more important in the world of business, for better or worse.
      - jonnycomputer 4y ago
        The majority of code I write, the efficiency of the code is mostly a secondary concern; it will be run only a few times at most, and the fact that its a a few 1000 times slower than something written in C or C++ means waiting a few more seconds (at most) for my results. Most of my time spent is writing it, not running it.
      - toyg 4y ago
woodruffw 4y ago
This is really incredible work. The "What's New" page has an item-by-item breakdown of each performance tweak and its measured effect[1]. In particular, PEP 659 and the call/frame optimizations stand out to me as very clever and a strong foundation for future improvements. [1]: https://docs.python.org/3.11/whatsnew/3.11.html https://docs.python.org/3.11/whatsnew/3.11.html
- deleted 4y ago
  [deleted]
ineedasername 4y ago
If it's 25% faster then the point versions should be (rounded) 3.88.
sod 4y ago
I wish there was something like llvm for scripting languages. Imagine if python, php, javascript, dart or ruby would not interpret the code themself, but compile to an interpretable common language, where you could just plug in the fastest interpreter there is for the job.
- jacobn 4y ago
  JVM and GraalVM? https://www.graalvm.org/ https://www.graalvm.org/
- MarkSweep 4y ago
  The RPython language PyPy is written in is designed to enable writing JIT-compiled interceptors for any language: https://rpython.readthedocs.io/en/latest/ https://rpython.readthedocs.io/en/latest/ There is also the Dynamic Language Runtime, which is used to implement IronPython and IronRuby on top of .NET: https://en.wikipedia.org/wiki/Dynamic_Language_Runtime https://en.wikipedia.org/wiki/Dynamic_Language_Runtime
  - adsharma 4y ago
    rpython is designed to write new interpreters. Not aware of many apps written in the rpython dialect. There are bunch of transpilers which might provide a path from statically typed python3 to native binaries. py2many is one of them. The downside is that all of the C extensions that python3 uses become unusable and need to be rewritten in the subset of python3 that the transpiler accepts.
- Aperocky 4y ago
  That's why they are called scripting languages.
- chickenpotpie 4y ago
  Webassembly can fulfill that requirement for certain use cases
  - cmrdporcupine 4y ago
alexfromapex 4y ago
One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.
- bilsbie 4y ago
  When is that coming? Yes the error messages are confusing in a big list comprehension.
  - alexfromapex 4y ago
    Will be in the 3.11 release: https://docs.python.org/3.11/whatsnew/3.11.html#new-features https://docs.python.org/3.11/whatsnew/3.11.html#new-features
  - teekert 4y ago
    Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.
    - 8organicbits 4y ago
      "Debugging is twice as hard as writing the code in the first place. Therfore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Rajanand Although, personally, I enjoy python list comprehensions.
      - timoteostewart 4y ago
        I believe that quote about debugging being twice as hard as coding is by Brian Kernighan. https://en.m.wikiquote.org/wiki/Brian_Kernighan https://en.m.wikiquote.org/wiki/Brian_Kernighan
        8organicbits 4y ago
bilsbie 4y ago
I’d be curious to see the speed up compared to python 2.4. To see how far it’s come since I first got started with it.
- upupandup 4y ago
  it means you are not following PEP8 if you get non descriptive errors, it means you haven't followed proper exception handling/management its not the fault of Python but the developer. go ahead and downvote me but you if you mentioned parent's comment in an interview, you would not receive a call back or at least I hope the interviewer is realizing the skill gap.
  - bilsbie 4y ago
    How so?
  - d23 4y ago
    I think this is both insulting and not even responding to the right comment.
  - uoaei 4y ago
    Ah yes, the "why make things easier when you could do things the hard way" argument.
anewpersonality 4y ago
What happened to multithreaded Facebookthon?
s9w 4y ago
12ms to 6ms is not 2xfaster. It's 1x faster or 2 times as fast
IceHegel 4y ago
Next we need some standardization around package management. I recently tried installing the Metal optimized pytorch and descended into package and Python path hell.
- tandav 4y ago
  Just use conda or docker
deleted 4y ago
[deleted]
superjan 4y ago
Yesterday, I watched Emery Berger’s “Python performance matters” Which is you should not bother to write fast Python, just delegate all heavy lifting to optimized C/c++ and the likes. His group has a Python profiler whose main goal is to point out which parts should be delegated. Of course optimized is better but the numeric microbenchmarks in this post are mostly examples of code that is better delegated to low overhead compiled languages. https://youtu.be/LLx428PsoXw https://youtu.be/LLx428PsoXw
- wheelerof4te 4y ago
  The key wording is "optimized C". CPython is already executed in pure C, the only difference it being a very slow, unoptimized C. The code for simple adding of two numbers is insane. It jumps through enough hoops to make you wonder how is it even running everything else.
- ModernMech 4y ago
  > you should not bother to write fast Python, just delegate all heavy lifting to optimized C/c++ and the likes Certainly that's something you can do, but unfortunately for Python it opens the door for languages like Julia, which are trying to say that you can have your cake and eat it too.
  - galangalalgol 4y ago
    I like Julia but its easy to write slow julia unless you keep the performance tips in mind. Arrays are horribly slow, tuples are much faster, but having tuples be a multiple of 128 bytes adds 10% or more to speed. I honestly don't understand how much slower arrays are. Its like 30x or similar.
    - jolux 4y ago
      That’s bizarre, are they implemented as linked lists or something? Why would arrays be that slow?
      - 4y ago
antman 4y ago
There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part. If anyone more knowledgable can review this and give some feedback I think will be here in HN
- didip 4y ago
  I agree, please don't just accept the optimization and sweep the GIL removal under the rug again.
- nmstoker 4y ago
  I think you mean the work by Sam Gross: https://github.com/colesbury/nogil/ https://github.com/colesbury/nogil/ Interesting article about it here: https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/ https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...
- BerislavLopac 4y ago
  The GIL removal by that guy reverted some of the improvement done by other optimisations, so the overall improvement was much smaller. And most people do care for single-threaded speed, because the vast majority of Python software is written as single-threaded.
  - metadat 4y ago
    > the vast majority of Python software is written as single-threaded. This is a self-fulfilling prophecy, as the GIL makes Python's (and Ruby's) concurrency story pretty rough compared to nearly all other widely used languages: C, C++, Java, Go, Rust, and even Javascript (as of late).
    - SiempreViernes 4y ago
      Pretty sure it is actually a statement that comes from the "python is a scripting language" school, and not because the huge horde of programmers that craves concurrency when they write a script to reformat a log file to csv keeps being put off by the python multiprocessing story.
8organicbits 4y ago
Is this speed a feature of python now, or is this performance something that could regress in future if needed for a different feature? As in, will python continue to run this fast (or faster)?
- EnKopVand 4y ago
  I think it’s hard to answer your question. The development mentality of Python seems to have changed a little, going into 3.11, and you see sort of a shift in the priority of clean vs fast. I think you can assume that Python will continue to care about speed, but really, it sort of always has. Just like it’s going to continue to care about clean implementation. Then there is the part where Python will likely never become a “fast” language in the sense that C is a fast language, but the flip side of this is that Python was probably already fast enough for most uses. I tend to like to use the “we aren’t Netflix” or the “stackoverflow runs on IIS and always has” arguments when it comes to worrying about speed in anyone who isn’t Netflix, but that doesn’t really apply to Python since the backend of Instagram is django, and if Python can power Instagram then it’s probably fast enough for you, unless you’re already working with C/C++/Rust and know exactly why you are working with those. I know I’m a bit more focused on the business side of things than a lot of techies here on HN, it’s a curse and a gift, but what I read the 10-60% speed increase as is money. The less resources you consume, the less money you burn. Which is really good news for Python in general, because it makes it more competitive to languages like C# for many implementations. This comes from the perspective of someone who actually things running Typescript on your backend is a good idea because it lets you share developer resources easier so that the people who are really good at react can cover for the people who are really good at the backend and the other way around in smaller teams in non-software-engineering organisations.
mixmastamyk 4y ago
There have been a number of release blockers recently, and growing even as others fixed: https://mail.python.org/archives/list/python-dev@python.org/thread/7AT3YTUJOYMZI4VNMSJ42BE6ZNR7GANM/ https://mail.python.org/archives/list/python-dev@python.org/... Folks not desperate for the improvements might want before jumping in.
cercatrova 4y ago
Somewhat related, had anyone used Nim? These days I've been using it for its Python like syntax year C like speed, especially if I just need to script something quickly.
- objektif 4y ago
  Is it worth it to learn? Especially when you have python?
  - cercatrova 4y ago
    Yeah it's a nice language, it has optional static types as well which is always a plus in my experience. The speed though is what's really interesting.
- int_19h 4y ago
  The problem with any new language is libraries and tooling.
  - cercatrova 4y ago
    I use it for scripting mainly when I don't need Python specific libraries like pandas. The tooling is pretty good as well.
    - moffkalast 4y ago
      Seems like just going with bash would be more straightforward?
      - cercatrova 4y ago
        Why would I want to subject myself to writing in a language like bash? Bash has many disadvantages compared to Python, Nim, Go, nearly anything that isn't brainfuck.
        4y ago
rhabarba 4y ago
If performance is relevant to you, Python is the wrong language for you.
- catskul2 4y ago
  If you think this is the kind of statement that it's possible to make, software might be the wrong field for you.
sandGorgon 4y ago
is this project sponsored by microsoft ? it seems that the devs in the github org all work for microsoft
- korijn 4y ago
  Yes
bergenty 4y ago
I just learned today that python is 100x slower than C. I have severely lost respect for python.
- deleted 4y ago
  [deleted]
- StevePerkins 4y ago
  If you just learned this today, then HN has severely lost respect for you! lol
  - bergenty 4y ago
    Yes it’s deserved but I’ve been in management for a while.
    - aunty_helen 4y ago
      From your perspective then, python is 100x faster than c
      - bergenty 4y ago
        We don’t use python but you’re very articulate, Helen.
- calibas 4y ago
  C is faster than Python, but it's much more nuanced than saying Python is "100x slower". Try writing a program to open and parse a CSV file line by line in both languages. You'll see why people like Python. Also, because of FFI, it's not like the two languages are opposed to each other and you have to choose. They can happily work together.
- 4gotunameagain 4y ago
  And oranges contain 10x the vitamin C of apples :)
ttul 4y ago
Guido’s group at Microsoft have been busy.
pineapplejuice 4y ago
Is there a website which tracks which of the major libraries; pandas, requests, django, etc support each major version? I remember there was one years ago for python 3.6? Been a long time!
- robertlacok 4y ago
  I think this is what you’re looking for: https://pyreadiness.org/3.11/ https://pyreadiness.org/3.11/
  - pineapplejuice 4y ago
    Thanks!
truth_seeker 4y ago
It's good but not good enough.
michaelcampbell 4y ago
This use of "faster" in the text; I think they mean "as fast". "1x faster" to me says twice the speed of the original, but I believe they use it to mean "the same speed".
- smcl 4y ago
  That's not actually a bad observation even though you were downvoted. I think in the end it's technically ambiguous but most people would be able to see what is meant especially given the previous performance is present (i.e. for benchmark "deltablue" we have columns "12.4 ms" and "6.35 ms (1.96x faster)". But you're right, I think "1.96x as fast" sounds more correct. edit: but now that I think about it "X as fast" or "X faster" in terms of a duration will always sound a bit weird
  - michaelcampbell 4y ago
    It's an OCD pet peeve of mine. Worse yet is "2x slower!" To me, 1x slower is "stopped". I know they MEAN "1/2 the speed", but it still bugs me.
    - smcl 4y ago
      Oh that's like the US thing of saying something as "10 times less than ..." rather than "one tenth of ..."
      - michaelcampbell 4y ago
        Exactly that. I'm in the US and see it, but didn't know it was a US "thing". But yes, that.
        smcl 4y ago
        It could also just be a new thing for English overall that I've associated more with the USA because I listen to or watch a lot of American podcasts, videos and streamers. I'm not the type who gets worked up at American vs British English :-)

715 points by hyperbovine 4y ago

These speedups are awesome, but of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Having read about some of the changes [1], it seems like the python core committers preferred clean over fast implementations and have deviated from this mantra with 3.11. Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different language! [1] Here are the python docs on what precisely gave the speedups: https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpyth... [edit] A bit of explanation what I meant by low-hanging fruit: One of the changes is "Subscripting container types such as list, tuple and dict directly index the underlying data structures." Surely that seems like a straight-forward idea in retrospect. In fact, many python (/c) libraries try to do zero-copy work with data structures already, such as numpy.

fastball 4y ago
> Now let's get a sane concurrency story This is in very active development[1]! And seems like the Core Team is not totally against the idea[2]. [1] https://github.com/colesbury/nogil https://github.com/colesbury/nogil [2] https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-python_11.html https://pyfound.blogspot.com/2022/05/the-2022-python-languag...
siekmanj 4y ago
Python has actually had concurrency since about 2019: https://docs.python.org/3/library/asyncio.html https://docs.python.org/3/library/asyncio.html. Having used it a few times, it seems fairly sane, but tbf my experience with concurrency in other languages is fairly limited. edit: ray https://github.com/ray-project/ray https://github.com/ray-project/ray is also pretty easy to use and powerful for actual parallelism
- uniqueuid 4y ago
  I have used asyncio in anger quite a bit, and have to say that it seems elegant at first and works very well for some use cases. But when you try to do things that aren't a map-reduce or Pool.map() pattern, it suddenly becomes pretty warty. E.g. scheduling work out to a processpool executor is ugly under the hood and IMO ugly syntactically as well.
  - tandav 4y ago
    > scheduling work out to a processpool executor is ugly under the hood and IMO ugly syntactically as well. Are you talking about this example? https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.run_in_executor https://docs.python.org/3/library/asyncio-eventloop.html#asy...
- deleted 4y ago
  [deleted]
- BugsJustFindMe 4y ago
  I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Thread/ProcessPoolExecutor is personally much nicer to use and universally applicable...unless you need to accommodate Ctrl-C and then it's ugly again. But fixing _that_ stupid problem would have been a better expenditure of effort than asyncio.
  - coldtea 4y ago
    >I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Do you compare it to threads and pools, or judge it on its merits as an async framework (with you having experience of those that you think are done better elsewhere, e.g. in Javascript, C#, etc)? Because both things you mention "demands on how you build your code" and "limited scope" are part of the course with async in most languages that aren't async-first.
MrYellowP 4y ago
I don't wonder. For me it seems pretty clear. I believe the reason is that python does not need any low-hanging fruits to have people use it, which is why they're a priority for so many other projects out there. Low-hanging fruits attract people who can't reach higher than that. When talking about low-hanging fruits, it's important to consider who they're for. The intended target audience. It's important to ask ones self who grabs for low-hanging fruits and why they need to be prioritized. And with that in mind, I think the answer is actually obvious: Python never required the speed, because it's just so good. The language is so popular, people search for and find ways around its limitations, which most likely actually even increases its popularity, because it gives people a lot of space to tinker in.
- uniqueuid 4y ago
  I see your point, but it directly conflicts with the effort many people put into producing extremely fast libraries for specific purposes, such as web frameworks (benchmarked extensively), ORMs and things like json and date parsing, as seen in the excellent ciso8601 [1] for example. [1] https://github.com/closeio/ciso8601 https://github.com/closeio/ciso8601
  - dagmx 4y ago
    I disagree that it conflicts. There's an (implied) ceiling on Python performance, even after optimizations. The fear has always been that removing the design choices that cause that ceiling, would result in a different, incompatible language or runtime. If everyone knows it's never going to reach the performance needed for high performance work, and there's already an excellent escape hatch in the form of C extensions, then why would people be spending time on the middle ground of performance? It'll still be too slow to do the things required, so people will still be going out to C for them. Personally though, I'm glad for any performance increases. Python runs in so much critical infrastructure, that even a few percent would likely be a considerable energy savings when spread out over all users. Of course that assumes people upgrade their versions...but the community tends to be slow to do so in my experience.
  - mywittyname 4y ago
KptMarchewa 4y ago
Answer is very simple. Amount of people who got paid to make python fast was rounded to 0.
- dekhn 4y ago
  Not really. There were a couple engineers working at Google on a project called unladen swallow which was extremely promising but it eventually got canceled. The developer who worked at Microsoft to make iron python I think that was his full-time project as well and it was definitely faster than cpython at the time
  - pstrateman 4y ago
    Neither of those projects were ever going to be accepted upstream though.
    - dekhn 4y ago
      My hope was that iron pythonreplaced cpython as the standard but for a number of reasons that was never to be.
  - switch007 4y ago
    Was the project run by a team based in Africa or Europe?
    - dekhn 4y ago
      I don't know! [Whoosh]
  - dragonwriter 4y ago
    Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.
    - coldtea 4y ago
missblit 4y ago
So we have: * Statically allocated ("frozen") core modules for fast imports * Avoid memory allocation for frames / faster frame creation * Inlined python functions are called in pure python without needing to jump through C * Optimizations that take advantage of speculative typing (Reminds me of Javascript JIT compilers -- though according to the FAQ Python isn't JIT yet) * Smaller memory usage for frames, objects, and exceptions Dang that certainly does sound like low hanging fruit. There's probably a lot more opportunities left if they want Python to go even faster.
- dagmx 4y ago
  Things may seem like low hanging fruit in the abstract bullet point, but the work needed may be immense.
- FartyMcFarter 4y ago
  > Inlined python functions are called in pure python without needing to jump through C Given that Python is interpreted, it's quite unclear what this could mean. Also, what does it mean to "call" an inlined function?? Isn't the point of inline functions that they don't get called at all?
  - liuliu 4y ago
    It seems to be just previously, it does: switch (op) { case "call_function": interpret(op.function) ... } Now it does: switch (op) { case "call_function": ... setup frame objects etc ... pc = op.function continue .... } Not sure if they just "inlined" it or use tail-call elimination trick.
  - enragedcacti 4y ago
    It's a little confusing but I don't think they meant inlining in the traditional sense. its more like they inlined the C function wrapper around python functions. > During a Python function call, Python will call an evaluating C function to interpret that function’s code. This effectively limits pure Python recursion to what’s safe for the C stack. > In 3.11, when CPython detects Python code calling another Python function, it sets up a new frame, and “jumps” to the new code inside the new frame. This avoids calling the C interpreting function altogether. > Most Python function calls now consume no C stack space. This speeds up most of such calls. In simple recursive functions like fibonacci or factorial, a 1.7x speedup was observed. This also means recursive functions can recurse significantly deeper (if the user increases the recursion limit). We measured a 1-3% improvement in pyperformance.
Alex3917 4y ago
> Of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Because it's developed and maintained by volunteers, and there aren't enough folks who want to spend their volunteer time messing around with assembly language. Nor are there enough volunteers that it's practical to require very advanced knowledge of programming language design theory and compiler design theory as a prerequisite for contributing. People will do that stuff if they're being paid 500k a year, like the folks who work on v8 for Google, but there aren't enough people interested in doing it for free to guarantee that CPpython will be maintained in the future if it goes too far down that path. Don't get me wrong, the fact that Python is a community-led language that's stewarded by a non-profit foundation is imho its single greatest asset. But that also comes with some tradeoffs.
- mgaunard 4y ago
  first, there are lots of volunteers that want to mess with assembly language. second, CPython is just a C interpeter, there isn't much assembly if any. third, contributing to CPython is sufficiently high-profile you could easily land a 500k-job just by putting it on your CV. No, those are not the real reasons why it hasn't happened before.
  - Angostura 4y ago
    Go on then - what are the real reasons, in your mind?
    - coldtea 4y ago
      Unfriendly core team?
      - mgaunard 4y ago
        Why should major technology projects be "friendly" to random people? I think the word you're looking for is "politics".
int_19h 4y ago
> one wonders why they haven't been a low-hanging fruit over the past 25 years. From the very page you've linked to: "Faster CPython explores optimizations for CPython. The main team is funded by Microsoft to work on this full-time. Pablo Galindo Salgado is also funded by Bloomberg LP to work on the project part-time."
- ChuckNorris89 4y ago
  Hmm, looks like corporate money gets sh*t done.
  - deleted 4y ago
    [deleted]
  - lmm 4y ago
    Yep. That's the thing about the open source dream; especially for work like this that requires enough time commitment to understand the whole system, and a lot of uninteresting grinding details such that very few people would do it for fun, you really need people being funded to work on it full-time (and a 1-year academic grant probably doesn't cut it), and businesses are really the only source for that.
simias 4y ago
I suspect that the amount of people and especially companies willing to spend time and money optimizing Python are fairly low. Think about it: if you have some Python application that's having performance issues you can either dig into a foreign codebase to see if you can find something to optimize (with no guarantee of result) and if you do get something done you'll have to get the patch upstream. And all that "only" for a 25% speedup. Or you could rewrite your application in part or in full in Go, Rust, C++ or some other faster language to get a (probably) vastly bigger speedup without having to deal with third parties.
- ketralnis 4y ago
  > you can either dig into a foreign codebase ... > Or you could rewrite your application Programmers love to save an hour in the library by spending a week in the lab
  - prionassembly 4y ago
    Everyone likes to shirk away from their jobs; engineers and programmers have ways of making their fun (I'm teaching myself how to write parsers by giving each project a DSL) look like work. Lingerie designers or eyebrow barbers have nothing of the sort, they just blow off work on TikTok or something.
    - fragmede 4y ago
      TikTok’s got some fun coding content, if you can get the algorithm to surface it to you.
- LtWorf 4y ago
  There was some guarantee of result. It has been a long process but there was mostly one person who had identified a number of ways to make it faster but wanted financing to actually do the job. Seems Microsoft is doing the financing, but this has been going on for quite a while.
- dubbel 4y ago
  You are right, that's usually not how it works. Instead, there are big companies, who are running let's say the majority of their workloads in python. It's working well, it doesn't need to be very performant, but together all of the workloads are representing a considerable portion of your compute spend. At a certain scale it makes sense to employ experts who can for example optimize Python itself, or the Linux kernel, or your DBMS. Not because you need the performance improvement for any specific workload, but to shave off 2% of your total compute spend. This isn't applicable to small or medium companies usually, but it can work out for bigger ones.
Jasper_ 4y ago
> one wonders why they haven't been a low-hanging fruit over the past 25 years Because the core team just hasn't prioritized performance, and have actively resisted performance work, at least until now. The big reason has been about maintainership cost of such work, but often times plenty of VM engineers show up to assist the core team and they have always been pushed away. > Now let's get a sane concurrency story You really can't easily add a threading model like that and make everything go faster. The hype of "GIL-removal" branches is that you can take your existing threading.Thread Python code, and run it on a GIL-less Python, and you'll instantly get a 5x speedup. In practice, that's not going to happen, you're going to have to modify your code substantially to support that level of work. The difficulty with Python's concurrency is that the language doesn't have a cohesive threading model, and many programs are simply held alive and working by the GIL.
- dekhn 4y ago
  Yup. Sad but true. I just wanted c++ style multithreading with unsafe shared memory but it's too late. I was impressed by the recent fork that addresses this in a very sophisticated way, but realistically gil cpython will keep finding speed ups to stave off the transition.
  - pca006132 4y ago
    wondering how that interacts with c/c++ extensions that presumes the existance of the GIL
    - dekhn 4y ago
      A good place to start learning about this https://www.backblaze.com/blog/the-python-gil-past-present-and-future/ https://www.backblaze.com/blog/the-python-gil-past-present-a...
staticassertion 4y ago
Guido stepping away from the language will have a lot of impact on changes that were culturally guided.
- mjw1007 4y ago
  Guido is one of the people leading the current performance efforts.
  - staticassertion 4y ago
    That's interesting. Thanks.
- deleted 4y ago
  [deleted]
gostsamo 4y ago
A few people tried to excuse the slow python, but as far as I know the story, excuses are not necessary. Truth is that python was not meant to be fast, its source code was not meant to be fast, and its design was not optimized with the idea of being fast. Python was meant as a scrypting language that was easy to learn and work with on all levels and the issue of its slowness became important when it outgrew its role and became an application language powering large parts of the internet and the bigger part of the very expensive ML industry. I know that speed is a virtue, but it becomes a fundamental virtue when you have to scale and python was not meant to scale. So, yes, it is easy for people to be righteous and furious over the issue, but being righteous in hindsight is much easier than useful.
- atwood22 4y ago
  > Python was meant as a scrypting language that was easy to learn and work with on all levels. Being fast isn't contradictory with this goal. If anything, this is a lesson that so many developers forget. Things should be fast by default.
  - BeetleB 4y ago
    > Things should be fast by default. In over 90% of my work in the SW industry, being fast(er) was of no benefit to anyone. So no, it should not be fast by default.
    - vorticalbox 4y ago
      Being first to market is usually more important than being faster then those who got there first.
    - uoaei 4y ago
      Ha! Good luck convincing end-users that that's true.
      - BeetleB 4y ago
        I don't need to. Less than 10% of end users have put in requests for performance improvements.
Fiahil 4y ago
> Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different language! Yes, and I would argue it already exists and is called Rust :) Semi-jokes aside, this is difficult and is not just about removing the GIL and enabling multithreading ; we would need to get better memory and garbage collection controls. Parts of what's make python slow and dangerous in concurrent settings are the ballooning memory allocations on large and fragmented workloads. A -Xmx would help.
oaiey 4y ago
There is a race right now to be more performant. .NET, Java, Go already participate, Rust/C++ are anyway there. So to stay relevant they have to start participate. .NET went through the same some years ago. And why they were not addressed: because starting a certain points, the optimization are e.g. processor specific or non intuitive to understand. Making it hard to maintain vs a simple straight forward solution.
tambourine_man 4y ago
That’s something that has always puzzled me as well. Given the popularity, you’d think Python would have had several generations of JITs by now and yet it still runs interpreted, AFAIK. JavaScript has proven that any language can be made fast given enough money and brains, no matter how dynamic. Maybe Python's C escape hatch is so good that it’s not worth the trouble. It’s still puzzling to me though.
- dragonwriter 4y ago
  > JavaScript has proven that any language can be made fast given enough money and brains, Yeah but commercial Smalltalk proved that a long time before JS did. (Heck, back when it was maintained, the fastest Ruby implementation was built on top of a commercial Smalltalk system, which makes sense given they have a reasonably similar model.) The hard part is that “enough money“ is...not a given, especially for noncommercial projects. JS got it because Google decided JavaScript speed was integral to it's business of getting the web to replace local apps. Microsoft recently developed sufficient interest in Python to throw some money at it.
  - tambourine_man 4y ago
    Yes, I’m aware of the Smalltalk miracle. Google wasn’t alone in optimizing JS, it actually came late, Safari and Firefox were already competing and improving their runtime speeds, though V8 did doubled down on the bet of a fast JS machine. The question is why there isn’t enough money, given that there obviously is a lot of interest from big players.
    - dragonwriter 4y ago
      > The question is why there isn’t enough money, given that there obviously is a lot of interest from big players. I'd argue that there wasn't actually much interest until recently, and that's because it is only recently that interest in the CPython ecosystem has intersected with interest in speed that has money behind it, because of the sudden broad relevance to commercial business of the Python scientific stack for data science. Both Unladen Swallow and IronPython were driven by interest in Python as a scripting language in contexts detached from, or at least not necessarily attached to, the existing CPython ecosystem.
Sesse__ 4y ago
Because Guido van Rossum just isn't very good with performance, and when others tried to contribute improvements, he started heckling their talk because he thought they were “condescending”: https://lwn.net/Articles/754163/ https://lwn.net/Articles/754163/ And by this time, we've come to the point where the Python extension API is as good as set in stone. Note that all of the given benchmarks are microbenchmarks; the gains in 3.11 are _much_ less pronounced on larger systems like web frameworks.
- LtWorf 4y ago
  Yeah breaking compatibility kills a language. He did the right thing.
  - gpderetta 4y ago
    yet breaking compatibility in the 2->3 transition so that we can use print in lambdas was perfectly fine.
    - LtWorf 4y ago
      People learn from mistakes
emmelaich 4y ago
Perhaps they took a lesson from Perl; its code base was so complex as to be near unmaintainable. In addition to the other point here about speed not being a target in the first place.

gfd 4y ago

Did anyone try running this benchmark with other python implementations? (Pypy etc)

pen2l 4y ago
Too many things with Pypy (and other supposedly faster implementations) don't work, so it's a no-go for a lot of projects to begin with. In the last 10 years, I looked into pypy I think three or four times to speed things up, it didn't work even once. (I don't remember exactly what it was that didn't play nice... but I'm thinking it must have been pillow|numpy|scipy|opencv|plotting libraries).

londons_explore 4y ago

This looks like incremental performance work rather than a ground-up new approach, like an optimising compiler or JIT...

int_19h 4y ago
Python JITs were tried before, more than once. The usual problem there is that the gains are very modest unless you can also break the ABI for native modules. But if you do the latter, most users won't even bother with your version.
- cglace 4y ago
  I believe a JIT is planned for 3.12

imwillofficial 4y ago

That’s wild, do we typically see such gains in dot releases? I don’t remember the last time this happened. Great news.

dagmx 4y ago
Programming language dot releases can tend to be significant. Semver often means that major is the language version, and minor is the runtime version
- luhn 4y ago
  To nitpick a little bit, Python does not follow semver and does not claim to follow semver. Minor versions are mostly backwards compatible, but do include breaking changes.
dswalter 4y ago
Python dot releases are significant releases. Perhaps you recall the last python integer version number change? As a result, it will be quite some time before we see a version 4.
wheelerof4te 4y ago
Python's versioning has been misleading ever since 3.0 shipped. There was a heap of features added between 3.5 and 3.11, for example. Enough to make it a completely different language.

tasubotadas 4y ago

Cool improvement but changes very little when Python is x100 times slower than other GC languages.

woodruffw 4y ago
This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)
- TuringTest 4y ago
  > 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.) And that's even assuming that the code would have existed at all in another language. The thing about interpreted GC languages is that the iterative loop of creation is much more agile, easier to start with and easier to prototype in than a compiled, strictly typed language.
  - z3c0 4y ago
    I think this is the best explanation for its popularity. Sure, it runs slow, but it's very fast to write. The latter is usually more important in the world of business, for better or worse.
    - jonnycomputer 4y ago
      The majority of code I write, the efficiency of the code is mostly a secondary concern; it will be run only a few times at most, and the fact that its a a few 1000 times slower than something written in C or C++ means waiting a few more seconds (at most) for my results. Most of my time spent is writing it, not running it.
    - toyg 4y ago

woodruffw 4y ago

This is really incredible work. The "What's New" page has an item-by-item breakdown of each performance tweak and its measured effect[1]. In particular, PEP 659 and the call/frame optimizations stand out to me as very clever and a strong foundation for future improvements. [1]: https://docs.python.org/3.11/whatsnew/3.11.html https://docs.python.org/3.11/whatsnew/3.11.html

deleted 4y ago
[deleted]

ineedasername 4y ago

If it's 25% faster then the point versions should be (rounded) 3.88.

sod 4y ago

I wish there was something like llvm for scripting languages. Imagine if python, php, javascript, dart or ruby would not interpret the code themself, but compile to an interpretable common language, where you could just plug in the fastest interpreter there is for the job.

jacobn 4y ago
JVM and GraalVM? https://www.graalvm.org/ https://www.graalvm.org/
MarkSweep 4y ago
The RPython language PyPy is written in is designed to enable writing JIT-compiled interceptors for any language: https://rpython.readthedocs.io/en/latest/ https://rpython.readthedocs.io/en/latest/ There is also the Dynamic Language Runtime, which is used to implement IronPython and IronRuby on top of .NET: https://en.wikipedia.org/wiki/Dynamic_Language_Runtime https://en.wikipedia.org/wiki/Dynamic_Language_Runtime
- adsharma 4y ago
  rpython is designed to write new interpreters. Not aware of many apps written in the rpython dialect. There are bunch of transpilers which might provide a path from statically typed python3 to native binaries. py2many is one of them. The downside is that all of the C extensions that python3 uses become unusable and need to be rewritten in the subset of python3 that the transpiler accepts.
Aperocky 4y ago
That's why they are called scripting languages.
chickenpotpie 4y ago
Webassembly can fulfill that requirement for certain use cases
- cmrdporcupine 4y ago

alexfromapex 4y ago

One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.

bilsbie 4y ago
When is that coming? Yes the error messages are confusing in a big list comprehension.
- alexfromapex 4y ago
  Will be in the 3.11 release: https://docs.python.org/3.11/whatsnew/3.11.html#new-features https://docs.python.org/3.11/whatsnew/3.11.html#new-features
- teekert 4y ago
  Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.
  - 8organicbits 4y ago
    "Debugging is twice as hard as writing the code in the first place. Therfore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Rajanand Although, personally, I enjoy python list comprehensions.
    - timoteostewart 4y ago
      I believe that quote about debugging being twice as hard as coding is by Brian Kernighan. https://en.m.wikiquote.org/wiki/Brian_Kernighan https://en.m.wikiquote.org/wiki/Brian_Kernighan
      - 8organicbits 4y ago

bilsbie 4y ago

I’d be curious to see the speed up compared to python 2.4. To see how far it’s come since I first got started with it.

upupandup 4y ago
it means you are not following PEP8 if you get non descriptive errors, it means you haven't followed proper exception handling/management its not the fault of Python but the developer. go ahead and downvote me but you if you mentioned parent's comment in an interview, you would not receive a call back or at least I hope the interviewer is realizing the skill gap.
- bilsbie 4y ago
  How so?
- d23 4y ago
  I think this is both insulting and not even responding to the right comment.
- uoaei 4y ago
  Ah yes, the "why make things easier when you could do things the hard way" argument.

anewpersonality 4y ago

What happened to multithreaded Facebookthon?

s9w 4y ago

12ms to 6ms is not 2xfaster. It's 1x faster or 2 times as fast

IceHegel 4y ago

Next we need some standardization around package management. I recently tried installing the Metal optimized pytorch and descended into package and Python path hell.

tandav 4y ago
Just use conda or docker

deleted 4y ago

[deleted]

superjan 4y ago

Yesterday, I watched Emery Berger’s “Python performance matters” Which is you should not bother to write fast Python, just delegate all heavy lifting to optimized C/c++ and the likes. His group has a Python profiler whose main goal is to point out which parts should be delegated. Of course optimized is better but the numeric microbenchmarks in this post are mostly examples of code that is better delegated to low overhead compiled languages. https://youtu.be/LLx428PsoXw https://youtu.be/LLx428PsoXw

wheelerof4te 4y ago
The key wording is "optimized C". CPython is already executed in pure C, the only difference it being a very slow, unoptimized C. The code for simple adding of two numbers is insane. It jumps through enough hoops to make you wonder how is it even running everything else.
ModernMech 4y ago
> you should not bother to write fast Python, just delegate all heavy lifting to optimized C/c++ and the likes Certainly that's something you can do, but unfortunately for Python it opens the door for languages like Julia, which are trying to say that you can have your cake and eat it too.
- galangalalgol 4y ago
  I like Julia but its easy to write slow julia unless you keep the performance tips in mind. Arrays are horribly slow, tuples are much faster, but having tuples be a multiple of 128 bytes adds 10% or more to speed. I honestly don't understand how much slower arrays are. Its like 30x or similar.
  - jolux 4y ago
    That’s bizarre, are they implemented as linked lists or something? Why would arrays be that slow?
    - 4y ago

antman 4y ago

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part. If anyone more knowledgable can review this and give some feedback I think will be here in HN

didip 4y ago
I agree, please don't just accept the optimization and sweep the GIL removal under the rug again.
nmstoker 4y ago
I think you mean the work by Sam Gross: https://github.com/colesbury/nogil/ https://github.com/colesbury/nogil/ Interesting article about it here: https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/ https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...
BerislavLopac 4y ago
The GIL removal by that guy reverted some of the improvement done by other optimisations, so the overall improvement was much smaller. And most people do care for single-threaded speed, because the vast majority of Python software is written as single-threaded.
- metadat 4y ago
  > the vast majority of Python software is written as single-threaded. This is a self-fulfilling prophecy, as the GIL makes Python's (and Ruby's) concurrency story pretty rough compared to nearly all other widely used languages: C, C++, Java, Go, Rust, and even Javascript (as of late).
  - SiempreViernes 4y ago
    Pretty sure it is actually a statement that comes from the "python is a scripting language" school, and not because the huge horde of programmers that craves concurrency when they write a script to reformat a log file to csv keeps being put off by the python multiprocessing story.

8organicbits 4y ago

Is this speed a feature of python now, or is this performance something that could regress in future if needed for a different feature? As in, will python continue to run this fast (or faster)?

EnKopVand 4y ago
I think it’s hard to answer your question. The development mentality of Python seems to have changed a little, going into 3.11, and you see sort of a shift in the priority of clean vs fast. I think you can assume that Python will continue to care about speed, but really, it sort of always has. Just like it’s going to continue to care about clean implementation. Then there is the part where Python will likely never become a “fast” language in the sense that C is a fast language, but the flip side of this is that Python was probably already fast enough for most uses. I tend to like to use the “we aren’t Netflix” or the “stackoverflow runs on IIS and always has” arguments when it comes to worrying about speed in anyone who isn’t Netflix, but that doesn’t really apply to Python since the backend of Instagram is django, and if Python can power Instagram then it’s probably fast enough for you, unless you’re already working with C/C++/Rust and know exactly why you are working with those. I know I’m a bit more focused on the business side of things than a lot of techies here on HN, it’s a curse and a gift, but what I read the 10-60% speed increase as is money. The less resources you consume, the less money you burn. Which is really good news for Python in general, because it makes it more competitive to languages like C# for many implementations. This comes from the perspective of someone who actually things running Typescript on your backend is a good idea because it lets you share developer resources easier so that the people who are really good at react can cover for the people who are really good at the backend and the other way around in smaller teams in non-software-engineering organisations.

mixmastamyk 4y ago

There have been a number of release blockers recently, and growing even as others fixed: https://mail.python.org/archives/list/python-dev@python.org/thread/7AT3YTUJOYMZI4VNMSJ42BE6ZNR7GANM/ https://mail.python.org/archives/list/python-dev@python.org/... Folks not desperate for the improvements might want before jumping in.

cercatrova 4y ago

Somewhat related, had anyone used Nim? These days I've been using it for its Python like syntax year C like speed, especially if I just need to script something quickly.

objektif 4y ago
Is it worth it to learn? Especially when you have python?
- cercatrova 4y ago
  Yeah it's a nice language, it has optional static types as well which is always a plus in my experience. The speed though is what's really interesting.
int_19h 4y ago
The problem with any new language is libraries and tooling.
- cercatrova 4y ago
  I use it for scripting mainly when I don't need Python specific libraries like pandas. The tooling is pretty good as well.
  - moffkalast 4y ago
    Seems like just going with bash would be more straightforward?
    - cercatrova 4y ago
      Why would I want to subject myself to writing in a language like bash? Bash has many disadvantages compared to Python, Nim, Go, nearly anything that isn't brainfuck.
      - 4y ago

rhabarba 4y ago

If performance is relevant to you, Python is the wrong language for you.

catskul2 4y ago
If you think this is the kind of statement that it's possible to make, software might be the wrong field for you.

sandGorgon 4y ago

is this project sponsored by microsoft ? it seems that the devs in the github org all work for microsoft

korijn 4y ago
Yes

bergenty 4y ago

I just learned today that python is 100x slower than C. I have severely lost respect for python.

deleted 4y ago
[deleted]
StevePerkins 4y ago
If you just learned this today, then HN has severely lost respect for you! lol
- bergenty 4y ago
  Yes it’s deserved but I’ve been in management for a while.
  - aunty_helen 4y ago
    From your perspective then, python is 100x faster than c
    - bergenty 4y ago
      We don’t use python but you’re very articulate, Helen.
calibas 4y ago
C is faster than Python, but it's much more nuanced than saying Python is "100x slower". Try writing a program to open and parse a CSV file line by line in both languages. You'll see why people like Python. Also, because of FFI, it's not like the two languages are opposed to each other and you have to choose. They can happily work together.
4gotunameagain 4y ago
And oranges contain 10x the vitamin C of apples :)

ttul 4y ago

Guido’s group at Microsoft have been busy.

pineapplejuice 4y ago

Is there a website which tracks which of the major libraries; pandas, requests, django, etc support each major version? I remember there was one years ago for python 3.6? Been a long time!

robertlacok 4y ago
I think this is what you’re looking for: https://pyreadiness.org/3.11/ https://pyreadiness.org/3.11/
- pineapplejuice 4y ago
  Thanks!

truth_seeker 4y ago

It's good but not good enough.

michaelcampbell 4y ago

This use of "faster" in the text; I think they mean "as fast". "1x faster" to me says twice the speed of the original, but I believe they use it to mean "the same speed".

smcl 4y ago
That's not actually a bad observation even though you were downvoted. I think in the end it's technically ambiguous but most people would be able to see what is meant especially given the previous performance is present (i.e. for benchmark "deltablue" we have columns "12.4 ms" and "6.35 ms (1.96x faster)". But you're right, I think "1.96x as fast" sounds more correct. edit: but now that I think about it "X as fast" or "X faster" in terms of a duration will always sound a bit weird
- michaelcampbell 4y ago
  It's an OCD pet peeve of mine. Worse yet is "2x slower!" To me, 1x slower is "stopped". I know they MEAN "1/2 the speed", but it still bugs me.
  - smcl 4y ago
    Oh that's like the US thing of saying something as "10 times less than ..." rather than "one tenth of ..."
    - michaelcampbell 4y ago
      Exactly that. I'm in the US and see it, but didn't know it was a US "thing". But yes, that.
      - smcl 4y ago
        It could also just be a new thing for English overall that I've associated more with the USA because I listen to or watch a lot of American podcasts, videos and streamers. I'm not the type who gets worked up at American vs British English :-)