GIL в Python 3.1

Ответ 1

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

Ответ 2

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

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

Update0

• Общий прирост производительности с новым GIL в 3.2 от Antoine Pitrou был незначительным и вместо этого сосредоточился на улучшении конфликтных вопросов, которые возникают в определенном углу случаев.
• замечательное усилие Дэвида Бэзли было сделано для того, чтобы реализовать планировщик, чтобы значительно повысить производительность при смешении потоков, связанных с процессором и IO, что было, к сожалению, сбил.
• Работа с нерабочей ласточкой была предлагаемая для слияния в Python 3.3, но это было отменено из-за отсутствия результатов в этом проекте. PyPy теперь является предпочтительным проектом и в настоящее время запрашивает финансирование добавить поддержку Python3k. Очень мало шансов, что PyPy станет стандартным в настоящее время.

За последние 15 лет были предприняты усилия по удалению GIL из CPython, но в обозримом будущем он должен остаться.

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

Как я понимаю, "планировщик мозгов" заменит GIL на python 3.2

BFS bainfuck scheduler

Ответ 7

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