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

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

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

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

UPDATE

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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