Live data from Hacker News

Free-threaded CPython is ready to experiment with

labs.quansight.org

21–30 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#21
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.…

Optional static typing is just like a comment (real term is annotation) of the input variable(s) and return variable(s). No optimization is performed. Using a tool such as mypy that kicks off on a CI/CD process technically enforces types but they are ignored by the interpreter unless you make a syntax error.

A language server in your IDE kicks in much earlier, and is even more helpful.

Re: Free-threaded CPython is ready to experiment with

#22
post #9

Earlier quoted context omitted.

Not sure what this list means, there are successful languages without these feature. Also Python 3.13 [1] has an optional JIT [2], disabled by default. [1] https://docs.python.org/3.13/whatsnew/3.13.html [2] https://peps.python.org/pep-0744/

The successful languages without efficient dependency management are painful to manage dependencies in, though. I think Python should be shooting for a better package management user experience than C++.

Not sure this is still a valid critic of Python in 2024.

Between pip, poetry and pyproject.toml, things are now quite good IMHO.

Re: Free-threaded CPython is ready to experiment with

#23
My body is ready. I love python because the ease of writing and logic. Hopefully the more complicated free-threaded approach is comprehensive enough to write it like we traditionally write python. Not saying it is or isn't I just haven't dived enough into python multithreading because it is hard to put those demons back once you pull them out.

Re: Free-threaded CPython is ready to experiment with

#24
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.

Re: Free-threaded CPython is ready to experiment with

#25

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.

Re: Free-threaded CPython is ready to experiment with

#26
post #4

It has been ready for a few months now, at least since 3.13.0 beta 1 which released on 2024-05-08, although alpha versions had it working too. I don't know why this is news now . With it, the single-threaded case is slower.

FTA: "Yesterday, py-free-threading.github.io launched! It's both a resource with documentation around adding support for free-threaded Python, and a status tracker for the rollout across open source projects in the Python ecosystem."

Before the article came the misleading title: "Free-threaded CPython is ready to experiment with".

The link should have been to https://py-free-threading.github.io/tracking/

Re: Free-threaded CPython is ready to experiment with

#27
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.

To my understanding there is and there isn't. The driving force behind this demonstrated that it was possible to speed up the existing CPython interpreter by more than the performance cost of free threading with changes to the allocator and various other things.

So the net is actually a small performance win but lesser than if there was no free threading. That said, many of the techniques he identified were immediately incorporated into CPython and so I would expect benchmarks to show some regression as compared with the single threaded interpreter of the previous revision.

Re: Free-threaded CPython is ready to experiment with

#28

My body is ready. I love python because the ease of writing and logic. Hopefully the more complicated free-threaded approach is comprehensive enough to write it like we traditionally write python. Not saying it is or isn't I just haven't dived enough into python multithreading because it is hard to put those demons back once you pull them out.

Precisely, ease of writing, not ease of reading (the whole project, not just a tiny snippet of code) or supporting it long-term.

Re: Free-threaded CPython is ready to experiment with

#29
post #5

It has been ready for a few months now, at least since 3.13.0 beta 1 which released on 2024-05-08, although alpha versions had it working too. I don't know why this is news now . With it, the single-threaded case is slower.

This release coincides with the SciPy 2024 conference and a number of other things. I would suggest reading the article to learn more.

> This release

What release. The last release of CPython was 3.13.0b3 on 2024-06-27.

SciPy is irrelevant to the title.

Re: Free-threaded CPython is ready to experiment with

#30
post #22
post #9

Earlier quoted context omitted.

The successful languages without efficient dependency management are painful to manage dependencies in, though. I think Python should be shooting for a better package management user experience than C++.

Not sure this is still a valid critic of Python in 2024. Between pip, poetry and pyproject.toml, things are now quite good IMHO.

All is well, then, one day, you have to update one library.

Some days later, in some woods or cave, people will hear your screams of rage and despair.

Post reply on HN