10 ms·

State of Python 3.13 performance: Free-threading

196 points by art049 2y ago

deleted 2y ago
[deleted]
eigenspace 2y ago
I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "real" semantics. On the other hand, a lot of these changes to try and speed up the base language are going to be highly disruptive. E.g. disabling the GIL will break tonnes of code, lots of compilation projects involve changes to the ABI, etc. I guess getting loops in Python to run 5-10x faster will still save some people time, but it's also never going to be a replacement for the zoo of specialized python-like compilers because it'll never get to actual high performance territory, and it's not clear that it's worth all the ecosystem churn it might cause.
- willvarfar 2y ago
  (As a happy pypy user in previous jobs, I want to chime in and say python _can_ be fast. It can be so fast that it completely mooted the discussions that often happen when wanting to move from a python prototype to 'fast enough for production'.)
  - eigenspace 2y ago
    PyPy is still slow compared to actual fast languages. It's just fast compared to Python, and it achieves that speed by not being compatible with most of the Python ecosystem. Seems like a lose-lose to me. (which is presumably why it never caught on)
    - rowanG077 2y ago
      What isn't compatible with PyPy? I can run large frameworks using pypy no problem. There certainly will be package that aren't compatible. But far and away most of the ecosystem is fully comaptible.
      - artemisart 2y ago
        This depends a lot on your domain, e.g. pypy is not compatible with pytorch or tensorflow so DL is out of the picture.
- rmbyrro 2y ago
  Python 3.12 will be officially supported until October 2028, so there's plenty of time to migrate to no-GIL if anyone wants to.
  - zurfer 2y ago
    Python 3.13 is not removing the GIL. You just have an option to run without it.
- the__alchemist 2y ago
  This is a good question, and I think about it as well. My best guess for a simple explanation: Python is very popular; it makes sense to improve performance for python users, given many do not wish to learn to use a more performant language, or to use a more performant Python implementation. Becoming proficient in a range of tools so you can use the right one for the right job is high enough friction that it is not the path chosen by many.
  - eigenspace 2y ago
    Oh yeah, I totally get the motivation behind it. It's always very tempting to want to make things faster. But I can't help but wondering if these attempts to make it faster might end up just making it worse. On the other hand though, Python is so big and there's so many corps using it with so much cash that maybe they can get away with just breaking shit every few releases and people will just go adapt packages to the changes.
    - dagmx 2y ago
      Python famously has a community that does NOT adapt to changes well. See the Python 2 to 3 transition.
      - eigenspace 2y ago
        Python's community was significantly smaller and less flushed with cash during the 2 to 3 transition. Since then there has been numerous 3.x releases that were breaking and people seem to have been sucking it up and dealing with it quietly so far. The main thing is that unlike the 2 to 3 transition, they're not breaking syntax (for the most part?), which everyone experiences and has an opinion on, they're breaking rather deep down things that for the most part only the big packages rely on so most users don't experience it much at all.
        dagmx 2y ago
        I disagree with this entire comment. The Python community consisted of tons of developers including very wealthy companies. At what point in the last few years would you even say they became “rich enough” to do the migration? Because people are STILL talking about trying to fork 2.7 into a 2.8. I also disagree with your assertion that 3.x releases have significant breaking changes. Could you point to any specific major breaking changes between 3.x releases? 2 to 3 didn’t break syntax for most code either. It largely cleaned house on sensible API defaults.
- sneed_chucker 2y ago
  If JavaScript (V8) and PyPy can be fast, then CPython can be fast too. It's just that the CPython developers and much of the Python community sat on their hands for 15 years and said stuff like "performance isn't a primary goal" and "speed doesn't really matter since most workloads are IO-bound anyway".
  - jerf 2y ago
    In this context, V8 and PyPy aren't fast. Or at least, not generally; they may actually do well on this task because pure number tasks are the only things they can sometimes, as long as you don't mess them up, get to compiled language-like performance. But they don't in general to compiled language performance, despite common belief to the contrary.
    - Spivak 2y ago
      Let's make this more concrete because assigning speed to languages is a fools errand. Python is doing a lot more per line of code than compiled languages to enable its very flexible semantics. In cases where this flexibility is desired you won't see much more performance in a compiled language as you'll have just implemented Python-like semantics on top of your compiled language— GObject is a good example of this. More famously this is Greenspun's tenth rule. > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. But where this flexibility isn't required, which is a lot of performance sensitive number crunching code the cost of the flexibility bites you. You can't "turn it off" when you want control down to the instruction for a truly massive performance win. Which is why I think the model Python has of highly expressive and flexible language backed by high-performance compiled libraries is so successful. Python will never be number crunching or parsing with the best of them because it would require essentially a whole new language to express the low-level constraints but for high-level code that relies on Python's semantics you can get performance wins that can't be accomplished just by switching to a compiled language. We've just taken the "embedded scripting language" and made it the primary interface.
    - adamc 2y ago
      This gets into the whole "fast for what purpose" discussion. For many purposes, JavaScript is quite acceptably fast. But it isn't C or Rust.
- wormlord 2y ago
  > On the other hand, a lot of these changes to try and speed up the base language are going to be highly disruptive. E.g. disabling the GIL will break tonnes of code, lots of compilation projects involve changes to the ABI, etc. Kind of related, the other day I was cursing like a sailor because I was having issues with some code I wrote that uses StrEnum not working with older versions of Python, and wondering why I did that, and trying to find the combination of packages that would work for the version of Python I needed-- wondering why there was so much goddamn churn in this stupid [expletive] scripting language. But then I took a step back and realized that, actually, I should be glad about the churn because it means that there is a community of developers who care enough about the language to add new features and maintain this language so that I can just pipe PyQt and Numpy into each other and get paid. I don't have any argument, just trying to give an optimistic perspective.
  - d0mine 2y ago
    At least bugfix versions could have kept Enum behavior the same. Postponing breaking changes until the next minor version. Some Enum features work differently (incompatible) in Python 3.11.x versions.
    - wormlord 2y ago
      > Some Enum features work differently (incompatible) in Python 3.11.x versions. I wasn't aware of that, that's actually insane. It's odd to me that it took so long to get f-strings and Enums right in Python, I assumed those would be pretty easy language features to implement.
    - roelschroeven 2y ago
      > Some Enum features work differently (incompatible) in Python 3.11.x versions. I know that Python 3.11 added some things, like StrEnum; those obviously won't work on older Python versions. But I'm not aware of things that work in a certain Python 3 version but don't work in newer ones. You're even talking about incompatibilities between different 3.11.x versions? Can you give some more detail on that?
