GIL на Python 3.1

Question

Кто-нибудь знает судьбу глобальной блокировки интерпретатора в 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, они предвещают потенциально огромный прирост производительности.

Обновление0

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

Насколько я понимаю, "мозговой отряд" планировщик заменит GIL из Python 3.2

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

Answer 7

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