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

Question

Python 3.2 ALPHA отсутствует .

Из журнала изменений видно, что GIL полностью переписан.

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

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

UPDATE

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

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

Answer 1

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

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

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

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

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

Answer 2

Хорошо или плохо иметь GIL?(и почему).

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

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

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

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

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

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

Читать это: http://perldoc.perl.org/perlthrtut.html

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

Во-вторых, более новый интерпретатор Perl имеет эту функцию.

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

* 1032.Модель потока Perl принципиально отличается.

Answer 3

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

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

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

GIL - сложная проблема, ее не следует рассматривать как Ultimate Evil.Это приносит нам безопасность потока.

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