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

121–130 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#121

Post by nine_k »

guhidalg wrote: post #82
simonw wrote: post #67

Earlier quoted context omitted.

"I don't want a bunch of venvs" That's your problem right there. Virtual environments are the Python ecosystem's solution to the problem of wanting to install different things on the same machine that have different conflicting requirements. If you refuse to use virtual environments and you install more than one separate Python project you're going to run into conflicting requirements and it's going to suck. Have you…

Normal users who just want to run some code shouldn't need to learn why they need a venv or any of its alternatives. Normal users just want to download a package and run some code without having to think about interfering with other packages. Many programming languages package managers give them that UX and you can't blame them for expecting that from Python. The added step of having to think about venvs with Python…

This is correct. The whole application installation process, including the creation of a venv, installing stuff into it, and registering it with some on-PATH launcher should be one command.

BTW pyenv comes relatively close.

Re: Free-threaded CPython is ready to experiment with

#122

Post by andmkl »

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.

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.

Re: Free-threaded CPython is ready to experiment with

#123

Post by eigenvalue »

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.

I personally optimize more for development time and overall productivity in creating and refactoring, adding new features, etc. I'm just so much faster using Python than anything else, it's not even close. There is such an incredible world of great libraries easily available on pip for one thing.

Also, I've found that ChatGPT/Claude3.5 are much, much smarter and better at Python than they are at C++ or Rust. I can usually get code that works basically the first or second time with Python, but very rarely can do that using those more performant languages. That's increasingly a huge concern for me as I use these AI tools to speed up my own development efforts very dramatically. Computers are so fast already anyway that the ceiling for optimization of network oriented software that can be done in a mostly async way in Python is already pretty compelling, so then it just comes back again to developer productivity, at least for my purposes.

Re: Free-threaded CPython is ready to experiment with

#124

Post by andmkl »

ngoldbaum wrote: post #24
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.

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.

That would be in the order of previous GIL-removal projects, which were abandoned for that reason.

Re: Free-threaded CPython is ready to experiment with

#125

Post by LegionMammal978 »

nilamo wrote: post #113
hot_gril wrote: post #92

Earlier quoted context omitted.

Basically true in JS too. You're not supposed to do blocking calls in async code. You also can't "await" an async call inside a non-async func, though you could fire-and-forget it. Right, but how often does a Python program have complex shared state across threads, rather than some simple fan-out-fan-in, and also need to take advantage of multiple cores?

The primary thing that tripped me up about async/await, specifically only in Python, is that the called function does not begin running until you await it. Before that moment, it's just an unstarted generator. To make background jobs, I've used the class-based version to start a thread, then the magic method that's called on await simply joins the thread. Which is a lot of boilerplate to get a little closer to how as…

Rust's version of async/await is the same in that respect, where futures don't do anything until you poll them (e.g., by awaiting them): if you want something to just start right away, you have to call out to the executor you're using, and get it to spawn a new task for it.

Though to be fair, people complain about this in Rust as well. I can't comment much on it myself, since I haven't had any need for concurrent workloads that Rayon (a basic thread-pool library with work stealing) can't handle.

Re: Free-threaded CPython is ready to experiment with

#126

Post by simonw »

arp242 wrote: post #80
simonw wrote: post #67

Earlier quoted context omitted.

"I don't want a bunch of venvs" That's your problem right there. Virtual environments are the Python ecosystem's solution to the problem of wanting to install different things on the same machine that have different conflicting requirements. If you refuse to use virtual environments and you install more than one separate Python project you're going to run into conflicting requirements and it's going to suck. Have you…

Managing a farm of virtualenvs and mucking about with my PATH doesn't address the user-installable problem at all. And it seems there's a new tool to try every few months that really will fix all problems this time. And maybe if you're a Python developer working on the code every day that's all brilliant. But most people aren't Python developers, and I just want to try that "Show HN" project or whatnot. Give me a sin…

"Give me a single command I can run. Always. For any project. And that always works."

    pipx install X

Re: Free-threaded CPython is ready to experiment with

#127

Post by simonw »

guhidalg wrote: post #82
simonw wrote: post #67

Earlier quoted context omitted.

"I don't want a bunch of venvs" That's your problem right there. Virtual environments are the Python ecosystem's solution to the problem of wanting to install different things on the same machine that have different conflicting requirements. If you refuse to use virtual environments and you install more than one separate Python project you're going to run into conflicting requirements and it's going to suck. Have you…

Normal users who just want to run some code shouldn't need to learn why they need a venv or any of its alternatives. Normal users just want to download a package and run some code without having to think about interfering with other packages. Many programming languages package managers give them that UX and you can't blame them for expecting that from Python. The added step of having to think about venvs with Python…

I agree with that. Until we solve that larger problem, people need to learn to use virtual environments, or at least learn to install Python tools using pipx.

Re: Free-threaded CPython is ready to experiment with

#128

Post by ipsum2 »

jmward01 wrote: post #105

I know, I know, 'not every story needs to be about ML' but.... I can only imagine how unlocking the GIL will change the nature of ML training and inference. There is so much waste and complexity in passing memory around and coordinating processes. I know that libraries have made it (somewhat) easier and more efficient but I can't wait to see what can be done with things like pytorch when optimized for this.

It'll mostly help for debugging and lowering RAM (not VRAM) usage. Otherwise it won't impact ML much.

Re: Free-threaded CPython is ready to experiment with

#129

Post by infamia »

VeejayRampay wrote: post #37
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.…

python will never be "properly typed" what it has is "type hints" which is way to have richer integration with type checkers and your IDE, but will never offer more than that as is

> what it has is "type hints" which is way to have richer integration with type checkers and your IDE, but will never offer more than that as is

Python is strongly typed and it's interpreter is type aware of it's variables, so you're probably overreaching with that statement. Because Python's internals are type aware, it's how folks are able to create type checkers like mypy and pydantic both written in Python. Maybe you're thinking about TS/JSDoc, which is just window dressing for IDEs to display hints as you described?

Re: Free-threaded CPython is ready to experiment with

#130

Post by pdonis »

stavros wrote: post #118
dagenix wrote: post #97

Earlier quoted context omitted.

As I understand it, if your code would have race conditions with free threaded python, than it probably already has them.

Not when there's a global interpreter lock.

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.
Post reply on HN