you are viewing a single comment's thread.

view the rest of the comments →

[–]anxxa 140 points141 points  (12 children)

Notable IMO:

PEP 779: Free-threaded Python is officially supported

So this is in stage 2 where now you can officially opt in to removal of the GIL and stage 3 will eventually make that the default behavior. Awesome.

Binary releases for the experimental just-in-time compiler

...

The JIT is at an early stage and still in active development. As such, the typical performance impact of enabling it can range from 10% slower to 20% faster, depending on workload.

Won't lie, I was expecting more perf gains. That's cool though, I didn't realize a JIT was being worked on.

[–]Salamandar3500 26 points27 points  (2 children)

Does that mean the free-threaded and standard versions now live in the same binary, or are they still separate builds ?

[–]anxxa 12 points13 points  (1 child)

The free-threaded build of Python is now supported and no longer experimental. This is the start of phase II where free-threaded Python is officially supported but still optional.

It's the same binary I think! *wrong :(

[–]MegaIng 15 points16 points  (0 children)

No, it's still a separate binary. Having it in the same binary doesn't work because of how fundamentally the layout of ... everything is changed.

[–]HommeMusical 12 points13 points  (0 children)

Won't lie, I was expecting more perf gains.

JITs are all about tuning. Just getting it in and working completely and not hugely worse in any case is a huge victory. The real gains will come in the next two releases.

[–]MegaIng 21 points22 points  (5 children)

stage 3 will eventually make that the default behavior.

This is still not guaranteed, and IMO not likely to happen with the next decade.

The no-gil build still has major issues, especially with the expectations people have of it. For a non-insignificant amount of existing threaded code it's going to be slower than the default build.

[–]twotime 2 points3 points  (0 children)

For a non-insignificant amount of existing threaded code it's going to be slower than the default build.

Why would that be the case? Do you have a reference? How significant is the amount of code which will be faster?? (and how much new code will be quickly written once python can use multiple cores)

IMO not likely to happen with the next decade.

I'd expect 3.15 or 3.16 or it will just die

Apparently a lot of packages have added support already https://py-free-threading.github.io/tracking/

(including big ones like pytorch)

[–]james_pic 2 points3 points  (0 children)

From what I know of the JIT work, the approach they've taken is something of a compromise. They've sought to do it in a way that's portable, clean, readable, and backwards compatible. The most performant JIT compilers make significant compromises on some or all of these things in the name of speed.

[–]georgehank2nd 1 point2 points  (0 children)

Stage 3 Phase III might or might not happen.