Scaling NumPy on Free-Threaded Python
labs.quansight.org
Scaling NumPy on Free-Threaded Python
1–10 of 27 posts
Re: Scaling NumPy on Free-Threaded Python
#2Re: Scaling NumPy on Free-Threaded Python
#3Re: Scaling NumPy on Free-Threaded Python
#4[flagged]
Re: Scaling NumPy on Free-Threaded Python
#5I 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.
Re: Scaling NumPy on Free-Threaded Python
#6[flagged]
Re: Scaling NumPy on Free-Threaded Python
#7[flagged]
Perhaps, however, this hacky language is more productive in the real world than most. What’s the point, otherwise?
- As the GP stated, the thrill of hidden bugs.
- Feeling productive due to fixing eternal issues.
- Getting paid to fix eternal issues.
- Feeling smart by talking about unnecessary issues.
- Writing a constant stream of PEPs to fix issues.
- Give conference talks about how you fixed issues.
- Give conference talks about how you will speed up Python by 5%.
Re: Scaling NumPy on Free-Threaded Python
#8Unclear 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".
Re: Scaling NumPy on Free-Threaded Python
#9Re: Scaling NumPy on Free-Threaded Python
#10I 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.
https://en.wikipedia.org/wiki/Amdahl%27s_law
Even a tiny bit of serial instruction will limit the speed up