2 ms·
There’s also the fact that INCREF and DECREF on shared objects is a lot more expensive than plain integer addition, so stuff becomes a bottleneck that was never
by ngoldbaum 2mo ago
There’s also the fact that INCREF and DECREF on shared objects is a lot more expensive than plain integer addition, so stuff becomes a bottleneck that was never a bottleneck. Kumar also fixed a bottleneck caused by a lock added only for safety on the free-threaded build. It’s hard to tell in advance than a fancy lock-free data structure is needed for something.
- quietbritishjim 2mo agoYou're talking about the same thing as the article: why were things not as fast as they could be in free threaded mode? But this comment thread is more of a meta discussion: why would lock contention issues only show up now, in free threaded mode, if numpy already released the GIL anyway? That's what I answered above: yes the GIL was sometimes released by numpy, but these operations really were happening with the GIL locked (in non free threaded build).
- ngoldbaum 2mo agoI’m saying that it’s a new issue on the free-threaded build.
- quietbritishjim 2mo agoRight. The original commenter already seemed to understand that. It's a new issue because the reference count needs locking, whereas previously it didn't because it was implicitly synchronised due to the GIL being locked. But the original commenter asked: hang on, I thought the GIL wasn't locked for numpy? Now you have reached the start of the conversation.