Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Free-threaded CPython is ready to experiment with

labs.quansight.org

Post reply on HN
Print view View original

381–390 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#381

Post by robertlagrant »

throwaway81523 wrote: post #234
robertlagrant wrote: post #230

Earlier quoted context omitted.

Async seems fine? What's wrong with it?

Watch this video and maybe you'll understand ;). Warning, NSFW (lots of swearing), use headphones. https://www.youtube.com/watch?v=bzkRVzciAZg This is also good: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... web search on "colored functions" finds lots of commentary on that article.

Yeah gotcha - I'm familiar with the colored functions argument. I see the conceptual downside, but it doesn't seem that bad in practice. I have a pre-commit hook that shouts at me if I call an async function synchronously.

Re: Free-threaded CPython is ready to experiment with

#382

Post by ngoldbaum »

ngoldbaum wrote: post #24
mihaic wrote: post #19

Does anyone know if there is more serious single threaded performance degradation (more than a few percent for instance)? I couldn't find any benchmarks, just some generic reassurance that everything is fine.

Right now there is a significant single-threaded performance cost. Somewhere from 30-50%. Part of what my colleague Ken Jin and others are working on is getting back some of that lost performance by applying some optimizations. Expect single-threaded performance to improve for Python 3.14 next year.

Clarifying a few days later: single-threaded performance in the normal ABI with the GIL does not have the same performance degradation. You only see the performance hit if you’re testing the experimental 3.13 free-threaded release.

Re: Free-threaded CPython is ready to experiment with

#383

Post by hot_gril »

zo1 wrote: post #310
hot_gril wrote: post #84

Earlier quoted context omitted.

JS had an event loop since the start. It's an old concept that Python seems to have lifted, as did Rust. I used Python for a decade and never really liked the way it did threads.

Python's reactor pattern, or event loop as you call it, started with the "Twisted" framework or library. And that was first published in 2003. That's a full 6 years before Node.js was released which I assume was the first time anything event-loopy started happening in the JS world. I forgot to mention that it came into prominence in the Python world through the Tornado http server library that did the same thing. Slo…

Yeah, this pattern is old. But JS is the only common language (at least today) that went so all-in with it.

Re: Free-threaded CPython is ready to experiment with

#384

Post by __MatrixMan__ »

kaba0 wrote: post #365
__MatrixMan__ wrote: post #83

Earlier quoted context omitted.

Python's dependency management sucks because they're audacious enough to attempt packaging non-python dependencies. People always bring Maven up as a system that got it right, but Maven only does JVM things. I think the real solution here is to just only use python dependency management for python things and to use something like nix for everything else.

There is no way to manage non-hosted dependencies, though, in a cross-platform way. Something attempting it is often worse than nothing, on a distro that has different assumptions — e.g. every package manager that downloads a dynamic executable will fail on NixOS, and gives no easy way to hook into how those get executed.

I agree that attempting it is worse than nothing, because you now have expectations that may fail at awkward times. But they've gone an done it so here we are.

NixOS is a stark contrast to Python here. It makes things that can't be done deterministically difficult to do at all. Maybe this sounds extreme from the outside, but I'd rather be warned off from that dependency as soon as I attempt to use it, rather than years later when I get a user or contributor than can't make it work for some environmental reason I didn't forsee and now everything rests on finding some hacky way to make it work.

If Nix can be used to solve Python's packaging problems, participating packages will have to practice the same kind of avoidance (or put in the work to fix such hazards up front). I'm not sure if the wider python community is willing to do that, but as someone who writes a lot of python myself and wants it to not be painful down the line, I am.

Re: Free-threaded CPython is ready to experiment with

#385

Post by throwaway81523 »

robertlagrant wrote: post #380
throwaway81523 wrote: post #325

Earlier quoted context omitted.

The Python community seems to have a virulent hatred of threads. I don't understand the reason. Yes there are hazards but you can code in a style that avoids them. With something like BEAM you can even enforce the style. Async/await of course introduce their own hazards.

There's no hatred. There are just lots of libraries that can't be multithreaded, due to historical reasons. This is being worked on right now[0], though. [0] https://peps.python.org/pep-0703

The GIL only gets in the way of parallelism. Yes there is real hatred. You can experience it if you visit #python on libera and ask anything about threads. "Aieee! The non-determinism! The race conditions! Etc." Of course the async requires an async version of the whole i/o system, it can block on long computations or the wrong system calls, etc. And many rock solid systems are written in Erlang, which uses preemptive lightweight processes for all its concurrency needs.

