GIL в Python 3.1

Question

Кто-нибудь знает судьбу Global Interpreter Lock в Python 3.1 против многопоточной интеграции C ++

Answer 1

GIL все еще есть в CPython 3.1; проекты Unladen Swallow направлены (среди многих других повышений производительности) на то, чтобы в конечном итоге удалить его, но это все еще далеко от своих целей, и сначала работает над 2.6 с намерением в конечном итоге портировать на 3.x для чего угодно x будет действительным к моменту, когда версия 2.y считается завершенной. На данный момент многопроцессорная обработка (а не многопоточность) остается предпочтительным вариантом использования нескольких ядер в CPython (IronPython и Jython тоже хороши, но в настоящее время они не поддерживают Python 3, а также не делают интеграцию с C ++ такой же простой; - ).

Answer 2

Значительные изменения произойдут в GIL для Python 3.2. Взгляните на Что нового для Python 3.2 и ветку, которая инициировала его в списке рассылки .

Хотя изменения не означают конца GIL, они предвещают потенциально огромный прирост производительности.

Update0

• Общее увеличение производительности с новым GIL в 3.2 от Антуана Питроу было незначительным, и вместо этого было сосредоточено на улучшении проблем конкуренции , возникающих в определенных угловых случаях.
• Замечательное усилие Дэвида Бизли (David Beazley) было направлено на реализацию планировщика, позволяющего значительно повысить производительность при смешивании потоков, связанных с процессором и вводом-выводом, что, к сожалению, было сбито.
• Работа Unladen Swallow была предложена для слияния в Python 3.3, но она была отозвана из-за отсутствия результатов в этом проекте. PyPy теперь является предпочтительным проектом и в настоящее время запрашивает финансирование для добавления поддержки Python3k. В настоящее время очень мало шансов, что PyPy станет по умолчанию.

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

Answer 3

GIL не повлияет на ваш код, который не использует объекты Python. В Numpy мы выпускаем GIL для вычислительного кода (вызовы линейной алгебры и т. Д.), И базовый код может свободно использовать многопоточность (на самом деле это, как правило, сторонние библиотеки, которые ничего не знают о Python)

Answer 4

GIL - это хорошая вещь.

Просто заставьте ваше приложение C ++ выпускать GIL, пока оно выполняет свою многопоточную работу. Код Python будет продолжать работать в других потоках без изменений. Получайте GIL только тогда, когда вам нужно дотронуться до объектов Python.

Answer 5

Если GIL мешает, просто используйте модуль multiprocessing . Он порождает новые процессы, но использует модель потоков и (большую часть) API. Другими словами, вы можете выполнять параллелизм на основе процессов потоковым способом.

Answer 6

Насколько я понимаю, планировщик "brainfuck" заменит GIL из python 3.2

BFS bainfuck планировщик

Answer 7

Я думаю, что всегда будет GIL. Причина в производительности. Сделать весь поток доступа низкого уровня безопасным - означает, что мьютекс вокруг каждой операции хеширования и т. Д. Тяжел. Помните, что простое утверждение типа

self.foo(self.bar, 3, val)

Может уже иметь как минимум 3 (если val является глобальным) поиска в хеш-таблице на данный момент и, возможно, даже больше, если кэш метода не горячий (зависит от глубины наследования класса)

Это дорого - поэтому Java отказалась от этой идеи и представила хеш-таблицы, в которых не используется вызов монитора, чтобы избавиться от своей торговой марки "Java Is Slow".