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

321–330 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#321

Post by imtringued »

ipsum2 wrote: post #128
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.

Yeah, one of the dumbest things about Dataloaders running in a different process is that you are logging into the void.

Re: Free-threaded CPython is ready to experiment with

#322

Post by imtringued »

vulnbludog wrote: post #257
pansa2 wrote: post #247

Earlier quoted context omitted.

No-GIL Python is still interpreted - single-threaded performance is slower that standard Python, which is in turn much slower than the languages you mentioned. Maybe if you’ve got an embarrassingly parallel problem, and dozen(s) of cores to spare, you can match the performance of a single-threaded JIT/AOT compiled program.

How do companies like Instagram/OpenAI scale with a majority python codebase? Like I just kick it on HN idk much about computers or coding (think high school CS) why wouldn’t they migrate can someone explain like I’m five

They have tools like Triton that compile a restricted subset to CUDA.

Re: Free-threaded CPython is ready to experiment with

#323

Post by lyu07282 »

bausgwi678 wrote: post #249
pizza234 wrote: post #231

Earlier quoted context omitted.

> using simple threads instead of dealing with the massive overhead and complexity and bugs of using something like multiprocessing. Depending on the domain, the reality can be the reverse. Multiprocessing in the web serving domain, as in "spawning separate processes", is actually simpler and less bug-prone, because there is considerably less resource sharing. The considerably higher difficulty of writing, testing an…

Using multiple processes is simpler in terms of locks etc, but python libraries like multiprocessing or even subprocess.popen[1] which make using multiple processes seem easy are full of footguns which cause deadlocks due to fork-safe code not being well understood. I’ve seen this lead to code ‘working’ and being merged but then triggering sporadic deadlocks in production after a few weeks. The default for multiproce…

Same experiences, multiprocessing is such a pain in python. It's one of these things people think they can write production code in, but they just haven't run into all the ways their code was wrong so they figure out those bugs later in production.

As an aside I still constantly see side effects in imports in a ton of libraries (up to and including resource allocations).

Re: Free-threaded CPython is ready to experiment with

#324

Post by lyu07282 »

skissane wrote: post #237
pizza234 wrote: post #231

Earlier quoted context omitted.

> using simple threads instead of dealing with the massive overhead and complexity and bugs of using something like multiprocessing. Depending on the domain, the reality can be the reverse. Multiprocessing in the web serving domain, as in "spawning separate processes", is actually simpler and less bug-prone, because there is considerably less resource sharing. The considerably higher difficulty of writing, testing an…

Just the other day I was trying to do two things in parallel in Python using threads - and then I switched to multiprocessing - why? I wanted to immediately terminate one thing whenever the other failed. That’s straightforwardly supported with multiprocessing. With threads, it gets a lot more complicated and can involve things with dubious supportability

There is a reason why it's "complicated" in threads, because doing it correctly just IS complicated, and the same reason applies to child processes, you just ignored that reason. That's one example of a footgun in using multiprocessing, people write broken code but they don't know that because it appears to work... until it doesn't (in production on friday night).

Re: Free-threaded CPython is ready to experiment with

#325

Post by throwaway81523 »

pansa2 wrote: post #248
hiddew wrote: post #245

Earlier quoted context omitted.

> The reason we can’t, and why `async`/`await` exist, is because of shortcomings (lack of support for stackful coroutines) in language runtimes The JVM runtime has solved this problem neatly with virtual threads in my opinion. Run a web request in a virtual thread, and all blocking I/O is suddenly no longer blocking the OS thread, but yielding/suspending and giving and giving another virtual thread run time. And all…

Yes, this is similar to how Go works. IIRC the same approach was available in Python as a library, “greenlet”, but Python’s core developers rejected it in favour of `async`/`await`.

The Python community seems to have a virulent hatred of threads. I don't understand the reason. Yes there are hazards but you can code in a style that avoids them. With something like BEAM you can even enforce the style. Async/await of course introduce their own hazards.

Re: Free-threaded CPython is ready to experiment with

#326

