Scaling NumPy on Free-Threaded Python
Quansight Labs explores the challenges and opportunities of scaling NumPy on free-threaded Python, a build that removes the Global Interpreter Lock (GIL). The post details the current state of NumPy's support for free-threading, the performance implications, and the ongoing work to enable efficient parallel execution. It highlights the potential for significant speedups in numerical computing, while acknowledging the complexities involved in making NumPy thread-safe.
The free-threaded build of Python is a major step toward enabling true parallelism, and NumPy is at the forefront of this transition.
- wiz21c
I know this is more or less expected, but the improvement induced by adding a worker diminishes very rapidly... I guess it's not the cpython/numpy's fault but rather the CPU.
- tialaramex
> only acquire the lock when the flag needs to be updated
Unclear why you still need the lock here in that case. The idea that this flag may get updated during runtime and impacts how the software works when set seems to clash with the idea we need take no action having performed a relaxed (ie non-synchronising) load and seen it wasn't set at some previous time.
Maybe there's something I don't understand about these internals, which may be as simple as "It's just advisory so if we don't trace when we should no big deal".
- w-m
This is well-written. I could follow along quite nicely, from the setup through the bottlenecks and onto the resolution of the performance bug. Even the PRs are very pleasant to read: the majority of them is just a handful of changed lines with an added tests and a bit of documentation.
I was taken aback for a moment that this work originated from a report on StackOverflow. I had thought SO was effectively dead and abandoned by its community. But maybe I shouldn't project my own experience onto everyone else.