GIL в Python 3.1

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

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

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

Обновление0

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

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

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

ГИЛ хорошая штука.

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

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

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

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

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

Я так понимаю планировщик "brainfuck" заменит GIL из python 3.2

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

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