11–20 of 27 posts
[flagged]
[flagged]
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.
The more fundamental reason is Amdahl's law https://en.wikipedia.org/wiki/Amdahl%27s_law Even a tiny bit of serial instruction will limit the speed up
Every doubling of the number of workers halves the execution time cleanly in the plot, from 40 seconds to 20 seconds to 10 seconds. Eyeballing this for 32 over 16 workers is difficult, but it still seems close to halving the total time once again. So there's not a lot of Amdahl flattening, it's just the plain physics of looking at a inverse-proportional curve.
I thought NumPy was already releasing the GIL. On regular non-free-threaded Python, you can run threaded parallel Numpy operations and have multiple cores doing 100%, I've relied on that. Maybe not the case with the operations this article focuses on (sin/cos).
Earlier quoted context omitted.
Perhaps, however, this hacky language is more productive in the real world than most. What’s the point, otherwise?
The points: - 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%.
I thought NumPy was already releasing the GIL. On regular non-free-threaded Python, you can run threaded parallel Numpy operations and have multiple cores doing 100%, I've relied on that. Maybe not the case with the operations this article focuses on (sin/cos).
sum((np.sin(np.cos(np.sin(np.cos(x + i)))).sum()
for i in range(n_loop)))
release GIL
# i = 0
compute y = x + 0 (numpy broadcasting sum)
compute z = np.cos(y) (elementwise)
...
add to running total
# i = 1
compute y = x + 1
...
reacquire GIL
# i = 0
look up "+" operation
release GIL
compute y = x + 0
reacquire GIL
look up "np.cos" operation
release GIL
compute z = np.cos(y)
reacquire GIL
...
# i = 1
look up "+" operation
release GIL
compute y = x + 1
reacquire GIL
...
Of course, without free threading, the lock contention would be way worse, but this time the GIL is the lock being contended. Numpy has to reacquire the GIL whenever it returns from a function call, and this expression is made up of multiple calls. To multithread effectively with numpy (in non-freethreading) you'd normally aim to vectorise into a small number of calls in big arrays.
The composition of +, then np.cos, etc. is not too bad if these are big arrays, but the problem is the pure Python iteration over the range which is, presumably, quite large. You could vectorise over the range:
x[..., None] + np.arange(n_loop, dtype=np.float64)
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 a…
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 a…