- yunohn 2y ago
  > I guess getting loops in Python to run 5-10x faster will still save some people time I would recommend being less reductively dismissive, after claiming you “don’t really have a dog in this race”. Edit: Lots of recent changes have done way more than just loop unrolling JIT stuff.
- Capricorn2481 2y ago
  I don't really get this. They have already made Python faster in the past while maintaining the same semantics. Seems like a good goal to me.
- andai 2y ago
  There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experiences trying to get older code with dependencies running. My meaning with this comment is, that if the average developer's reality is that backwards compatibility isn't really a thing anyway, then we are already paying for that downside so we might as well get some upside there, is my reasoning.
  - almostgotcaught 2y ago
    > I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). ... > I wrote last year and it turned out that a bunch of my dependencies had changed their APIs these two things have absolutely nothing to do with each other - couldn't be a more apples to oranges comparison if you tried
    - andai 2y ago
      I ran into both of these things in the same context, which is "the difficulty involved in getting old code working on the latest Python environment", which I understood as the context of this discussion.
  - klysm 2y ago
    So pin your deps? Language backwards compatibility and an API from some random package changing are completely distinct.
    - epistasis 2y ago
      Pinning deps is discouraged by years of Python practice. And going back to a an old project and finding versions that work, a year or more later, might be nigh on impossible. Last week I was trying to install snakemake via Conda, and couldn't find any way to satisfy dependencies at all, so it's not just pypi, and pip tends to be one of the more forgiving version dependency managers. It's not just Python, trying to get npm to load the requirements has stopped me from compiling about half of the projects I've tried to build (which is not a ton of projects). And CRAN in the R universe can have similar problems as projects age.
- jillesvangurp 2y ago
  Why does python have to be slow? Improvements over the last few releases have made it quite a bit faster. So that kind of counters that a bit. Apparently it didn't need to be quite as slow all along. Other languages can be fast. So, why not python? I think with the GIL some people are overreacting: most python code is single threaded because of the GIL. So removing it doesn't actually break anything. The GIL was just making the use of threads kind of pointless. Removing it and making a lot of code thread safe benefits people who do want to use threads. It's very simple. Either you did not care about performance anyway and nothing really changes for you. You'd need to add threading to your project to see any changes. Unless you do that, there's no practical reason to disable the GIL for you. Or to re-enable that once disabled becomes the default. If your python project doesn't spawn threads now, it won't matter to you either way. Your code won't have deadlocking threads because it has only 1 thread and there was never anything to do for the GIL anyway. For code like that compatibility issues would be fairly minimal. If it does use threads, against most popular advise of that being quite pointless in python (because of the GIL), you might see some benefits and you might have to deal with some threading issues. I don't see why a lot of packages would break. At best some of them would be not thread safe and it's probably a good idea to mark the ones that are thread safe as such in some way. Some nice package management challenge there. And probably you'd want to know which packages you can safely use.
  - eigenspace 2y ago
    > Why does python have to be slow? Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc. The list of stuff like this goes on and on and on. You fundamentally just cannot compile most python programs to efficient machine code without making (sometimes subtle) changes to its semantics. _________ > I don't see why a lot of packages would break. At best some of them would be not thread safe and it's probably a good idea to mark the ones that are thread safe as such in some way. Some nice package management challenge there. And probably you'd want to know which packages you can safely use. They're not thread safe because it was semantically guaranteed to them that it was okay to write code that's not thread safe.
- rfoo 2y ago
  > Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible Scientific computing community have a bunch of code calling numpy or whatever stuff. They are pretty fast because, well, numpy isn't written in Python. However, there is a scalability issue: they can only drive so many threads (not 1, but not many) in a process due to GIL. Okay, you may ask, why not just use a lot of processes and message-passing? That's how historically people work around the GIL issue. However, you need to either swallow the cost of serializing data over and over again (pickle is quite slow, even it's not, it's wasting precious memory bandwidth), or do very complicated dance with shared memory. It's not for web app bois, who may just write TypeScript.
  - eigenspace 2y ago
    Numpy is not fast enough for actual performance sensitive scientific computing. Yes threading can help, but at the end of the day the single threaded perf isn't where it needs to be, and is held back too much by the python glue between Numpy calls. This makes interproceedural optimizations impossible. Accellerated sub-languages like Numba, Jax, Pytorch, etc. or just whole new languages are really the only way forward here unless massive semantic changes are made to Python.
    - rfoo 2y ago
      These "accelerated sub-languages" are still driven by, well, Python glue. That's why we need free-threading and faster Python. We want the glue to be faster because it's currently the most accessible glue to the community. In fact, Sam, the man behind free-threading, works on PyTorch. From my understanding he decided to explore nogil because GIL is holding DL trainings written in PyTorch back. Namely, the PyTorch DataLoader code itself and almost all data loading pipelines in real training codebases are hopeless bloody mess just because all of the IPC/SHM nonsense.
  - willseth 2y ago
    This is misleading. Most of the compute intensive work in Numpy releases the GIL, and you can use traditional multithreading. That is the case for many other compute intensive compiled extensions as well.
- ggm 2y ago
  You may be right. I personally think this work is net beneficial, and although I never expected to be in MP or threads, I now find doing a lot of DNS (processing end of day logs of 300m records per day, trying to farm them out over public DNS resolvers doing multiple RR checks per FQDN) that the MP efficiency is lower than threads, because of this serialisation cost. So, improving threading has shown me I could be 4-5x faster in this solution space, IFF I learn how to use the thread.lock to gatekeep updates on the shared structures. My alternative is to serialise in heavy processes and then incur a post process unification pass, because the cost of serialise send/receive deserialise to unify this stuff is too much. If somebody showed me how to use shm models to do this so it came back to the cost of threading.lock I'd do the IPC over a shared memory dict, but I can't find examples and now suspect multiprocessing in Python3 just doesn't do that (happy, delighted even to be proved wrong)
- nickpsecurity 2y ago
  I spent some time looking into it. I believe it could be done with a source-to-source transpiler with zero-cost abstractions and some term rewriting. It’s a lot of work. The real barrier my thought experiment hit were the extensions. Many uses of Python are glue around C extensions designed for the CPython interpreter. Accelerating “Python” might actually be accelerating Python, C, and hybrid code that’s CPython-specific. Every solution seemed like more trouble than just rewriting those libraries to not be CPython-specific. Or maybe to work with the accelerators better. Most people are just using high-level C++ and Rust in the areas I was considering. If using Python, the slowdown of Python doesn’t impact them much anyway since their execution time is mostly in the C code. I’m not sure if much will change.
