Python 3.2 - GIL - хороший/плохой?

АЛЬФА Python 3.2 отсутствует.

От Журнала изменений кажется, что GIL был полностью переписан.

Несколько вопросов:

  1. Имеет польза GIL или плохой? (и почему).
  2. Новый GIL лучше? Если так, как?

ОБНОВЛЕНИЕ:

Я довольно плохо знаком с Python. Таким образом, все это в новинку для мой, но я действительно, по крайней мере, понимаю, что существование GIL с CPython является огромным соглашением.

Вопрос, хотя, то, почему CPython только не клонирует интерпретатор как Perl, делает в попытке устранить необходимость GIL?

20
задан JerryK 2 August 2010 в 01:49
поделиться

3 ответа

Наличие GIL - это хорошо или плохо? (и почему).

Ни то, ни другое. Это необходимо для синхронизации потоков.

Новый GIL лучше? Если да, то как?

Выполняли ли вы какие-нибудь тесты? Если нет, то, возможно, вам следует (1) запустить тест, (2) опубликовать тест в вопросе и (3) задать конкретные вопросы о результатах теста.

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

Однако обсуждение GIL в конкретном контексте вашего теста может привести к решению вашей проблемы с производительностью.

Вопрос, однако, почему CPython не просто клонирует интерпретатор, как Perl, в попытке устранить необходимость в GIL?

Прочтите это: http://perldoc.perl.org/perlthrtut.html

Во-первых, Perl вообще не поддерживал потоки. В старых интерпретаторах Perl был модуль с ошибками, который работал некорректно.

Во-вторых, эта функция есть в новом интерпретаторе Perl.

Самая большая разница между потоками Perl и старым стилем потоковой передачи 5.005, или, если на то пошло, с большинством других потоковых систем, заключается в том, что по умолчанию никакие данные не используются совместно. Когда создается новый поток Perl, все данные, связанные с текущим потоком, копируются в новый поток и впоследствии становятся частными для этого нового потока!

Поскольку модель Perl (совместно используются только определенные данные) отличается от модели Python (совместно используются все данные), копирование интерпретатора Perl в корне нарушит потоки Python. Модель потока Perl принципиально иная.

4
ответ дан 30 November 2019 в 00:35
поделиться

Лучшее объяснение того, почему GIL отстой, я видел здесь:

http://www.dabeaz.com/python/GIL.pdf

И у того же парня есть презентация нового GIL здесь:

http://www.dabeaz.com/python/NewGIL.pdf

Если это все, что было сделано, это все еще отстой - просто не так плохо. Многопоточность будет вести себя лучше. Многоядерность все еще ничего не даст вам с одним приложением на python.

25
ответ дан 30 November 2019 в 00:35
поделиться

Новый GIL лучше? Если да, то как?

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

почему CPython не просто клонирует интерпретатор, как Perl, в попытке устранить необходимость в GIL?

GIL - сложный вопрос, его не следует рассматривать как абсолютное зло. Это дает нам потокобезопасность.

Что касается perl, perl а) мертв, б) слишком стар. Ребята из Google работают над добавлением возможностей LLVM в CPython, которые, среди прочего, улучшат поведение GIL (хотя полного удаления GIL пока нет): http://code.google.com/p/unladen-swallow/

1
ответ дан 30 November 2019 в 00:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: