GIL вообще никак не влияет на скорость или вообще что либо в питоне.. сейчас объясню почему:
1. большинство основных библиотек для Python (NumPy, SciPy, и т.д.) написаны на C где ограничения GIL не влияют на нашу программу...для всего остального есть multiprocessing, numba, Jython, Boost.Python, IronPython и т.д.
2. CPython поддерживает
multi-io-bound-thread + single-cpu-bound-thread и в питоне доступен только сингл в некоторых случаях это так, но:
io-bound-methods: file.open(), file.write(), file.read(), socket.send(), socket.recv(), и т.д.
file.open(), file.write(),
file.read(), socket.send(), socket.recv(), и т.д.
cpu-bound-methods: арифметические вычисления, и т.д.
——> как видим на большинство операций, а именно
io-bound-methods эти ограничения не влияют с;
а для всего остального есть multiprocessing, numba, Jython, Boost.Python, IronPython и т.д.
3. Вместе с
PEP554 в asyncio очень скоро появятся субинтерпретаторы а это означает встроенную многопоточность с;
из всего этого выходит, что GIL действительно устарел, но сейчас от него даже больше пользы чем вреда, ведь он делает не потокобезопасные библиотеки на C легко интегрируемыми и безопасными для выполнения из Python..... с;
* для простых задач есть concurrent.futures (с его встроенными ProcessPoolExecutor / ThreadPoolExecutor)
** если мобилизовать ядра видюхи (gpu) и юзать multiprocessing из питона + PyOpenCL (чтобы управлять доступом к gpu) может получится достаточно быстро даже для какой-нибудь кастомной библиотеки целиком на питоне (без C-твиков для обхода GIL), даже в пределах какого-нибудь крутого научного исследования. в самой обычной видюхе от 700 ядер, бывает и по 2к