- runeblaze 2y ago
  For machine learning (un)fortunately, lots of the stack runs on Python. Lots of ceremony was done to circumvent GIL (e.g. PyTorch data loader). “Reasonable performance Python” I imagine is actually something in huge demand for lots of ML shops
- emgeee 2y ago
  One area where this absolutely makes a difference is when embedding python. Like it or not Python is extreme popular in data/AI/ML so if you want to build an experience where users can deploy custom functions, removing the GIL allows you to more efficiently scale these workloads.
- pjmlp 2y ago
  Since Python has become the new Lisp, the minimum is to have the performance tooling Common Lisp has had for several decades, in native code generation and multithreading (yes I know that in CL this is implementation specific).
- cma 2y ago
  How about when there are 128-256 core consumer CPUs?
  - lanstin 2y ago
    And people are running things that take minutes to run when a good multi-cpu framework would make it seconds. Maybe add a dataflow analyzer to Python and do it for people.
- 6gvONxR4sf7o 2y ago
  > so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "real" semantics. I don't even understand what this means. If I write `def foo(x):` versus `def foo(x: int) -> float:`, one is a restricted subset of the other, but both are the language's "real" semantics. Restricted subsets of languages are wildly popular in programming languages, and for very varied reasons. Why should that be a barrier here? Personally, if I have to annotate some of my code that run with C style semantics, but in return that part runs with C speed, for example, then I just don't really mind it. Different tools for different jobs.
  - almostgotcaught 2y ago
    > If I write `def foo(x):` versus `def foo(x: int) -> float:`, one is a restricted subset of the other, but both are the language's "real" semantics. You either are performing some wordplay here or you don't understand but type hints are not part of the semantics at all: since they are not processed at all they do not affect the behavior of the function (that's what semantics means). EDIT: according to the language spec and current implementation `def foo(x: int) -> float` and `def foo(x: float) -> int` are the same exact function
    - movpasd 2y ago
      That's not strictly true -- type annotations are accessible at runtime (that's how things like dataclasses and pydantic work).
- lijok 2y ago
  Given the scale at which python is run, how much energy are we saving by improving its performance by 1%?
- PaulHoule 2y ago
  As a Java dev I think people don’t always appreciate the flexiblity of threads for manage parallelism, concurrency, and memory. In particular with threads you can have a large number of thread share a large data structure. Say you have an ML inference model that takes 1GB of RAM. No way can you let 25 Celery workers each have a copy of that model, so if you are using Python you have to introduce a special worker class. It’s one more thing to worry about and more parameters to tune. With Java all your “workers” could be in one process, even the same process as your web server and that will be the case in Python. Threads break down so many bottlenecks of CPU resources, memory, data serialization, waiting for communications, etc. I have a 16-core computer on my desk and getting a 12x speed-up is possible for many jobs and often worth worse less efficient use of the individual CPU. Java has many primitives for threads that include tools for specialized communications (e.g. barrier synchronization) that are necessary to really get those speed-ups and I hope Python gets those too.
- Someone 2y ago
  I think the reasoning is like this: - People choose Python to get ease of programming, knowing that they give up performance. - With multi-core machines now the norm, they’re relatively giving up more performance to get the same amount of ease of programming. - so, basically, the price of ease of programming has gone up. - economics 101 is that rising prices will decrease demand, in this case demand for programming in Python. - that may be problematic for the long-term survival of Python, especially with new other languages aiming to provide python’s ease of use while supporting multi-processing. So, Python must get even easier to use and/or it must get faster.
- graemep 2y ago
  I do use Python and I am not that bothered about speed. Very little of what I use it for has performance bottlenecks in the Python. Its the database or the network or IO or whatever. On the few occasions when it does I can rewrite critical bits of code. I definitely care more about backward compatibility than I do about performance. It feels like Python development is being driven by the needs of one particular group (people who use ML heavily, possibly because they have deep pockets) and I wonder whether this, and a few other things will make it less attractive a language for me and others.
  - winrid 2y ago
    Your DB is probably faster than you think. I rewrote an API in Python to Java and it is around 6x faster with just same dumb N+1 queries, and the new API also includes all the frontend calculations that Python wasn't doing before.
- DeathArrow 2y ago
  >Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "real" semantics. Have you heard of Mojo? It is a very performant superset of Python. https://www.modular.com/mojo https://www.modular.com/mojo
  - pansa2 2y ago
    Mojo isn’t anywhere near a superset of Python. It doesn’t even support classes!
- otabdeveloper4 2y ago
  Parallelism != speed. If you have 128 cores you can compromise on being a bit slow. You can't compromise on being single-threaded though.
  - lanstin 2y ago
    And for the code running on the 128 core machine, which is not really rare these days, for that code to be pythonic, it should be dead simple to use all the cores in the obvious correct way. We have language features that enable simple multiple semantics but haven't yet got the easy way to do it. MP has the stupid serialization issues and anything involving the Python coder doing locking or mutexes is not Pyrhinic as they will struggle.
- Netcob 2y ago
  I was experimenting with Python for some personal data-based project. My goal was to play around with some statistics functions, maybe train some models and so on. Unfortunately most of my data needs a lot of preprocessing before it will be of any use to numpy&co. Mostly just picking out the right objects from a stream of compressed JSON data and turning them into time series. All of that is easy to do in Python, which is what I'd expect for the language used this much in data science (or so I've heard). But then I do have a lot of data, there's a lot of trial&error there for me so I'm not doing these tasks only once, and I would have appreciated a speedup of up to 16x. I don't know about "high performance", but that's the difference between a short coffee break and going to lunch. And if I was a working on an actual data-oriented workstation, I would be using only one of possibly 100+ cores. That just seems silly to me.
- ogrisel 2y ago
  The IPC overhead of process-based parallelism in Python is a pain to deal with in general, even when the underlying computational bottleneck are already written CPU optimized (calls to compiled extensions written in Cython/C/C++/Rust, call to CPU optimized operations written with CPU architecture-specific intrinsics/assembly from OpenBLAS via NumPy/SciPy, calls to e.g. GPU CUDA kernels via PyTorch/Triton, ...). Sometimes the optimal level of parallelism lies in an outer loop written in Python instead of just relying on the parallelism opportunities of the inner calls written using hardware specific native libraries. Free-threading Python makes it possible to choose which level of parallelism is best for a given workload without having to rewrite everything in a low-level programming language.
- kevincox 2y ago
  Even if something is slow there is utility to have it run faster. Sure, Python will never be with for the most demanding performance requirements but that doesn't mean we should deny people performance. There are lots of use case where Python's performance is acceptable but a 10x speed boost would be much appreciated. Or where Python's performance is not acceptable but it would be if I could fully utilize my 32 cores. For example look at Instagram. They run tons of Python but need to run many processes on each machine wasting memory. I'm sure they would love to save that memory, the environment would too. Sure, they could rewrite their service in C but that is most likely not the best tradeoff.
- zelphirkalt 2y ago
  I am always wondering who writes code so badly unaware of concurrency issues, to rely on the GIL. Wondering how many libraries and programs will actually break. But probably the number is way higher than even I imagine.
  - ogrisel 2y ago
    The race condition bugs are typically hidden by different software layers. For instance, we found one that involves OpenBLAS's pthreads-based thread pool management and maybe its scipy bindings: - https://github.com/scipy/scipy/issues/21479 https://github.com/scipy/scipy/issues/21479 it might be the same as this one that further involves OpenMP code generated by Cython: - https://github.com/scikit-learn/scikit-learn/issues/30151 https://github.com/scikit-learn/scikit-learn/issues/30151 We haven't managed to write minimal reproducers for either of those but as you can observe, those race conditions can only be triggered when composing many independently developed components.
- stevofolife 2y ago
  Can you help me understand, if libraries like pandas and numpy also applies to your comment? Or are they truely optimized and you’re just referring to the standard Python language?
ijl 2y ago
Performance for python3.14t alpha 1 is more like 3.11 in what I've tested. Not good enough if Python doesn't meet your needs, but this comes after 3.12 and 3.13 have both performed worse for me. 3.13t doesn't seem to have been meant for any serious use. Bugs in gc and so on are reported, and not all fixes will be backported apparently. And 3.14t still has unavoidable crashes. Just too early.
- bastawhiz 2y ago
  > 3.13t doesn't seem to have been meant for any serious use. I don't think anyone would suggest using it in production. The point was to put something usable out into the world so package maintainers could kick the tires and start working on building compatible versions. Now is exactly the time for weird bug reports! It's a thirty year old runtime and one of its oldest constraints is being removed!
- kristianp 2y ago
  > 3.12 and 3.13 have both performed worse for me That's interesting, I wouldn't have expected performance regressions coming from those releases. How can that be?
refdl 2y ago
[flagged]
- kmeisthax 2y ago
  > people are kept in line with CoC threats Can you point to an example of someone claiming that a particular feature's performance claims were misleading, and then getting threatened with a ban or other sanctions for it, where they did not otherwise violate CoC?
  - pwdisswordfishz 2y ago
    > where they did not otherwise violate CoC? Violations are in the eye of the enforcer.
- notatallshaw 2y ago
  You seem to be conflating problems and different groups of people that aren't directly related. To clarify some different groups: * The faster-cpython project, headed by Guido and his team at Microsoft, is continuing fine, most of the low hanging fruit was accomplished by 3.11, further improvements were moved to medium term goals and they were delayed further by the free threaded project which broke assumptions that were made to optimize CPython, they have adapted but it has pushed big optimizations out to later released (think probably 3.15ish) * The free threaded project, initiated by Sam Gross at Meta, is continuing fine, it was never intended to be ready by 3.13, the fact there is even a build officially published is very fast progress. There isn't yet a plan to make it default, depending on the compatibility of the free threaded build it could be a quick transition or a 5+ year switch over. * The PSF, the Steering Council, and the CoC WG are all different groups that have different responsibilities and aren't typically involved in day-to-day choices of committing certain features. * The release manager is a core developer in charge of making the final choice on whether a particular feature is stable or not. It was the 3.13 release manager who decided to revert the new GC which was intended to generally improve performance for non-free threaded builds, which it may still do in a future release with sufficient fine tuning. Now, there are clearly communication issues in areas of the Python community, but there is also a lot of people getting on with great work and improvements and communicating fine.
runjake 2y ago
If it were ever open sourced, I could see Mojo filling the performance niche for Python programmers. I'm hopeful because Lattner certainly has the track record, if he doesn't move on beforehand. https://en.wikipedia.org/wiki/Mojo_(programming_language) https://en.wikipedia.org/wiki/Mojo_(programming_language)
- qaq 2y ago
  https://github.com/modularml/mojo/blob/main/LICENSE https://github.com/modularml/mojo/blob/main/LICENSE
  - kaanyalova 2y ago
    The source code for the compiler hasn't released yet
- misswaterfairy 2y ago
  If not, Nim is probably the closest most 'Python-like' language that is almost as fast as C, and is released under the MIT licence. https://nim-lang.org/ https://nim-lang.org/ https://en.wikipedia.org/wiki/Nim_(programming_language) https://en.wikipedia.org/wiki/Nim_(programming_language)
Decabytes 2y ago
I'm glad the Python community is focusing more on CPython's performance. Getting speed ups on existing code for free feels great. As much as I hate how slow Python is, I do think its popularity indicates it made the correct tradeoffs in regards to developer ease vs being fast enough. Learning it has only continued to be a huge benefit to my career, as it's used everywhere which underlies how important popularity of a language can be for developers when evaluating languages for career choices
biglost 2y ago
I'm not smart nor have any university title butmy opinion is this it's very good, but efforts should also go into remove features, not just python, i get it, it would breake anything.
the5avage 2y ago
Can someone share insight into what was technically done to enable this? What replaced the global lock? Is the GC stopping all threads during collection or an other locking mechanism?
- nas 2y ago
  The key enabling tech is thread safe reference counting. There are many other problems that Sam Gross solved in order to make it happen but the reference counting was one of the major blockers.
  - the5avage 2y ago
    Is this implemented with lockless programming? Is it a reason for the performance drop in single thread code? Does it eliminate the need for a GC pause completely?
    - nas 2y ago
      You should probably just read the PEP, which explains these things: https://peps.python.org/pep-0703/#reference-counting https://peps.python.org/pep-0703/#reference-counting If by GC you mean the cyclic GC, free-threaded Python currently stops all threads while the cyclic GC is running.
      - the5avage 2y ago
        Thank you:)
- tightbookkeeper 2y ago
  Lots of little locks littered all over the place.
- throwaway313373 2y ago
  AFAIK the initial prototype called nogil was developed by a person named Sam Gross who also wrote a detailed article [0] about it. He also had a meeting with Python core. Notes from this meeting [1] by Łukasz Langa provide more high-level overview, so I think that they are a good starting point. [0] https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/mobilebasic https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf... [1] https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/ https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...
0xDEADFED5 2y ago
Nice benchmarks. Hopefully some benevolent soul with more spare time than I can pitch in on threadsafe CFFI
aitchnyu 2y ago
Are there web frameworks taking advantage of subinterpreters and free threading yet?
santiagobasulto 2y ago
With these new additions it might make sense to have a synchronized block as in Java?

