The first year of free-threaded Python

Post by jillesvangurp » Tue, May 20, 2025, 6:57 AM UTC

tgv wrote: post #271

jillesvangurp wrote: post #23

Earlier quoted context omitted.

You are not the only one who is afraid of changes and a bit change resistant. I think the issue here is that the reasons for this fear are not very rational. And also the interest of the wider community is to deal with technical debt. And the GIL is pure technical debt. Defensible 30 years ago, a bit awkward 20 years ago, and downright annoying and embarrassing now that world + dog does all their AI data processing w…

> Nothing unless you start using threads. Isn't it also promises/futures? They might start threads implicitly.

Why would you use those without threads?

Post by kragen » Fri, May 23, 2025, 7:25 PM UTC

duped wrote: post #299

kragen wrote: post #250

Earlier quoted context omitted.

On a 64-core machine, Python code that uses all the cores will be modestly faster than single-threaded C, even if all the inner loops are in Python. If you can move the inner loops to C, for example with Numpy, you can do much better still. (Python is still harder to get right than something like C or OCaml, of course, especially for larger programs, but often the smaller amount of code and quicker feedback loop can…

I strongly doubt this claim. Python is more than 64x slower than C without synchronization overhead in most numeric tasks, with synchronization overhead on those processes it should be much worse. Python is so much slower than any native or JIT compiled language that it begets things like numpy in the first place.

My typical experience is about 40×.

Re: The first year of free-threaded Python

Re: The first year of free-threaded Python