Pull to refresh

Comments 24

Я как бы не самый большой специалист по питону (можно сказать, вообще не специалист), но из прочтенной статьи сделал следующие выводы:

1. В питоне нет многопоточности в привычном понимании.
2. Использование потоков очень сильно замедляет выполнение программы.

Это так?
2. Верно для тех программ где скорость выполнения которой зависит преимущественно от производительности процессора.
Для операций последовательного и параллельного (в тредах) скачивания файлов из интернета выигрывает конечно второй способ.
Ухты, хабракат в коментах уже)

спс за разъяснение
Если уж случилось такое горе, что надо писать многопоточное приложения, проводящее активные вычисления (скажем, перекодирование чего-нуть во что-нибудь, да еще с большим количеством исходных данных); то эффективней использовать несколько процессов с модулем multiprocessing или ручками.

В некритичных приложениях потоки использовать вполне можно.

В критичных случаях используется наиболее эффективная асинхронная (не-б-б-б-б-блокирующая) модель, когда пускается несколько процессов с неблокирующим IO.

Чтобы вы не думали, что GIL появился с потолка, могу добавить, что его наличие в полтора-два раза ускоряет работу однопоточных приложений. Гвидо в свое время заявил, что GIL не уйдет до тех пор, пока не будет предложено решение, не снижающее производительность обыкновенных однопоточных программ.

import multiprocessing и никаких проблем. Вообще проблема GIL сильно преувеличена: попытки заменить GIL на отдельные локи провалилась, так как GIL просто быстрее.

Так что GIL — скорее очередной повод попинать питон, нежели реальная проблема.
> import multiprocessing и никаких проблем.

Тем более учитывая то, что в Unix создание процесса обходится очень дёшево.

Не помню кто, один из гуру C++, сказал, что даже после многих лет работы с потоками неспособен написать корректную многопоточную программу.

Вообще, это скорее дискуссия на тему процессы vs потоки :-)
У него несколько книжек по плюсам, он в нём хорошо разбирается. Насчёт явы я не интересовался, а вот C++ он точно знает лучше, чем большинство других программистов.

Про умножение — каким образом?
Да просто. У процессора есть кэш. Несколько потоков снижают эффективность кеша. Если матрицы представить в виде векторов (строка за строкой), то все становится очень быстро и много времени кеш экономит
Вы смяли немного тему — не провалилась, а Гвидо дал отворот, потому что однопоточная программа стала медленнее работать. А в мире гораздо больше однопоточных python-программ. В многопоточных программах вариант с локами работал быстрее.
ИМХО, самое главное, нужно определиться, для чего нужна многопоточность. Нужна она для выполнения нескольких задач одновременно. Но не для ускорения вычислительных задач.
Просто нужно понимать ограничения и применимость подхода. Без знания специфики, вообще в многопоточное программирования лучше не соваться.
у меня вот вопрос…
я выполнил Ваш скрипт (Тест производительности) своего ничего не дописывал, только копипаст:
выполнения скрипта без потоков:
real 1m45.761s
user 1m45.563s
sys 0m0.112s

выполнение скрипта с потоками:
real 0m12.954s
user 0m12.201s
sys 0m0.808s

это я что-то не так сделал или у меня неправильная машина?
ubuntu, intel core2duo работают 2 ядра

может все-таки в маке дело?
Возможно. В маке количество сигналов возрастает явно быстрее, чем в линуксе.
было бы неплохо проверить этот тест на винде, возможно на самом деле проблема в маке?:)
Проверил
WinXP, Intel Core Duo

29,5 с. в однопоточном режиме
43,9 с. в двухпоточном

Похоже что Убунта знает волшебное слово :)
Дико извиняюсь, я протупил, в однопоточком скрипте я ошибся ноликом :( мне стыдно, убунта, увы, не знает волшебного слова
Дико извиняюсь, я протупил, в однопоточком скрипте я ошибся ноликом :( мне стыдно, Вы правы, потоки медленней
Надо, наверное, смотреть в сторону кооперативных потоков, (Stackless Pyhton, например). Есть ли в питоне что-то похожее на GNU Pth для C?
Пишу из будущего. Протестировал ваш код без изменений в Python 3.7.2 на macOS 10.14.3 с процессором 2,8 GHz Intel Core i7 (4 ядра):
последовательный запуск — 10.447758279 с
параллельный запуск — 10.4375156 с
Не зря же в Release Notes Питона 3.7 сказано, что он стал быстрее)
На моей машине получается то же, что у автора. Питон 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 рулит?
и еще из будущего.
habr.com/ru/company/otus/blog/458694
«Одной из особенностей CPython 3.8, является PEP554, реализация субинтерпретаторов и API с новым модулем interpreters в стандартной библиотеке.
Это позволяет создавать несколько интерпретаторов из Python в рамках одного процесса. Еще одно нововведение Python 3.8 заключается в том, что все интерпретаторы будут иметь свои собственные GIL.»
Интересно как теперь по скорости.
Only those users with full accounts are able to leave comments. Log in, please.