196 points by art049 2y ago

deleted 2y ago

[deleted]

I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "real" semantics. On the other hand, a lot of these changes to try and speed up the base language are going to be highly disruptive. E.g. disabling the GIL will break tonnes of code, lots of compilation projects involve changes to the ABI, etc. I guess getting loops in Python to run 5-10x faster will still save some people time, but it's also never going to be a replacement for the zoo of specialized python-like compilers because it'll never get to actual high performance territory, and it's not clear that it's worth all the ecosystem churn it might cause.

willvarfar 2y ago
(As a happy pypy user in previous jobs, I want to chime in and say python _can_ be fast. It can be so fast that it completely mooted the discussions that often happen when wanting to move from a python prototype to 'fast enough for production'.)
- eigenspace 2y ago
  PyPy is still slow compared to actual fast languages. It's just fast compared to Python, and it achieves that speed by not being compatible with most of the Python ecosystem. Seems like a lose-lose to me. (which is presumably why it never caught on)
  - rowanG077 2y ago
    What isn't compatible with PyPy? I can run large frameworks using pypy no problem. There certainly will be package that aren't compatible. But far and away most of the ecosystem is fully comaptible.
    - artemisart 2y ago
      This depends a lot on your domain, e.g. pypy is not compatible with pytorch or tensorflow so DL is out of the picture.
rmbyrro 2y ago
Python 3.12 will be officially supported until October 2028, so there's plenty of time to migrate to no-GIL if anyone wants to.
- zurfer 2y ago
  Python 3.13 is not removing the GIL. You just have an option to run without it.
the__alchemist 2y ago
This is a good question, and I think about it as well. My best guess for a simple explanation: Python is very popular; it makes sense to improve performance for python users, given many do not wish to learn to use a more performant language, or to use a more performant Python implementation. Becoming proficient in a range of tools so you can use the right one for the right job is high enough friction that it is not the path chosen by many.
- eigenspace 2y ago
  Oh yeah, I totally get the motivation behind it. It's always very tempting to want to make things faster. But I can't help but wondering if these attempts to make it faster might end up just making it worse. On the other hand though, Python is so big and there's so many corps using it with so much cash that maybe they can get away with just breaking shit every few releases and people will just go adapt packages to the changes.
  - dagmx 2y ago
    Python famously has a community that does NOT adapt to changes well. See the Python 2 to 3 transition.
    - eigenspace 2y ago
      Python's community was significantly smaller and less flushed with cash during the 2 to 3 transition. Since then there has been numerous 3.x releases that were breaking and people seem to have been sucking it up and dealing with it quietly so far. The main thing is that unlike the 2 to 3 transition, they're not breaking syntax (for the most part?), which everyone experiences and has an opinion on, they're breaking rather deep down things that for the most part only the big packages rely on so most users don't experience it much at all.
      - dagmx 2y ago
        I disagree with this entire comment. The Python community consisted of tons of developers including very wealthy companies. At what point in the last few years would you even say they became “rich enough” to do the migration? Because people are STILL talking about trying to fork 2.7 into a 2.8. I also disagree with your assertion that 3.x releases have significant breaking changes. Could you point to any specific major breaking changes between 3.x releases? 2 to 3 didn’t break syntax for most code either. It largely cleaned house on sensible API defaults.
sneed_chucker 2y ago
If JavaScript (V8) and PyPy can be fast, then CPython can be fast too. It's just that the CPython developers and much of the Python community sat on their hands for 15 years and said stuff like "performance isn't a primary goal" and "speed doesn't really matter since most workloads are IO-bound anyway".
- jerf 2y ago
  In this context, V8 and PyPy aren't fast. Or at least, not generally; they may actually do well on this task because pure number tasks are the only things they can sometimes, as long as you don't mess them up, get to compiled language-like performance. But they don't in general to compiled language performance, despite common belief to the contrary.
  - Spivak 2y ago
    Let's make this more concrete because assigning speed to languages is a fools errand. Python is doing a lot more per line of code than compiled languages to enable its very flexible semantics. In cases where this flexibility is desired you won't see much more performance in a compiled language as you'll have just implemented Python-like semantics on top of your compiled language— GObject is a good example of this. More famously this is Greenspun's tenth rule. > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. But where this flexibility isn't required, which is a lot of performance sensitive number crunching code the cost of the flexibility bites you. You can't "turn it off" when you want control down to the instruction for a truly massive performance win. Which is why I think the model Python has of highly expressive and flexible language backed by high-performance compiled libraries is so successful. Python will never be number crunching or parsing with the best of them because it would require essentially a whole new language to express the low-level constraints but for high-level code that relies on Python's semantics you can get performance wins that can't be accomplished just by switching to a compiled language. We've just taken the "embedded scripting language" and made it the primary interface.
  - adamc 2y ago
    This gets into the whole "fast for what purpose" discussion. For many purposes, JavaScript is quite acceptably fast. But it isn't C or Rust.
wormlord 2y ago
> On the other hand, a lot of these changes to try and speed up the base language are going to be highly disruptive. E.g. disabling the GIL will break tonnes of code, lots of compilation projects involve changes to the ABI, etc. Kind of related, the other day I was cursing like a sailor because I was having issues with some code I wrote that uses StrEnum not working with older versions of Python, and wondering why I did that, and trying to find the combination of packages that would work for the version of Python I needed-- wondering why there was so much goddamn churn in this stupid [expletive] scripting language. But then I took a step back and realized that, actually, I should be glad about the churn because it means that there is a community of developers who care enough about the language to add new features and maintain this language so that I can just pipe PyQt and Numpy into each other and get paid. I don't have any argument, just trying to give an optimistic perspective.
- d0mine 2y ago
  At least bugfix versions could have kept Enum behavior the same. Postponing breaking changes until the next minor version. Some Enum features work differently (incompatible) in Python 3.11.x versions.
  - wormlord 2y ago
    > Some Enum features work differently (incompatible) in Python 3.11.x versions. I wasn't aware of that, that's actually insane. It's odd to me that it took so long to get f-strings and Enums right in Python, I assumed those would be pretty easy language features to implement.
  - roelschroeven 2y ago
    > Some Enum features work differently (incompatible) in Python 3.11.x versions. I know that Python 3.11 added some things, like StrEnum; those obviously won't work on older Python versions. But I'm not aware of things that work in a certain Python 3 version but don't work in newer ones. You're even talking about incompatibilities between different 3.11.x versions? Can you give some more detail on that?
