Comments 27
Из англоязычных мне понравилась презентация про новый GIL: www.dabeaz.com/blog/2010/01/presentation-on-new-python-gil.html
Я как бы не самый большой специалист по питону (можно сказать, вообще не специалист), но из прочтенной статьи сделал следующие выводы:
1. В питоне нет многопоточности в привычном понимании.
2. Использование потоков очень сильно замедляет выполнение программы.
Это так?
1. В питоне нет многопоточности в привычном понимании.
2. Использование потоков очень сильно замедляет выполнение программы.
Это так?
2. Верно для тех программ где скорость выполнения которой зависит преимущественно от производительности процессора.
Для операций последовательного и параллельного (в тредах) скачивания файлов из интернета выигрывает конечно второй способ.
Для операций последовательного и параллельного (в тредах) скачивания файлов из интернета выигрывает конечно второй способ.
Если уж случилось такое горе, что надо писать многопоточное приложения, проводящее активные вычисления (скажем, перекодирование чего-нуть во что-нибудь, да еще с большим количеством исходных данных); то эффективней использовать несколько процессов с модулем multiprocessing или ручками.
В некритичных приложениях потоки использовать вполне можно.
В критичных случаях используется наиболее эффективная асинхронная (не-б-б-б-б-блокирующая) модель, когда пускается несколько процессов с неблокирующим IO.
Чтобы вы не думали, что GIL появился с потолка, могу добавить, что его наличие в полтора-два раза ускоряет работу однопоточных приложений. Гвидо в свое время заявил, что GIL не уйдет до тех пор, пока не будет предложено решение, не снижающее производительность обыкновенных однопоточных программ.
В некритичных приложениях потоки использовать вполне можно.
В критичных случаях используется наиболее эффективная асинхронная (не-б-б-б-б-блокирующая) модель, когда пускается несколько процессов с неблокирующим IO.
Чтобы вы не думали, что GIL появился с потолка, могу добавить, что его наличие в полтора-два раза ускоряет работу однопоточных приложений. Гвидо в свое время заявил, что GIL не уйдет до тех пор, пока не будет предложено решение, не снижающее производительность обыкновенных однопоточных программ.
import multiprocessing и никаких проблем. Вообще проблема GIL сильно преувеличена: попытки заменить GIL на отдельные локи провалилась, так как GIL просто быстрее.
Так что GIL — скорее очередной повод попинать питон, нежели реальная проблема.
Так что GIL — скорее очередной повод попинать питон, нежели реальная проблема.
> import multiprocessing и никаких проблем.
Тем более учитывая то, что в Unix создание процесса обходится очень дёшево.
Не помню кто, один из гуру C++, сказал, что даже после многих лет работы с потоками неспособен написать корректную многопоточную программу.
Вообще, это скорее дискуссия на тему процессы vs потоки :-)
Тем более учитывая то, что в Unix создание процесса обходится очень дёшево.
Не помню кто, один из гуру C++, сказал, что даже после многих лет работы с потоками неспособен написать корректную многопоточную программу.
Вообще, это скорее дискуссия на тему процессы vs потоки :-)
Это был Брюс Эккель, он помоему жабист www.artima.com/weblogs/viewpost.jsp?thread=214112
А вообще я на практике однопоточным приложением в 2 раза убирал многопоточные при перемножении матриц на C
А вообще я на практике однопоточным приложением в 2 раза убирал многопоточные при перемножении матриц на C
Вы смяли немного тему — не провалилась, а Гвидо дал отворот, потому что однопоточная программа стала медленнее работать. А в мире гораздо больше однопоточных python-программ. В многопоточных программах вариант с локами работал быстрее.
ИМХО, самое главное, нужно определиться, для чего нужна многопоточность. Нужна она для выполнения нескольких задач одновременно. Но не для ускорения вычислительных задач.
Просто нужно понимать ограничения и применимость подхода. Без знания специфики, вообще в многопоточное программирования лучше не соваться.
Просто нужно понимать ограничения и применимость подхода. Без знания специфики, вообще в многопоточное программирования лучше не соваться.
у меня вот вопрос…
я выполнил Ваш скрипт (Тест производительности) своего ничего не дописывал, только копипаст:
выполнения скрипта без потоков:
real 1m45.761s
user 1m45.563s
sys 0m0.112s
выполнение скрипта с потоками:
real 0m12.954s
user 0m12.201s
sys 0m0.808s
это я что-то не так сделал или у меня неправильная машина?
ubuntu, intel core2duo работают 2 ядра
может все-таки в маке дело?
я выполнил Ваш скрипт (Тест производительности) своего ничего не дописывал, только копипаст:
выполнения скрипта без потоков:
real 1m45.761s
user 1m45.563s
sys 0m0.112s
выполнение скрипта с потоками:
real 0m12.954s
user 0m12.201s
sys 0m0.808s
это я что-то не так сделал или у меня неправильная машина?
ubuntu, intel core2duo работают 2 ядра
может все-таки в маке дело?
Тоже порекомендую перевести в тему презентацию о новом GIL предложенный в версии Python 3.2:
www.dabeaz.com/python/NewGIL.pdf
www.dabeaz.com/python/NewGIL.pdf
Надо, наверное, смотреть в сторону кооперативных потоков, (Stackless Pyhton, например). Есть ли в питоне что-то похожее на GNU Pth для C?
Пишу из будущего. Протестировал ваш код без изменений в Python 3.7.2 на macOS 10.14.3 с процессором 2,8 GHz Intel Core i7 (4 ядра):
последовательный запуск — 10.447758279 с
параллельный запуск — 10.4375156 с
последовательный запуск — 10.447758279 с
параллельный запуск — 10.4375156 с
Не зря же в Release Notes Питона 3.7 сказано, что он стал быстрее)
На моей машине получается то же, что у автора. Питон 3.6, Ubuntu, Intel i7 2.8 GHz.
На моей машине получается то же, что у автора. Питон 3.6, Ubuntu, Intel i7 2.8 GHz.
И еще из будущего:
MacOS 10.14.5, Intel Core I5 2.3Ghz
Python 2.7.10
Последовательно 5.6 сек
Параллельно 7.6 сек
Python 3.7.3
Последовательно 10.9 сек
Параллельно 10.4 сек
Python2 рулит?
MacOS 10.14.5, Intel Core I5 2.3Ghz
Python 2.7.10
Последовательно 5.6 сек
Параллельно 7.6 сек
Python 3.7.3
Последовательно 10.9 сек
Параллельно 10.4 сек
Python2 рулит?
и еще из будущего.
habr.com/ru/company/otus/blog/458694
«Одной из особенностей CPython 3.8, является PEP554, реализация субинтерпретаторов и API с новым модулем interpreters в стандартной библиотеке.
Это позволяет создавать несколько интерпретаторов из Python в рамках одного процесса. Еще одно нововведение Python 3.8 заключается в том, что все интерпретаторы будут иметь свои собственные GIL.»
Интересно как теперь по скорости.
habr.com/ru/company/otus/blog/458694
«Одной из особенностей CPython 3.8, является PEP554, реализация субинтерпретаторов и API с новым модулем interpreters в стандартной библиотеке.
Это позволяет создавать несколько интерпретаторов из Python в рамках одного процесса. Еще одно нововведение Python 3.8 заключается в том, что все интерпретаторы будут иметь свои собственные GIL.»
Интересно как теперь по скорости.
Sign up to leave a comment.
Как устроен GIL в Python