5 ms·

> That's the trade-off. Personally I think a single digit percentage slow-down of single-threaded code worth it. Maybe. I would expect that 99% of python code

> That's the trade-off. Personally I think a single digit percentage slow-down of single-threaded code worth it. Maybe. I would expect that 99% of python code going forward will still be single threaded. You just don’t need that extra complexity for most code. So I would expect that python code as a whole will have worse performance, even though a handful of applications will get faster.

pphysch 1y ago
But the bar to parallelizing code gets much lower, in theory. Your serial code got 5% slower but has a direct path to being 50% faster. And if there's a good free-threaded HTTP server implementation, the RPS of "Python code as a whole" could increase dramatically.
- weakfish 1y ago
  Is there any news from FastAPI folks and/or Gunicorn on their support?
- fjasdfas 1y ago
  You can do multiple processes with SO_REUSEPORT. free-threaded makes sense if you need shared state.
  - pphysch 1y ago
    Any webserver that wants to cache and reuse content cares about shared state, but usually has to outsource that to a shared in-memory database because the language can't support it.
    - monkeyelite 1y ago
      And most web servers already need in memory databases for other things. And it’s a great design principle - use sharp focused tools.
rfoo 1y ago
That's the mindset that leads to the funny result that `uv pip` is like 10x faster than `pip`. Is it because Rust is just fast? Nope. For anything after resolving dependency versions raw CPU performance doesn't matter at all. It's writing concurrent PLUS parallel code in Rust is easier, doesn't need to spawn a few processes and wait for the interpreter to start in each, doesn't need to serialize whatever shit you want to run constantly. So, someone did it! Yet, there's a pip maintainer who actively sabotages free-threading work. Nice.
- notpushkin 1y ago
  > Yet, there's a pip maintainer who actively sabotages free-threading work. Wow. Could you elaborate?
- Doxin 1y ago
  For anyone who hasn't used uv, I feel like 10x faster is an understatement. For cases where packages are already downloaded it's basically instant for any use case I have run into.
foresto 1y ago
As I recall, CPython has also been getting speed-ups lately, which ought to make up for the minor single-threaded performance loss introduced by free threading. With that in mind, the recent changes seem like an overall win to me.
- celeritascelery 1y ago
  It’s not either/or. The CPython speedups would be even better with the single threaded interpreter.
  - foresto 1y ago
    Nobody has suggested otherwise.
oconnor663 1y ago
Sure but of those 99%, how many are performance-sensitive, CPU-bound (in Python not in C) applications? It's clearly some, not saying it's an easy tradeoff, but I assume the large majority of Python programs out there won't notice a slowdown.

pphysch 1y ago

But the bar to parallelizing code gets much lower, in theory. Your serial code got 5% slower but has a direct path to being 50% faster. And if there's a good free-threaded HTTP server implementation, the RPS of "Python code as a whole" could increase dramatically.

weakfish 1y ago
Is there any news from FastAPI folks and/or Gunicorn on their support?
fjasdfas 1y ago
You can do multiple processes with SO_REUSEPORT. free-threaded makes sense if you need shared state.
- pphysch 1y ago
  Any webserver that wants to cache and reuse content cares about shared state, but usually has to outsource that to a shared in-memory database because the language can't support it.
  - monkeyelite 1y ago
    And most web servers already need in memory databases for other things. And it’s a great design principle - use sharp focused tools.

rfoo 1y ago

That's the mindset that leads to the funny result that `uv pip` is like 10x faster than `pip`. Is it because Rust is just fast? Nope. For anything after resolving dependency versions raw CPU performance doesn't matter at all. It's writing concurrent PLUS parallel code in Rust is easier, doesn't need to spawn a few processes and wait for the interpreter to start in each, doesn't need to serialize whatever shit you want to run constantly. So, someone did it! Yet, there's a pip maintainer who actively sabotages free-threading work. Nice.

notpushkin 1y ago
> Yet, there's a pip maintainer who actively sabotages free-threading work. Wow. Could you elaborate?
Doxin 1y ago
For anyone who hasn't used uv, I feel like 10x faster is an understatement. For cases where packages are already downloaded it's basically instant for any use case I have run into.

foresto 1y ago

As I recall, CPython has also been getting speed-ups lately, which ought to make up for the minor single-threaded performance loss introduced by free threading. With that in mind, the recent changes seem like an overall win to me.

celeritascelery 1y ago
It’s not either/or. The CPython speedups would be even better with the single threaded interpreter.
- foresto 1y ago
  Nobody has suggested otherwise.

oconnor663 1y ago

Sure but of those 99%, how many are performance-sensitive, CPU-bound (in Python not in C) applications? It's clearly some, not saying it's an easy tradeoff, but I assume the large majority of Python programs out there won't notice a slowdown.