Как интерпретирующему языку можно избежать использования Global Interpreter lock (GIL)?

Question

CPython использует Глобальную блокировку интерпретатора .Linux удалил все следы Big Kernel Lock .Какая альтернатива этим замкам?Как система может в полной мере использовать действительно многоядерную или многопроцессорную систему, не останавливая все?

Answer 1

GIL не понадобился бы, если бы Python использовал более продвинутый сборщик мусора, такой как IBM Recycler , основанный на примитивном методе подсчета ссылок. Это то, что Unladen Swallow делает для улучшения производительности Python. Более многообещающий ответ - Stackless Python , который использует собственную реализацию микропотока, а не полагается на операционную систему, подобную традиционному CPython.

Answer 2

GIL зависит от процесса, поэтому вы можете обойти его, запустив несколько процессов Python. многопроцессорный модуль предоставляет простой в использовании API для этого.

Другой способ - использовать C-расширения (или написать свои собственные), которые высвобождают GIL, выполняя необходимый вам тип обработки данных.

Answer 3

Simple. Не имеют изменяемого состояния, как в Haskell и других функциональных языках программирования. Поскольку в памяти ничего не нужно менять, глобальная блокировка не нужна.

Answer 4

Вы можете избавиться от GIL точно так же, как парни из Linux избавились от Big Kernel Lock: просто добавьте множество более мелкозернистых блокировок или используйте атомарные примитивы, которые не нуждаются в блокировках.

Недостатком и главной причиной, по которой Python этого не делает, является производительность. Например, интерпретатор Tcl не имеет GIL, но может быть скомпилирован как многопоточный, так и не поточный, если вы используете многопоточную версию, вы получите производительность примерно на 10-20% меньше, чем в однопоточном случае. Так что, если вы не используете потоки, это на самом деле медленнее. Были исправления Python для добавления меньших блокировок, но они имели еще худшее влияние на производительность, поэтому были отклонены.

Это просто компромисс, разработчики Python решили, что производительность одного потока (и обратная совместимость с C-расширениями) гораздо важнее, чем возможность использовать много потоков на уровне Python. Вы все еще можете свободно использовать потоки внутри C-расширения, но это не имеет смысла на уровне языка Python.