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

151–160 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#151

Post by pansa2 »

pansa2 wrote: post #137

PEP703 explains that with the GIL removed, operations on lists such as `append` remain thread-safe because of the addition of per-list locks. What about simple operations like incrementing an integer? IIRC this is currently thread-safe because the GIL guarantees each bytecode instruction is executed atomically.

Ah, `i += 1` isn’t currently thread-safe because Python does (LOAD, +=, STORE) as 3 separate bytecode instructions.

I guess the only things that are a single instruction are some modifications to mutable objects, and those are already heavyweight enough that it’s OK to add a per-object lock.

Re: Free-threaded CPython is ready to experiment with

#152

Post by kortex »

andmkl wrote: post #134

[flagged]

Many uses. There's tons of situations where you are already accelerating most of your heavy compute with tensor libraries, but the data input/output parts are still in python. They would benefit from loading data in parallel before batching.

Multiprocess, OS threads, and asyncio all solve different problems. Threads are pretty heavyweight compared to async coroutines (aka green threads). The big win with coroutines is it is very cheap to put them to sleep waiting on io. So a web server on a 4 core vm might have 4 worker processes, several threads per process, and dozens/hundreds of coroutines.

> So perhaps you can use this for slurping other people's IP in parallel and train the "AIs" that are supposed to make us redundant.

This has absolutely nothing to do with the technical merits of async or threads. For one, the above two examples are taken directly from work I did to combat deep fakes by identifying various "tells" from the media. Some of us are in fact using machine learning for good.

Re: Free-threaded CPython is ready to experiment with

#153

Post by woodson »

ipsod wrote: post #138
andmkl wrote: post #122

Earlier quoted context omitted.

Yes, but then extensions can already release the GIL and use the simple and industrial strength std::thread, which is orders of magnitude easier to debug.

Really? Cool. I expected that dropping down to C/C++ would be a large jump in difficulty and quantity of code, but I've found it isn't, and the dev experience isn't entirely worse, as, for example, in-editor code-intelligence is rock solid and very fast in every corner of my code and the libraries I'm using. If anyone could benefit from speeding up some Python code, I'd highly recommend installing cppyy and giving it…

Thanks, I haven’t come across cppyy! But I’ve worked with pybind11, which works well, too.

Re: Free-threaded CPython is ready to experiment with

#154

Post by [deleted] »

DanielVZ wrote: post #55
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.

Usually performance critical code is written in cpp, fortran, etc, and then wrapped in libraries for Python. Python still has a use case for glue code.

[deleted]

Re: Free-threaded CPython is ready to experiment with

#155

Post by pdonis »

stavros wrote: post #150
pdonis wrote: post #130

Earlier quoted context omitted.

The GIL does not prevent race conditions in your Python code. It only prevents race conditions in internal data structures inside the interpreter and in atomic operations, i.e., operations that take a single Python bytecode. But many things that appear atomic in Python code take more than one Python bytecode. The GIL gives you no protection if you do such operations in multiple threads on the same object.

I answered in a sibling reply: https://news.ycombinator.com/item?id=40950798

I'll respond there.

Re: Free-threaded CPython is ready to experiment with

#156

Post by dgfitz »

stavros wrote: post #145
dgfitz wrote: post #142

Earlier quoted context omitted.

I pip3 installed something today. It didn’t work, at all. I then yum installed a lib and headers, it worked well. C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.

If I had a penny for every time I gave up on compiling C++ software because there's no way to know what dependencies it needs, I'd be a millionaire. Python at least lists them.

If I had a penny every time I heard something like that on sites like this, I’d be a billionaire :)

Re: Free-threaded CPython is ready to experiment with

#157

Post by yupyupyups »

dgfitz wrote: post #142
stavros wrote: post #89

Earlier quoted context omitted.

That was the entire point, that C++ is the absolute worst.

I pip3 installed something today. It didn’t work, at all. I then yum installed a lib and headers, it worked well. C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.

Mac has the Brew project, which is sort of like apt-get or yum.

Re: Free-threaded CPython is ready to experiment with

#158

Post by pdonis »

stavros wrote: post #133
dagenix wrote: post #131

Earlier quoted context omitted.

Are you writing an extension or Python code? If you are writing Python code, the GIL can already be dropped at pretty much any point and there isn't much way of controlling when. Iirc, this includes in the middle of things like +=. There are some operations that Python defines as atomic, but, as I recall, there aren't all that many. In what way is the GIL preventing races for your use case?

I mean that, if the GIL didn't prevent races, it would be trivially removable. Races that are already there in people's Python code have probably been debugged (or at least they are tolerated), so there are some races that will happen when the GIL is removed, and they will be a surprise.

> if the GIL didn't prevent races, it would be trivially removable

Nobody is saying the GIL doesn't prevent races at all. We are saying that the GIL does not prevent races in your Python code. It's not "trivially removable" because it does prevent races in the interpreter's internal data structures and in operations that are done in a single Python bytecode, and there are a lot of possible races in those places.

Also, perhaps you haven't considered the fact that Python provides tools such as mutexes, locks, and semaphores to help you prevent races in your Python code. Python programmers who do write multi-threaded Python code (for example, code where threads spend most of their time waiting on I/O, which releases the GIL and allows other threads to run) do have to use these tools. Why? Because the GIL by itself does not prevent races in your Python code. You have to do it, just as you do with multi-threaded code in any language.

> Races that are already there in people's Python code have probably been debugged

Um, no, they haven't, because they've never been exposed to multi-threading. Most people's Python code is not written to be thread-safe, so it can't safely be parallelized as it is, GIL or no GIL.

Re: Free-threaded CPython is ready to experiment with

#159

Post by pdonis »

dagenix wrote: post #146
stavros wrote: post #133

Earlier quoted context omitted.

I mean that, if the GIL didn't prevent races, it would be trivially removable. Races that are already there in people's Python code have probably been debugged (or at least they are tolerated), so there are some races that will happen when the GIL is removed, and they will be a surprise.

The GIL prevents the corruption of Pythons internal structures. It's hard to remove because: 1. Lots of extensions, which can control when they release the GIL unlike regular Python code, depend on it 2. Removing the GIL requires some sort of other mechanism to protect internal Python stuff 3. But for a long time, such a mechanism was resisted by th Python team because all attempts to remove the GIL either made singl…

> removing the GIL isn't expected to really impact pure Python code.

If your Python code assumes it's just going to run in a single thread now, and it is run in a single thread without the GIL, yes, removing the GIL will make no difference.

Re: Free-threaded CPython is ready to experiment with

#160

Post by nvy »

j1elo wrote: post #108
BugsJustFindMe wrote: post #45

Earlier quoted context omitted.

Working with asyncio sucks when all you want is to be able to do some things in the background, possibly concurrently. You have to rewrite the worker code using those stupid async await keywords. It's an obnoxious constraint that completely breaks down when you want to use unaware libraries. The thread model is just a million times easier to use because you don't have to change the code.

So, in Rust they had threading since forever and they are now hyped with this new toy called async/await (and all the new problems it brings), while in Python they've had async/await and are now excited to see the possibilities of this new toy called threads (and all its problems). That's funny!

Being hyped for is totally on-brand for the Rust community.
Post reply on HN