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

191–200 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#191

Post by Derbasti »

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.

A thought experiment:

A piece of code takes 6h to develop in C++, and 1h to run.

The same algorithm takes 3h to code in Python, but 6h to run.

If I could thread-spam that Python code on my 24 core machine, going Python would make sense. I've certainly been in such situations a few times.

Re: Free-threaded CPython is ready to experiment with

#192

Post by quotemstr »

sveiss wrote: post #18
GTP wrote: post #11

Earlier quoted context omitted.

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system.…

The parser supports the type hint syntax, and the standard library provides various type hint related objects. So you can do things like “from typing import Optional” to bring Optional into scope, and then annotate a function with -> Optional[int] to indicate it returns None or an int. Unlike a system using special comments for type hints, the interpreter will complain if you make a typo in the word Optional or don’t…

> In practice it’s quite usable

It would be super helpful if the interpreter had a type-enforcing mode though. All the various external runtime enforcement packages leave something to be desired.

Re: Free-threaded CPython is ready to experiment with

#193

Post by saagarjha »

fuzztester wrote: post #163
fuzztester wrote: post #106

Earlier quoted context omitted.

[flagged]

[flagged]

They’re probably downvoting you because you’ve posted like the laziest trope comment there is. lol Python slow everyone is paid to hide the truth amirite

Re: Free-threaded CPython is ready to experiment with

#194

Post by d0mine »

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…

Number crunching code in Python (such as using numpy/pytorch) performs the vast vast majority of its calculations in C/Fortran code under the hood where GIL can be released. Single python process can use multiple CPUs.

There is code that may benefit from the free threaded implementation but it is not as often as it might appear and it is not without its own downsides. In general, GIL simplifies multithreaded code.

There were no-GIL Python implementations such as Jython, IronPython. They hadn't replaced CPython, Pypy implementation which use GIL i.e., other concerns dominate.

Re: Free-threaded CPython is ready to experiment with

#195

Post by bdd8f1df777b »

rty32 wrote: post #99
MBCook wrote: post #51

Earlier quoted context omitted.

But it would give you more headroom before rewriting for performance would make sense right? That alone could be beneficial to a lot of people.

I think it is beneficial to some people, but not a lot. My guess is that most Python users (from beginners to advanced users, including many professional data scientists) have never heard of GIL or thought of doing any parallelization in Python . Code that needs performance and would benefit from multithreading, usually written by professional software engineers, likely isn't written in Python in the first place. It…

> Code that needs performance and would benefit from multithreading, usually written by professional software engineers, likely isn't written in Python in the first place.

There are a lot of simple cases where multi-threading can easily triple or quadruple the performance.

Re: Free-threaded CPython is ready to experiment with

#196

Post by d0mine »

dagenix wrote: post #131
stavros wrote: post #118

Earlier quoted context omitted.

Not when there's a global interpreter lock.

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?

It is not about your code, it is about C extensions you are relying on. Without GIL, you can't even be sure that refcounting works reliably. Bugs in C extensions are always possible. No GIL makes them more likely. Even if you are not the author of C extension, you have to debug the consequences.

Re: Free-threaded CPython is ready to experiment with

#197

Post by nhumrich »

nine_k wrote: post #6

Python 3 progress so far: [x] Async. [x] Optional static typing. [x] Threading. [ ] JIT. [ ] Efficient dependency management.

Python 3.12 introduces a little bit of JIT. Also, there is always pypy.

For efficient dependency management, there is now rye and UV. So maybe you can check all those boxes?

Re: Free-threaded CPython is ready to experiment with

#198

Post by nhumrich »

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.

Irrelevant, because even if there was, you would use the normal GIL python for it.

Re: Free-threaded CPython is ready to experiment with

#199

Post by d0mine »

BugsJustFindMe wrote: post #53
hot_gril wrote: post #49

Earlier quoted context omitted.

Asyncio is designed for things like webservers or UIs where some framework is probably already handling the main event loop. What are you doing where you just want to run something else in the background, and IPC isn't good enough?

Non-blocking HTTP requests is an extremely common need, for instance. Why the hell did we need to reinvent special asyncio-aware request libraries for it? It's absolute madness. Thread pools are much easier to work with. > where some framework is probably already handling the main event loop This is both not really true and also irrelevant. When you need a flask (or whatever) request handler to do parallel work, asyn…

Ordinary CPython code releases GIL during blocking I/O. You can do http requests + thread pool in Python.

Re: Free-threaded CPython is ready to experiment with

#200

Post by dagenix »

pdonis wrote: post #188
dagenix wrote: post #184

Earlier quoted context omitted.

> But there is a lot of pure Python code out there that is not written that way. Removal of the GIL would allow such code to be naively run in multiple threads using, for example, Python's support for thread pools. I guess this is what I don't understand. This code could already be run in multiple threads today, with a GIL. And it would be broken - in all the same ways it would be broken without a GIL, correct? > Any…

> This code could already be run in multiple threads today, with a GIL. Yes. > And it would be broken - in all the same ways it would be broken without a GIL, correct? Yes, but the absence of the GIL would make race conditions more likely to happen. > is your point that removing the GIL will cause people to take non-multithread code and run it in multiple threads without realizing that it is broken in that context? Y…

> Yes, but the absence of the GIL would make race conditions more likely to happen.

Does it though? I'm not saying it doesn't, I'm quite curious. Switching between threads with the GIL is already fairly unpredictable from the perspective of pure-Python code. Does it get significantly more troublesome without the GIL?

> Yes. They could run it in multiple threads with the GIL today, but as above, race conditions might not show up as often, so it might not be realized that the code is broken. But also, with the GIL there is the common perception that Python doesn't do multithreading well anyway, so it's less likely to be used for that. With the GIL removed, I suspect many people will want to use multithreading a lot more in Python to parallelize code, without fully realizing the implications.

Fair

Post reply on HN