Lots of microcontroller OS's use cooperative multitasking but once there are enough machine resource's, OS's generally become preemptive. Async concurrency is basically cooperative multitasking with similar issues. Does Python give a way to open a file asynchronously in Linux? It's now possible with io_uring but it was impossible for a very long time (like decades). Erlang and GHC both use thread pools to deal with that. The use the old synchronous open(2) call but move it into an auxiliary thread so it won't block the calling thread.

Re: Free-threaded CPython is ready to experiment with

#386

Post by lordfrikk »

zo1 wrote: post #272
arp242 wrote: post #80

Earlier quoted context omitted.

Managing a farm of virtualenvs and mucking about with my PATH doesn't address the user-installable problem at all. And it seems there's a new tool to try every few months that really will fix all problems this time. And maybe if you're a Python developer working on the code every day that's all brilliant. But most people aren't Python developers, and I just want to try that "Show HN" project or whatnot. Give me a sin…

I could say the exact same stuff about NodeJs, c++, go, rust, php, etc. All of these are easy to use and debug and "install easily" when you know them and use them regularly, and the opposite if you're new. Doubly-so if you personally don't like that language or have some personal pet peeve about it's choices. Guys let's not pretend like this is somehow unique to python. It's only until about a few years ago that it…

That does not match my experience. I've been working with Python for a year or so and the packaging problems come up every now and then still.

I've installed/built a few packages written in Go and Rust specifically and had no problems.

Re: Free-threaded CPython is ready to experiment with

#387

Post by robertlagrant »

throwaway81523 wrote: post #385
robertlagrant wrote: post #380

Earlier quoted context omitted.

There's no hatred. There are just lots of libraries that can't be multithreaded, due to historical reasons. This is being worked on right now[0], though. [0] https://peps.python.org/pep-0703

The GIL only gets in the way of parallelism. Yes there is real hatred. You can experience it if you visit #python on libera and ask anything about threads. "Aieee! The non-determinism! The race conditions! Etc." Of course the async requires an async version of the whole i/o system, it can block on long computations or the wrong system calls, etc. And many rock solid systems are written in Erlang, which uses preemptiv…

> "Aieee! The non-determinism! The race conditions! Etc."

That doesn't sound like real hatred. Those sound like real concerns, which need to be addressed, and the attempt to remove the GIL is doing so very much with those concerns in mind.

Re: Free-threaded CPython is ready to experiment with

#388

Post by fastasucan »

phkahler wrote: post #25
eigenvalue wrote: post #12

Really excited for this. Once some more time goes by and the most important python libraries update to support no GIL, there is just a tremendous amount of performance that can be automatically unlocked with almost no incremental effort for so many organizations and projects. It's also a good opportunity for new and more actively maintained projects to take market share from older and more established libraries if th…

I feel like most things that will benefit from moving to multiple cores for performance should probably not be written in Python. OTH "most" is not "all" so it's gonna be awesome for some.

I never understand this sentiment, that shows up in every topic on python. Who descides why something should or should not be written I Python?

Why shouldn't someone who prefers writing in python benefit from using multiple cores?

Re: Free-threaded CPython is ready to experiment with

#389

Post by fastasucan »

noisy_boy wrote: post #149
VeejayRampay wrote: post #35

Earlier quoted context omitted.

the efficient dependency management is coming, the good people of astral will take care of that with the uv-backed version of rye (initially created by Armin Ronacher with inspirations from Cargo), I'm really confident it'll be good like ruff and uv were good

rye's habit of insisting on creating a .venv per project is a deal-breaker. I don't want .venvs spread all over my projects eating into space (made worse by the ml/LLM related mega packages). It should atleast respect activated venvs.

I think uv's use of a global cache means that having several .venv with the same packages is less of a problem.

Re: Free-threaded CPython is ready to experiment with

#390

Post by phkahler »

jodrellblank wrote: post #182
phkahler wrote: post #25

Earlier quoted context omitted.

I feel like most things that will benefit from moving to multiple cores for performance should probably not be written in Python. OTH "most" is not "all" so it's gonna be awesome for some.

https://www.servethehome.com/wp-content/uploads/2023/01/Inte... AMD EPYC 9754 with 128-cores/256-threads, and EPYC 9734 with 112-cores/224-threads. TomsHardware says they "will compete with Intel's 144-core Sierra Forest chips, which mark the debut of Intel's Efficiency cores (E-cores) in its Xeon data center lineup, and Ampre's 192-core AmpereOne processors". What in 5 years? 10? 20? How long will "1 core should be…

>> What in 5 years? 10? 20? How long will "1 core should be enough for anyone using Python" stand?

If you're looking for a 32x or 128x performance improvement from python supporting multi-core you should probably rewrite in C, C++, Rust, or Fortran and get that 100x improvement today on a single core. If done properly you can then ALSO get the gain from multiple cores on top of that. Or to put it another way, if performance is critical python is a poor choice.

Post reply on HN