yunohn 2y ago
> I guess getting loops in Python to run 5-10x faster will still save some people time I would recommend being less reductively dismissive, after claiming you “don’t really have a dog in this race”. Edit: Lots of recent changes have done way more than just loop unrolling JIT stuff.
Capricorn2481 2y ago
I don't really get this. They have already made Python faster in the past while maintaining the same semantics. Seems like a good goal to me.
andai 2y ago
There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experiences trying to get older code with dependencies running. My meaning with this comment is, that if the average developer's reality is that backwards compatibility isn't really a thing anyway, then we are already paying for that downside so we might as well get some upside there, is my reasoning.
- almostgotcaught 2y ago
  > I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). ... > I wrote last year and it turned out that a bunch of my dependencies had changed their APIs these two things have absolutely nothing to do with each other - couldn't be a more apples to oranges comparison if you tried
  - andai 2y ago
    I ran into both of these things in the same context, which is "the difficulty involved in getting old code working on the latest Python environment", which I understood as the context of this discussion.
- klysm 2y ago
  So pin your deps? Language backwards compatibility and an API from some random package changing are completely distinct.
  - epistasis 2y ago
    Pinning deps is discouraged by years of Python practice. And going back to a an old project and finding versions that work, a year or more later, might be nigh on impossible. Last week I was trying to install snakemake via Conda, and couldn't find any way to satisfy dependencies at all, so it's not just pypi, and pip tends to be one of the more forgiving version dependency managers. It's not just Python, trying to get npm to load the requirements has stopped me from compiling about half of the projects I've tried to build (which is not a ton of projects). And CRAN in the R universe can have similar problems as projects age.
jillesvangurp 2y ago
Why does python have to be slow? Improvements over the last few releases have made it quite a bit faster. So that kind of counters that a bit. Apparently it didn't need to be quite as slow all along. Other languages can be fast. So, why not python? I think with the GIL some people are overreacting: most python code is single threaded because of the GIL. So removing it doesn't actually break anything. The GIL was just making the use of threads kind of pointless. Removing it and making a lot of code thread safe benefits people who do want to use threads. It's very simple. Either you did not care about performance anyway and nothing really changes for you. You'd need to add threading to your project to see any changes. Unless you do that, there's no practical reason to disable the GIL for you. Or to re-enable that once disabled becomes the default. If your python project doesn't spawn threads now, it won't matter to you either way. Your code won't have deadlocking threads because it has only 1 thread and there was never anything to do for the GIL anyway. For code like that compatibility issues would be fairly minimal. If it does use threads, against most popular advise of that being quite pointless in python (because of the GIL), you might see some benefits and you might have to deal with some threading issues. I don't see why a lot of packages would break. At best some of them would be not thread safe and it's probably a good idea to mark the ones that are thread safe as such in some way. Some nice package management challenge there. And probably you'd want to know which packages you can safely use.
- eigenspace 2y ago
  > Why does python have to be slow? Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc. The list of stuff like this goes on and on and on. You fundamentally just cannot compile most python programs to efficient machine code without making (sometimes subtle) changes to its semantics. _________ > I don't see why a lot of packages would break. At best some of them would be not thread safe and it's probably a good idea to mark the ones that are thread safe as such in some way. Some nice package management challenge there. And probably you'd want to know which packages you can safely use. They're not thread safe because it was semantically guaranteed to them that it was okay to write code that's not thread safe.
rfoo 2y ago
> Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible Scientific computing community have a bunch of code calling numpy or whatever stuff. They are pretty fast because, well, numpy isn't written in Python. However, there is a scalability issue: they can only drive so many threads (not 1, but not many) in a process due to GIL. Okay, you may ask, why not just use a lot of processes and message-passing? That's how historically people work around the GIL issue. However, you need to either swallow the cost of serializing data over and over again (pickle is quite slow, even it's not, it's wasting precious memory bandwidth), or do very complicated dance with shared memory. It's not for web app bois, who may just write TypeScript.
- eigenspace 2y ago
  Numpy is not fast enough for actual performance sensitive scientific computing. Yes threading can help, but at the end of the day the single threaded perf isn't where it needs to be, and is held back too much by the python glue between Numpy calls. This makes interproceedural optimizations impossible. Accellerated sub-languages like Numba, Jax, Pytorch, etc. or just whole new languages are really the only way forward here unless massive semantic changes are made to Python.
  - rfoo 2y ago
    These "accelerated sub-languages" are still driven by, well, Python glue. That's why we need free-threading and faster Python. We want the glue to be faster because it's currently the most accessible glue to the community. In fact, Sam, the man behind free-threading, works on PyTorch. From my understanding he decided to explore nogil because GIL is holding DL trainings written in PyTorch back. Namely, the PyTorch DataLoader code itself and almost all data loading pipelines in real training codebases are hopeless bloody mess just because all of the IPC/SHM nonsense.
- willseth 2y ago
  This is misleading. Most of the compute intensive work in Numpy releases the GIL, and you can use traditional multithreading. That is the case for many other compute intensive compiled extensions as well.
ggm 2y ago
You may be right. I personally think this work is net beneficial, and although I never expected to be in MP or threads, I now find doing a lot of DNS (processing end of day logs of 300m records per day, trying to farm them out over public DNS resolvers doing multiple RR checks per FQDN) that the MP efficiency is lower than threads, because of this serialisation cost. So, improving threading has shown me I could be 4-5x faster in this solution space, IFF I learn how to use the thread.lock to gatekeep updates on the shared structures. My alternative is to serialise in heavy processes and then incur a post process unification pass, because the cost of serialise send/receive deserialise to unify this stuff is too much. If somebody showed me how to use shm models to do this so it came back to the cost of threading.lock I'd do the IPC over a shared memory dict, but I can't find examples and now suspect multiprocessing in Python3 just doesn't do that (happy, delighted even to be proved wrong)
nickpsecurity 2y ago
I spent some time looking into it. I believe it could be done with a source-to-source transpiler with zero-cost abstractions and some term rewriting. It’s a lot of work. The real barrier my thought experiment hit were the extensions. Many uses of Python are glue around C extensions designed for the CPython interpreter. Accelerating “Python” might actually be accelerating Python, C, and hybrid code that’s CPython-specific. Every solution seemed like more trouble than just rewriting those libraries to not be CPython-specific. Or maybe to work with the accelerators better. Most people are just using high-level C++ and Rust in the areas I was considering. If using Python, the slowdown of Python doesn’t impact them much anyway since their execution time is mostly in the C code. I’m not sure if much will change.
runeblaze 2y ago
For machine learning (un)fortunately, lots of the stack runs on Python. Lots of ceremony was done to circumvent GIL (e.g. PyTorch data loader). “Reasonable performance Python” I imagine is actually something in huge demand for lots of ML shops
emgeee 2y ago
One area where this absolutely makes a difference is when embedding python. Like it or not Python is extreme popular in data/AI/ML so if you want to build an experience where users can deploy custom functions, removing the GIL allows you to more efficiently scale these workloads.
pjmlp 2y ago
Since Python has become the new Lisp, the minimum is to have the performance tooling Common Lisp has had for several decades, in native code generation and multithreading (yes I know that in CL this is implementation specific).
cma 2y ago
How about when there are 128-256 core consumer CPUs?
- lanstin 2y ago
  And people are running things that take minutes to run when a good multi-cpu framework would make it seconds. Maybe add a dataflow analyzer to Python and do it for people.
