4 ms·
> requires some kind of synchronization and for CPU-intensive code slowdown from this synchronisation tends to be larger than from sequential execution with GIL
by runT1ME 16y ago
> requires some kind of synchronization and for CPU-intensive code slowdown from this synchronisation tends to be larger than from sequential execution with GIL for almost any significant number of concurrent threads (such as 3 threads on Core 2 Quad on Linux 2.6.2something)
what? You're saying the absolute worst case synchronization scenario is on par with the GIL, so you might as well not have it?
- deleted 16y ago[deleted]
- dfox 16y agoExactly, because in other cases the GIL does not matter (in best case both approaches would be on par, which they probably would not, due to greater lock contention in finely grained case). Trying to optimize synchronization on so fine level as is done inside various kernels (Linux) would not help, because it is very hard to do correctly in user space ("very hard" as in "probably impossible"). Only way that I see is to try to optimize away majority of shared memory accesses, which would require clever compiler and probably slight modification of Python semantics, or you can simply write your code that is so easily parallelizable as separate processes not threads.