CPython: Эталонная реализация Python и глобальная блокировка интерпретатора (GIL)

Введение

Референтная реализация Python

CPython — это эталонная реализация языка программирования Python. Написанный на языках C и Python, CPython является реализацией по умолчанию и наиболее широко используемой реализацией Python. CPython можно рассматривать как интерпретатор и компилятор, поскольку он компилирует код Python в байт-код перед интерпретацией. Он предоставляет интерфейс для работы с функциями, написанными на других языках, таких как C, требующий явного создания связующих модулей на языке, отличном от Python.

Дизайн

Особенностью CPython является использование глобальной блокировки интерпретатора (GIL) в каждом процессе интерпретатора CPython, что означает, что в рамках одного процесса в любой момент времени только одна нить может обрабатывать байт-код Python. Это не означает, что многопоточность бессмысленна; наиболее распространенный сценарий многопоточности – это когда потоки в основном ожидают завершения внешних процессов. Это может происходить, когда несколько потоков обслуживают отдельных клиентов. Одна нить может ждать ответа от клиента, другая – завершения запроса к базе данных, а третья – фактически обрабатывать код Python. Однако GIL означает, что CPython не подходит для процессов, реализующих ресурсоемкие алгоритмы на Python, которые потенциально можно было бы распределить по нескольким ядрам. В реальных приложениях ситуации, когда GIL становится существенным узким местом, встречаются довольно редко. Это связано с тем, что Python по своей природе – медленный язык и обычно не используется для ресурсоемких или критичных ко времени операций. Python обычно используется на верхнем уровне и вызывает функции в библиотеках для выполнения специализированных задач. Эти библиотеки, как правило, не написаны на Python, и код Python в другой нити может выполняться, пока происходит вызов одного из этих базовых процессов. Библиотека, не на Python, вызываемая для выполнения ресурсоемкой задачи, не подвержена воздействию GIL и может одновременно выполнять множество потоков на нескольких процессорах без ограничений. Параллельное выполнение кода Python возможно только с использованием отдельных процессов интерпретатора CPython, управляемых многозадачной операционной системой. Это усложняет взаимодействие между параллельными процессами Python, хотя модуль multiprocessing несколько смягчает эту проблему; это означает, что приложения, которые действительно могут выиграть от параллельного выполнения кода Python, могут быть реализованы с ограниченными накладными расходами. Наличие GIL упрощает реализацию CPython и облегчает создание многопоточных приложений, которые не выигрывают от параллельного выполнения кода Python. Однако без GIL многопроцессорные приложения должны обеспечивать потокобезопасность всего общего кода. Хотя было предложено множество способов устранения GIL, общее мнение заключается в том, что в большинстве случаев преимущества GIL перевешивают недостатки; в тех редких случаях, когда GIL является узким местом, приложение следует разрабатывать с использованием многопроцессорной архитектуры. Для повышения степени параллелизма в октябре 2023 года было выпущено обновление, позволяющее использовать отдельный GIL для каждого подчиненного интерпретатора в одном процессе Python, что было описано как "потоки с возможностью выбора совместного использования". После нескольких обсуждений в 2023 году был запущен проект по предложению сделать GIL необязательным, начиная с версии 3.13 Python, выпуск которой запланирован на октябрь 2024 года.

A particular feature of CPython is that it makes use of a global interpreter lock (GIL) on each CPython interpreter process, which means that within a single process, only one thread may be processing Python bytecode at any one time. This does not mean that there is no point in multithreading; the most common multithreading scenario is where threads are mostly waiting on external processes to complete. This can happen when multiple threads are servicing separate clients. One thread may be waiting for a client to reply, and another may be waiting for a database query to execute, while the third thread is actually processing Python code. However, the GIL does mean that CPython is not suitable for processes that implement CPU intensive algorithms in Python code that could potentially be distributed across multiple cores. In real world applications, situations where the GIL is a significant bottleneck are quite rare. This is because Python is an inherently slow language and is generally not used for CPU intensive or time sensitive operations. Python is typically used at the top level and calls functions in libraries to perform specialized tasks. These libraries are generally not written in Python, and Python code in another thread can be executed while a call to one of these underlying processes takes place. The non Python library being called to perform the CPU intensive task is not subject to the GIL and may concurrently execute many threads on multiple processors without restriction. Concurrency of Python code can only be achieved with separate CPython interpreter processes managed by a multitasking operating system. This complicates communication between concurrent Python processes, though the multiprocessing module mitigates this somewhat; it means that applications that really can benefit from concurrent Python code execution can be implemented with limited overhead. The presence of the GIL simplifies the implementation of CPython, and makes it easier to implement multi threaded applications that do not benefit from concurrent Python code execution. However, without a GIL, multiprocessing apps must make sure all common code is thread safe. Although many proposals have been made to eliminate the GIL, the general consensus has been that in most cases, the advantages of the GIL outweigh the disadvantages; in the few cases where the GIL is a bottleneck, the application should be built around the multiprocessing structure. To help allow more parallelism, an improvement was released in October 2023 to allow a separate GIL per subinterpreter in a single Python process and have been described as "threads with opt in sharing". After several debates, a project was launched in 2023 to propose making the GIL optional from version 3.13 of Python, which is scheduled for release in October 2024.

Незаряженная ласточка

Unladen Swallow был ветвью оптимизации CPython, предназначенной для полной совместимости и значительного увеличения скорости работы. Проект стремился достичь своих целей путем дополнения пользовательской виртуальной машины CPython JIT-компилятором, построенным на базе LLVM. Заявленной целью проекта было увеличение скорости в пять раз по сравнению с CPython, однако эта цель не была достигнута. Проект финансировался Google, а его владельцы – Томас Вутерс, Джеффри Яскин и Коллин Винтер – являлись штатными сотрудниками Google, хотя большинство участников проекта не были сотрудниками Google. Unladen Swallow размещался на Google Code. Как и многое другое, связанное с языком Python, название Unladen Swallow является отсылкой к «Монти Пайтону», в частности к шутке о скорости полета незагруженной ласточки из фильма «Монти Пайтон и Святой Грааль». Несмотря на то, что проект не достиг всех заявленных целей, он создал код, который был включен в основную реализацию Python, например, улучшения для модуля cPickle. В июле 2010 года некоторые наблюдатели высказывали предположения о том, что проект либо мертв, либо находится в состоянии упадка, поскольку релиз этапа разработки Q4 2009 года так и не состоялся. Активность в рассылке Unladen снизилась с 500 сообщений в январе 2010 года до менее чем 10 в сентябре 2010 года. Также сообщалось о прекращении финансирования проекта со стороны Google. В ноябре 2010 года один из основных разработчиков объявил, что «Джеффри и я были переведены на другие проекты, имеющие более высокий приоритет для Google». Ветвь разработки Q4 2009 года была создана 26 января 2010 года, но на веб-сайте не было объявлено о ее запуске. Более того, в отношении долгосрочных планов, и поскольку проект не успел к релизу Python 2.7, было предложено улучшение Python (PEP). Интеграция заняла бы некоторое время, поскольку Unladen Swallow изначально был основан на Python 2.6, с которым Python 3 нарушил обратную совместимость (подробнее см. Python 3000). Однако впоследствии это PEP было отозвано. В начале 2011 года стало очевидно, что проект был остановлен.