6gvONxR4sf7o 2y ago
> so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "real" semantics. I don't even understand what this means. If I write `def foo(x):` versus `def foo(x: int) -> float:`, one is a restricted subset of the other, but both are the language's "real" semantics. Restricted subsets of languages are wildly popular in programming languages, and for very varied reasons. Why should that be a barrier here? Personally, if I have to annotate some of my code that run with C style semantics, but in return that part runs with C speed, for example, then I just don't really mind it. Different tools for different jobs.
- almostgotcaught 2y ago
  > If I write `def foo(x):` versus `def foo(x: int) -> float:`, one is a restricted subset of the other, but both are the language's "real" semantics. You either are performing some wordplay here or you don't understand but type hints are not part of the semantics at all: since they are not processed at all they do not affect the behavior of the function (that's what semantics means). EDIT: according to the language spec and current implementation `def foo(x: int) -> float` and `def foo(x: float) -> int` are the same exact function
  - movpasd 2y ago
    That's not strictly true -- type annotations are accessible at runtime (that's how things like dataclasses and pydantic work).
lijok 2y ago
Given the scale at which python is run, how much energy are we saving by improving its performance by 1%?
PaulHoule 2y ago
As a Java dev I think people don’t always appreciate the flexiblity of threads for manage parallelism, concurrency, and memory. In particular with threads you can have a large number of thread share a large data structure. Say you have an ML inference model that takes 1GB of RAM. No way can you let 25 Celery workers each have a copy of that model, so if you are using Python you have to introduce a special worker class. It’s one more thing to worry about and more parameters to tune. With Java all your “workers” could be in one process, even the same process as your web server and that will be the case in Python. Threads break down so many bottlenecks of CPU resources, memory, data serialization, waiting for communications, etc. I have a 16-core computer on my desk and getting a 12x speed-up is possible for many jobs and often worth worse less efficient use of the individual CPU. Java has many primitives for threads that include tools for specialized communications (e.g. barrier synchronization) that are necessary to really get those speed-ups and I hope Python gets those too.
Someone 2y ago
I think the reasoning is like this: - People choose Python to get ease of programming, knowing that they give up performance. - With multi-core machines now the norm, they’re relatively giving up more performance to get the same amount of ease of programming. - so, basically, the price of ease of programming has gone up. - economics 101 is that rising prices will decrease demand, in this case demand for programming in Python. - that may be problematic for the long-term survival of Python, especially with new other languages aiming to provide python’s ease of use while supporting multi-processing. So, Python must get even easier to use and/or it must get faster.
graemep 2y ago
I do use Python and I am not that bothered about speed. Very little of what I use it for has performance bottlenecks in the Python. Its the database or the network or IO or whatever. On the few occasions when it does I can rewrite critical bits of code. I definitely care more about backward compatibility than I do about performance. It feels like Python development is being driven by the needs of one particular group (people who use ML heavily, possibly because they have deep pockets) and I wonder whether this, and a few other things will make it less attractive a language for me and others.
- winrid 2y ago
  Your DB is probably faster than you think. I rewrote an API in Python to Java and it is around 6x faster with just same dumb N+1 queries, and the new API also includes all the frontend calculations that Python wasn't doing before.
DeathArrow 2y ago
>Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "real" semantics. Have you heard of Mojo? It is a very performant superset of Python. https://www.modular.com/mojo https://www.modular.com/mojo
- pansa2 2y ago
  Mojo isn’t anywhere near a superset of Python. It doesn’t even support classes!
otabdeveloper4 2y ago
Parallelism != speed. If you have 128 cores you can compromise on being a bit slow. You can't compromise on being single-threaded though.
- lanstin 2y ago
  And for the code running on the 128 core machine, which is not really rare these days, for that code to be pythonic, it should be dead simple to use all the cores in the obvious correct way. We have language features that enable simple multiple semantics but haven't yet got the easy way to do it. MP has the stupid serialization issues and anything involving the Python coder doing locking or mutexes is not Pyrhinic as they will struggle.
Netcob 2y ago
I was experimenting with Python for some personal data-based project. My goal was to play around with some statistics functions, maybe train some models and so on. Unfortunately most of my data needs a lot of preprocessing before it will be of any use to numpy&co. Mostly just picking out the right objects from a stream of compressed JSON data and turning them into time series. All of that is easy to do in Python, which is what I'd expect for the language used this much in data science (or so I've heard). But then I do have a lot of data, there's a lot of trial&error there for me so I'm not doing these tasks only once, and I would have appreciated a speedup of up to 16x. I don't know about "high performance", but that's the difference between a short coffee break and going to lunch. And if I was a working on an actual data-oriented workstation, I would be using only one of possibly 100+ cores. That just seems silly to me.
ogrisel 2y ago
The IPC overhead of process-based parallelism in Python is a pain to deal with in general, even when the underlying computational bottleneck are already written CPU optimized (calls to compiled extensions written in Cython/C/C++/Rust, call to CPU optimized operations written with CPU architecture-specific intrinsics/assembly from OpenBLAS via NumPy/SciPy, calls to e.g. GPU CUDA kernels via PyTorch/Triton, ...). Sometimes the optimal level of parallelism lies in an outer loop written in Python instead of just relying on the parallelism opportunities of the inner calls written using hardware specific native libraries. Free-threading Python makes it possible to choose which level of parallelism is best for a given workload without having to rewrite everything in a low-level programming language.
kevincox 2y ago
Even if something is slow there is utility to have it run faster. Sure, Python will never be with for the most demanding performance requirements but that doesn't mean we should deny people performance. There are lots of use case where Python's performance is acceptable but a 10x speed boost would be much appreciated. Or where Python's performance is not acceptable but it would be if I could fully utilize my 32 cores. For example look at Instagram. They run tons of Python but need to run many processes on each machine wasting memory. I'm sure they would love to save that memory, the environment would too. Sure, they could rewrite their service in C but that is most likely not the best tradeoff.
zelphirkalt 2y ago
I am always wondering who writes code so badly unaware of concurrency issues, to rely on the GIL. Wondering how many libraries and programs will actually break. But probably the number is way higher than even I imagine.
- ogrisel 2y ago
  The race condition bugs are typically hidden by different software layers. For instance, we found one that involves OpenBLAS's pthreads-based thread pool management and maybe its scipy bindings: - https://github.com/scipy/scipy/issues/21479 https://github.com/scipy/scipy/issues/21479 it might be the same as this one that further involves OpenMP code generated by Cython: - https://github.com/scikit-learn/scikit-learn/issues/30151 https://github.com/scikit-learn/scikit-learn/issues/30151 We haven't managed to write minimal reproducers for either of those but as you can observe, those race conditions can only be triggered when composing many independently developed components.