Post by [deleted] »

mondrian wrote: post #287
zarzavat wrote: post #277

Earlier quoted context omitted.

> Those type hints are not used at runtime for performance. This is not a requirement for a language to be statically typed. Static typing is about catching type errors before the code is run. > Type hint a var as a string then set it to an int, that code still gonna try to execute. But it will fail type checking, no?

The critique is that "static typing" is not really the right term to use, even if preceded by "optional". "Type hinting" or "gradual typing" maybe. In static typing the types of variables don't change during execution.

[deleted]

Re: Free-threaded CPython is ready to experiment with

#327

Post by VagabundoP »

Highly recommend the core.py podcast if you're interested in the background, there are a few episodes that focus on the GILectomy:

-Episode 2: Removing the GIL[1]

-Episode 12: A Legit Episode[2]

[1]https://www.youtube.com/watch?v=jHOtyx3PSJQ&list=PLShJCpYUN3...

[2]https://www.youtube.com/watch?v=IGYxMsHw9iw&list=PLShJCpYUN3...

Re: Free-threaded CPython is ready to experiment with

#328

Post by kstrauser »

hot_gril wrote: post #307
kstrauser wrote: post #291

Earlier quoted context omitted.

That's the kind of thing I stumble across all the time. Indexing all the symbols in a codebase: results = Counter() for file in here.glob('*.py'): symbols = parse(file) results.update(symbols) Scanning image metadata: for image in here.glob('*.png'): headers = png.Reader(image) ... Now that I think about it, most of my use cases involve doing expensive things to all the files in a directory, but in ways where it'd be…

These are "embarassingly parallel" examples that multiprocessing is ok for, though. There was always the small caveat that you can't pickle a file handle, but it wasn't a real problem. Threads are more useful if you have lots of shared state and mutexes. I think these examples would also perform well with GIL'd threads, since the actual Python part is just waiting on blocking calls that do the expensive work. But may…

> Threads are more useful if you have lots of shared state and mutexes.

That's what always kicks me in such things. If the processes are truly completely separable, awesome! It never seems like they are as much as I wish they were.

Re: Free-threaded CPython is ready to experiment with

#329

Post by mixmastamyk »

GTP wrote: post #301
mixmastamyk wrote: post #174

Earlier quoted context omitted.

> you can't tell what a function does just by looking at it You just did tell us what it does by looking at it, for the 90% case at least. It might be useful to throw two lists in there as well. Throw a custom object in there? It will work if you planned ahead with dunder add and radd. If not fix, implement, or roll back.

> You just did tell us what it does by looking at it, for the 90% case at least The problem is that you can't know if the function is going to do what you want it to do without also looking at the context in which it is used. And what you pass as input could be dependent on external factors that you don't control. So I prefer the languages that let me know what happens in 100% of the cases.

Protection from untrusted input is something that has to be considered in any language.

Not yet been a real world concern in my career, outside webforms, which are handled by framework.

Re: Free-threaded CPython is ready to experiment with

#330

Post by VagabundoP »

arp242 wrote: post #56
Galanwe wrote: post #22

Earlier quoted context omitted.

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

I guess that depends from your perspective. I'm not a Python developer, but like many people I do want to run Python programs from time to time. I don't really know Rust, or Cargo, but I never have trouble building any Rust program: "cargo build [--release]" is all I need to know. Easy. Even many C programs are actually quite easy: "./configure", "make", and optionally "make install". "./configure" has a nice "--help…

Its more probable that you are trying to install the deps in the system python. And using pip instal xxxxx -u will install them in your user directory rather than the system. I'm pretty sure modern Ubuntu warns you against doing that now anyway.

If you're installing for a small script then doing python -m venv little_project in you home dir is straightforward, just active it after [1]

I'm using rye[2] now and its very similar to Rust's Cargo, it wraps a bunch of the standard toolchain and manages standalone python versions in the background, so doesn't fall into the trap of linux system python issues.

[1]https://docs.python.org/3/library/venv.html [2]https://rye.astral.sh/

Post reply on HN