Многопоточность в python: действительно ли она эффективна в большинстве случаев?
В моем маленьком понимании, это фактор производительности, который управляет программированием для multi-threading в большинстве случаев, но не во всех. (независимо от Java или Python).
Я читал эту поучительную статью о GIL в ТАК. В статье обобщается, что Python принимает GIL механизм; т.е. только single Thread может выполнить python byte code в любой момент времени. Это делает single thread приложение действительно быстрее.
Мой вопрос заключается в следующем:
Так как если бы только один Thread подается в данный момент, делает multiprocessing или же thread Модуль предоставляет способ преодолеть это ограничение, наложенное GIL? Если нет, то какие функции они предоставляют для реального multi-task Работа
Был задан вопрос в разделе комментариев вышеупомянутого поста в принятом ответе, но ответ не был дан? У меня тоже был этот вопрос
^so at any time point of time, only one thread will be serving content to client...
so no point of actually using multithreading to improve performance. right?
4 ответа
Вы правы в отношении GIL, нет смысла использовать многопоточность для выполнения вычислений с привязкой к ЦП, поскольку ЦП будет использоваться только одним потоком.
Но это предыдущее утверждение могло бы вас поразить: если ваши вычисления не связаны с процессором, вы можете воспользоваться многопоточностью.
Типичный пример - когда ваше приложение занимает большую часть времени в ожидании чего-либо.
Один из многих примеров программ, не связанных с процессором: скажем, вы хотите создать веб-сканер, вам нужно сканировать множество веб-сайтов и сохранять их в базе данных, что стоит времени? Ожидание отправки серверами данных, фактическая загрузка данных и их сохранение в базе данных - здесь ничего не связано с процессором. Здесь вы можете получить более быстрый сканер, используя пул сканеров вместо одного. Как правило, в случае, если один веб-сайт почти не работает и очень медленно реагирует (~30 с), в это время однопоточное приложение будет ждать веб-сайт, вы застряли. В многопоточном приложении другие потоки будут продолжать сканировать, и это круто.
С другой стороны, поскольку для каждого процесса существует один GIL, вы можете использовать многопроцессорность для выполнения вычислений с привязкой к процессору.
В качестве примечания, существует несколько более или менее частичных реализаций Python без GIL, я хотел бы упомянуть одну, которая, на мой взгляд, является отличным способом для достижения чего-то крутого: pypy STM. Вы легко найдете в поиске "избавиться от GIL" множество тем на эту тему.
Многопроцессорная обработка позволяет избежать проблемы GIL, поскольку код выполняется в отдельном процессе, а GIL связан только с одним процессом. Внутри процесса многопоточность может быть быстрее до такой степени, что потоки ожидают некоторого относительно медленного ресурса, такого как диск или сеть.
Быстрый поиск в Google дал это информативное слайд-шоу. http://www.dabeaz.com/python/UnderstandingGIL.pdf
Но то, что он не в состоянии представить это факт, что все потоки содержатся в процессе. И процесс по умолчанию может работать только на одном процессоре (или ядре). Таким образом, хотя GIL для каждого процесса управляет потоками в указанном процессе и не всегда обеспечивает ожидаемую производительность, он в больших масштабах должен выполнять лучше, чем однопоточные операции.
GIL - всегда горячая тема в python, но обычно бессмысленная. Это делает большинство программ намного более безопасными. Если вам нужна реальная производительность вычислений, попробуйте PyOpenCL. Любое современное высокопроизводительное сжатие чисел должно выполняться на графических процессорах (также openCL успешно работает на процессорах). У него нет проблем GIL.
Если вы хотите использовать многопоточность в python для улучшения производительности, связанной с вводом / выводом, GIL здесь не проблема.
И, наконец, если вы хотите использовать несколько процессоров для повышения производительности обработки ваших чистых чисел, и в стиле питона, используйте многопроцессорность.
Но это все еще не так быстро, как кодирование многопоточного приложения в сборке. Удачи, не делая опечаток.