stevofolife 2y ago
Can you help me understand, if libraries like pandas and numpy also applies to your comment? Or are they truely optimized and you’re just referring to the standard Python language?

ijl 2y ago

Performance for python3.14t alpha 1 is more like 3.11 in what I've tested. Not good enough if Python doesn't meet your needs, but this comes after 3.12 and 3.13 have both performed worse for me. 3.13t doesn't seem to have been meant for any serious use. Bugs in gc and so on are reported, and not all fixes will be backported apparently. And 3.14t still has unavoidable crashes. Just too early.

bastawhiz 2y ago
> 3.13t doesn't seem to have been meant for any serious use. I don't think anyone would suggest using it in production. The point was to put something usable out into the world so package maintainers could kick the tires and start working on building compatible versions. Now is exactly the time for weird bug reports! It's a thirty year old runtime and one of its oldest constraints is being removed!
kristianp 2y ago
> 3.12 and 3.13 have both performed worse for me That's interesting, I wouldn't have expected performance regressions coming from those releases. How can that be?

refdl 2y ago

[flagged]

kmeisthax 2y ago
> people are kept in line with CoC threats Can you point to an example of someone claiming that a particular feature's performance claims were misleading, and then getting threatened with a ban or other sanctions for it, where they did not otherwise violate CoC?
- pwdisswordfishz 2y ago
  > where they did not otherwise violate CoC? Violations are in the eye of the enforcer.
notatallshaw 2y ago
You seem to be conflating problems and different groups of people that aren't directly related. To clarify some different groups: * The faster-cpython project, headed by Guido and his team at Microsoft, is continuing fine, most of the low hanging fruit was accomplished by 3.11, further improvements were moved to medium term goals and they were delayed further by the free threaded project which broke assumptions that were made to optimize CPython, they have adapted but it has pushed big optimizations out to later released (think probably 3.15ish) * The free threaded project, initiated by Sam Gross at Meta, is continuing fine, it was never intended to be ready by 3.13, the fact there is even a build officially published is very fast progress. There isn't yet a plan to make it default, depending on the compatibility of the free threaded build it could be a quick transition or a 5+ year switch over. * The PSF, the Steering Council, and the CoC WG are all different groups that have different responsibilities and aren't typically involved in day-to-day choices of committing certain features. * The release manager is a core developer in charge of making the final choice on whether a particular feature is stable or not. It was the 3.13 release manager who decided to revert the new GC which was intended to generally improve performance for non-free threaded builds, which it may still do in a future release with sufficient fine tuning. Now, there are clearly communication issues in areas of the Python community, but there is also a lot of people getting on with great work and improvements and communicating fine.

runjake 2y ago

If it were ever open sourced, I could see Mojo filling the performance niche for Python programmers. I'm hopeful because Lattner certainly has the track record, if he doesn't move on beforehand. https://en.wikipedia.org/wiki/Mojo_(programming_language) https://en.wikipedia.org/wiki/Mojo_(programming_language)

qaq 2y ago
https://github.com/modularml/mojo/blob/main/LICENSE https://github.com/modularml/mojo/blob/main/LICENSE
- kaanyalova 2y ago
  The source code for the compiler hasn't released yet
misswaterfairy 2y ago
If not, Nim is probably the closest most 'Python-like' language that is almost as fast as C, and is released under the MIT licence. https://nim-lang.org/ https://nim-lang.org/ https://en.wikipedia.org/wiki/Nim_(programming_language) https://en.wikipedia.org/wiki/Nim_(programming_language)

Decabytes 2y ago

I'm glad the Python community is focusing more on CPython's performance. Getting speed ups on existing code for free feels great. As much as I hate how slow Python is, I do think its popularity indicates it made the correct tradeoffs in regards to developer ease vs being fast enough. Learning it has only continued to be a huge benefit to my career, as it's used everywhere which underlies how important popularity of a language can be for developers when evaluating languages for career choices

biglost 2y ago

I'm not smart nor have any university title butmy opinion is this it's very good, but efforts should also go into remove features, not just python, i get it, it would breake anything.

the5avage 2y ago

Can someone share insight into what was technically done to enable this? What replaced the global lock? Is the GC stopping all threads during collection or an other locking mechanism?

nas 2y ago
The key enabling tech is thread safe reference counting. There are many other problems that Sam Gross solved in order to make it happen but the reference counting was one of the major blockers.
- the5avage 2y ago
  Is this implemented with lockless programming? Is it a reason for the performance drop in single thread code? Does it eliminate the need for a GC pause completely?
  - nas 2y ago
    You should probably just read the PEP, which explains these things: https://peps.python.org/pep-0703/#reference-counting https://peps.python.org/pep-0703/#reference-counting If by GC you mean the cyclic GC, free-threaded Python currently stops all threads while the cyclic GC is running.
    - the5avage 2y ago
      Thank you:)
tightbookkeeper 2y ago
Lots of little locks littered all over the place.
throwaway313373 2y ago
AFAIK the initial prototype called nogil was developed by a person named Sam Gross who also wrote a detailed article [0] about it. He also had a meeting with Python core. Notes from this meeting [1] by Łukasz Langa provide more high-level overview, so I think that they are a good starting point. [0] https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/mobilebasic https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf... [1] https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/ https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...

0xDEADFED5 2y ago

Nice benchmarks. Hopefully some benevolent soul with more spare time than I can pitch in on threadsafe CFFI

aitchnyu 2y ago

Are there web frameworks taking advantage of subinterpreters and free threading yet?

santiagobasulto 2y ago

With these new additions it might make sense to have a synchronized block as in Java?