5 ms·

> there is just a tremendous amount of performance that can be automatically unlocked with almost no incremental effort for so many organizations and projects

> there is just a tremendous amount of performance that can be automatically unlocked with almost no incremental effort for so many organizations and projects This just isn’t true. This does not improve single threaded performance (it’s worse) and concurrent programming is already available. This will make it less annoying to do concurrent processing. It also makes everything slower (arguable where that ends up, currently significantly slower) overall. This way over hyped. At the end of the day this will be a change that (most likely) makes the existing workloads for everyone slightly slower and makes the lives of a few people a bit easier when they implement natively parallel processing like ML easier and better. It’s an incremental win for the ML community, and a meaningless/slight loss for everyone else. At the cost of a great. Deal. Of. Effort. If you’re excited about it because of the hype and don’t really understand it, probably calm down. Mostly likely, at the end of the day, it s a change that is totally meaningless to you, won’t really affect you other than making some libraries you use a bit faster, and others a bit slower. Overall, your standard web application will run a bit slower as a result of it. You probably won’t notice. Your data stack will run a bit faster. That’s nice. That’s it. Over hyped. 100%.

anwlamp 2y ago
Yes, good summary. My prediction is that free-threading will be the default at some point because one of the corporations that usurped Python-dev wants it. The rest of us can live with arcane threading bugs and yet another split ecosystem. As I understand it, if a single C-extension opts for the GIL, the GIL will be enabled. Of course the invitation to experiment is meaningless. CPython is run by corporations, many excellent developers have left and people will not have any influence on the outcome.
- pansa2 2y ago
  > one of the corporations that usurped Python-dev Man, that phrase perfectly encapsulates so much of Python’s evolution over the last ~10 years.
  - gomizari 2y ago
    Just Python evolution?
Uptrenda 2y ago
Why would it make single threaded performance slower? Sorry, but that's kind of ridiculous. You're just making shit up at this point.
- QkdhagA 2y ago
  What is "it"? If you assume two completely separate implementations where there is an #ifdef every 10 lines and atomics and locking only occur with --disable-gil, there is no slowdown for the --enable-gil build. I don't think that is entirely the case though! If the --enable-gil build becomes the default in the future, then peer pressure and packaging discipline will force everyone to use it. Then you have the OBVIOUS slowdown of atomics and of locking the reference counting and in other places. The advertised figures were around 20%, which would be offset by minor speedups in other areas. But if you compare against Python 3.8, for instance, the slowdowns are still there (i.e., not offset by anything). Further down on the second page of this discussion numbers of 30-40% have been measured by the submitter of this blog post. Actual benchmarks of Python tend to be suppressed or downvoted, so they are not on the first page. The Java HotSpot VM had a similar policy that forbid benchmarks.
- dragonwriter 2y ago
  Removing the GIL requires operations that are protected by it when it exists to be made thread safe in ways which they don't need to be with it, which has some overhead. Even having multiple options from which the situationally correct one (e.g., a lighter-weight one in guaranteed single-threaded or GIL active cases) can automatically be selected has some overhead. (Conceptually, you could have separate implementations that can be selected by the programmer with zero runtime overhead where not needed, but that also has more conceptual/developer overhead, so other than particular things where the runtime cost is found to really bite in practice, that's probably not going to be a common approach for core libraries that might need to be called either way. There's no free lunch here.
- wokwokwok 2y ago
  https://news.ycombinator.com/item?id=40949564 https://news.ycombinator.com/item?id=40949564 ^ read. The OP responds in the thread. tldr, literally what I said: > It also makes everything slower (arguable where that ends up, currently significantly slower) overall. longer version: If there was no reason for it to be slower, it would not be slower. ...but, implementing this stuff is hard. Doing a zero cost implementation is really hard. It is slower. Where it ends up eventually is still a 'hm... we'll see'. To be fair, they didn't lead the article here with: > Right now there is a significant single-threaded performance cost. Somewhere from 30-50%. They should have, because now people have a misguided idea of what this wip release is... and that's not ideal; because if you install it, you'll find its slow as balls; and that's not really the message they were trying to put out with this release. This release was about being technically correct. ...but, it is slow as balls right now, and I'm not making that shit up. Try it yourself. /shrug

anwlamp 2y ago

Yes, good summary. My prediction is that free-threading will be the default at some point because one of the corporations that usurped Python-dev wants it. The rest of us can live with arcane threading bugs and yet another split ecosystem. As I understand it, if a single C-extension opts for the GIL, the GIL will be enabled. Of course the invitation to experiment is meaningless. CPython is run by corporations, many excellent developers have left and people will not have any influence on the outcome.

pansa2 2y ago
> one of the corporations that usurped Python-dev Man, that phrase perfectly encapsulates so much of Python’s evolution over the last ~10 years.
- gomizari 2y ago
  Just Python evolution?

Uptrenda 2y ago

Why would it make single threaded performance slower? Sorry, but that's kind of ridiculous. You're just making shit up at this point.

QkdhagA 2y ago
What is "it"? If you assume two completely separate implementations where there is an #ifdef every 10 lines and atomics and locking only occur with --disable-gil, there is no slowdown for the --enable-gil build. I don't think that is entirely the case though! If the --enable-gil build becomes the default in the future, then peer pressure and packaging discipline will force everyone to use it. Then you have the OBVIOUS slowdown of atomics and of locking the reference counting and in other places. The advertised figures were around 20%, which would be offset by minor speedups in other areas. But if you compare against Python 3.8, for instance, the slowdowns are still there (i.e., not offset by anything). Further down on the second page of this discussion numbers of 30-40% have been measured by the submitter of this blog post. Actual benchmarks of Python tend to be suppressed or downvoted, so they are not on the first page. The Java HotSpot VM had a similar policy that forbid benchmarks.
dragonwriter 2y ago
Removing the GIL requires operations that are protected by it when it exists to be made thread safe in ways which they don't need to be with it, which has some overhead. Even having multiple options from which the situationally correct one (e.g., a lighter-weight one in guaranteed single-threaded or GIL active cases) can automatically be selected has some overhead. (Conceptually, you could have separate implementations that can be selected by the programmer with zero runtime overhead where not needed, but that also has more conceptual/developer overhead, so other than particular things where the runtime cost is found to really bite in practice, that's probably not going to be a common approach for core libraries that might need to be called either way. There's no free lunch here.
wokwokwok 2y ago
https://news.ycombinator.com/item?id=40949564 https://news.ycombinator.com/item?id=40949564 ^ read. The OP responds in the thread. tldr, literally what I said: > It also makes everything slower (arguable where that ends up, currently significantly slower) overall. longer version: If there was no reason for it to be slower, it would not be slower. ...but, implementing this stuff is hard. Doing a zero cost implementation is really hard. It is slower. Where it ends up eventually is still a 'hm... we'll see'. To be fair, they didn't lead the article here with: > Right now there is a significant single-threaded performance cost. Somewhere from 30-50%. They should have, because now people have a misguided idea of what this wip release is... and that's not ideal; because if you install it, you'll find its slow as balls; and that's not really the message they were trying to put out with this release. This release was about being technically correct. ...but, it is slow as balls right now, and I'm not making that shit up. Try it yourself. /shrug