Адаптивный интерпретатор: как CPython переписывает сам себя по дороге

Интерпретатор правит себя по ходу дела

Обычная картина такая: компилятор превратил исходник в байт-код, и дальше цикл интерпретатора этот байт-код крутит. Правдива она ровно до Python 3.11.

С 3.11 добавился третий участник. Пока код исполняется, интерпретатор смотрит, что именно через него проходит, и подменяет инструкции на более узкие. Было BINARY_OP — «сложи что угодно с чем угодно, разбирайся по ходу». Стало BINARY_OP_ADD_INT — «сложи два целых», без разбирательств.

Проверяется это одной строкой, без чтения исходников CPython: у dis есть флаг adaptive, который показывает инструкции в их нынешнем виде.

def attrs(fn):
    return [
        i.opname
        for i in dis.get_instructions(fn, adaptive=True)
        if i.opname.startswith("LOAD_ATTR")
    ]
 
print(attrs(read))    # ['LOAD_ATTR']
for _ in range(500):
    read(p)
print(attrs(read))    # ['LOAD_ATTR_INSTANCE_VALUE']

Функция та же, объект кода тот же. Изменился он сам.

Это происходит почти сразу

Слово «специализация» тянет за собой ожидание долгого разогрева — так работает JVM, где горячий код компилируется после тысяч итераций. В Python не так.

Замер простой: свежий кусок кода выполняется по одному разу, и после каждого раза у него спрашивают, как теперь называется инструкция.

Практический вывод: функция, вызванная дважды, уже работает на специализированных инструкциях. В частности, любой timeit меряет установившийся режим, а не разогрев.

Специализируется место, а не операция

Это важнее, чем кажется. Специализация записана не «для сложения вообще», а для одной конкретной строки в одной конкретной функции. Поэтому одно и то же обращение o.x даёт разные инструкции:

Отсюда неочевидное следствие: __slots__ — это не только про экономию памяти. Он ещё и меняет инструкцию, которой читается атрибут.

Проверка стоит денег

Специализированная инструкция обязана убедиться, что предположение ещё в силе, — иначе она отдала бы неверный ответ. Эта сверка выполняется на каждом проходе, и если через одно место ходят разные типы, она регулярно не сходится.

Пять классов, объявленных одинаково, делают одно и то же. Различается только число типов, проходящих через одну строку o.x:

Половина сверху на ровном месте — на этом замере: пять классов через одно o.x. Лечится это не аннотациями типов, а разделением горячего кода так, чтобы через одно место ходил один тип. Только сначала профиль: без него неизвестно, это ли место горячее.

А JIT?

С 3.13 в CPython есть и второй механизм — JIT. Он делает другое: заменяет не одну инструкцию, а целую последовательность.

Главное, что о нём стоит знать: по номеру версии судить о нём нельзя. В 3.14 он собран, но выключен; спросить у интерпретатора можно так:

import sys
print(sys._jit.is_available(), sys._jit.is_enabled())   # True False

Включается переменной окружения PYTHON_JIT=1. На четырёх коротких циклах, прогнанных на одной и той же сборке по шесть раз в каждом режиме, включение сделало медленнее все четыре: от +10,7 % на словаре до +36,7 % на обходе списка. На этом коде и этой машине «включил JIT — стало быстрее» не подтвердилось.

Что вообще происходит

Механизм описан в PEP 659 и внутри самого проекта — во внутренней документации CPython, и вторая формулировка точнее:

Ключевое слово — rewriting. Это не оптимизация компилятора: компилятор выдаёт обычный BINARY_OP, ничего не зная о типах. Переписывание происходит позже, во время исполнения, и делает его сам код: в Python/specialize.c на каждое семейство инструкций заведена своя функция _Py_Specialize_*.

Проверить это можно не читая исходников. У dis есть флаг adaptive, который показывает инструкции в их нынешнем виде:

import dis
 
def read(o):
    return o.x
 
class Point:
    def __init__(self):
        self.x = 1
 
def attrs(fn):
    return [
        i.opname
        for i in dis.get_instructions(fn, adaptive=True)
        if i.opname.startswith("LOAD_ATTR")
    ]
 
p = Point()
print("до прогрева:", attrs(read))
for _ in range(500):
    read(p)
print("после:      ", attrs(read))

до прогрева: ['LOAD_ATTR']
после:       ['LOAD_ATTR_INSTANCE_VALUE']

Одна и та же функция, один и тот же объект кода. Изменился он сам.

Где живёт счётчик

Чтобы решить, когда специализироваться, инструкции нужно место под счётчик, а специализированной версии — место под то, во что она верит: версию типа, смещение атрибута, указатель на дескриптор. Это место лежит прямо в массиве байт-кода, сразу за инструкцией:

И это тоже видно снаружи — флагом show_caches:

LOAD_ATTR_INSTANCE_VALUE 0 (x)
CACHE                    0 (counter: 832)
CACHE                    0 (version: 5833536)
CACHE                    0
CACHE                    0 (keys_version: 5833536)
CACHE                    0
CACHE                    0 (descr: 8595768128)
CACHE                    0
CACHE                    0
CACHE                    0

Девять двухбайтовых ячеек на одну инструкцию LOAD_ATTR — и первая из них по правилу семейства всегда счётчик. Отсюда, кстати, ответ на вопрос, который задают, увидев такой вывод впервые: CACHE — не инструкция. Интерпретатор её не исполняет, он через неё перешагивает; в массиве она лежит потому, что так данные оказываются рядом с кодом, который их читает.

Размер кеша одинаков у всех членов семейства — это условие корректности: LOAD_ATTR, LOAD_ATTR_SLOT и LOAD_ATTR_MODULE обязаны занимать в массиве одинаковое место, иначе подстановка сдвинула бы весь дальнейший код.

Что во что превращается

Одиннадцать однострочных операций, прогретых пятьюстами вызовами. Слева — что выдал компилятор, справа — что стало (Python 3.13.7):

Обратите внимание на две строки подряд: o.x превращается в разные инструкции в зависимости от того, лежит атрибут в словаре экземпляра или в слоте. Это и есть «под тот случай, который встречается в этой программе» — специализируется не операция вообще, а конкретное место в конкретной функции.

Всего таких семейств на 3.13 пятнадцать, а вариантов внутри них — семьдесят четыре. Самое большое семейство — CALL: двадцать вариантов.

Когда

Ответ неожиданно скорый:

Замер прямой: свежий объект кода выполняется по одному разу, и после каждого раза у него спрашивают имя инструкции. На 3.12 и новее оно меняется уже после второго прохода.

Практический вывод отсюда важнее самого числа. «Прогрев» в Python — это не тысячи итераций, как в JVM. Любая функция, вызванная дважды, уже работает на специализированных инструкциях. Микрозамер, который делает timeit с number=1000, меряет установившийся режим, а не разогрев, — и это хорошая новость для замеров и плохая для тех, кто рассчитывает «поймать» интерпретатор холодным.

Что если предположение не оправдалось

Внутренняя документация обещает откат:

Проверим. Пять классов, объявленных одинаково, делают одно и то же; одна строка o.x в цикле; различается только то, сколько разных типов через неё проходит:

Здесь два наблюдения, и второе противоречит тому, чего я ждал.

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

Второе: инструкция при этом не откатывается. Я ожидал увидеть в последней строке обычный LOAD_ATTR — и не увидел ни разу. За весь прогон инструкция переписывалась один раз (обобщённая → специализированная) и дальше не менялась, сколько типов через неё ни гоняй. То есть de-optimizing back to the generic version (откат к обобщённой версии) — это про то, что происходит внутри выполнения инструкции при несошедшейся проверке, а не про то, что в массиве байт-кода снова окажется обобщённый опкод. Отличить одно от другого можно только замером: пересказ PEP даёт обе картины одинаково правдоподобными.

Оговорка, без которой вывод был бы шире, чем измерение: это верно для семейства LOAD_ATTR и такого сценария. У BINARY_OP при смене типа наблюдалось другое поведение — специализированная инструкция сменялась на специализированную под новый тип (BINARY_OP_ADD_INT → BINARY_OP_ADD_FLOAT).

Второй уровень

С 3.13 в CPython есть ещё один механизм, и его постоянно путают с первым. Разница названа во внутренней документации одной фразой:

Там же названо, что считается горячим: инструкция JUMP_BACKWARD — то есть конец итерации цикла — смотрит на счётчик в собственном инлайн-кеше и, перевалив порог, просит оптимизатор построить трассу.

Работает ли он у вас — вопрос не к номеру версии. На это отвечает sys._jit:

import sys
print(sys._jit.is_available(), sys._jit.is_enabled(), sys._jit.is_active())

На сборке, на которой снят этот раздел (3.14.7), — True False False: собран, но выключен. Включается переменной окружения PYTHON_JIT=1.

А раз сборка одна и та же и различается ровно одна переменная, сравнение по времени здесь законно — в отличие от сравнения версий между собой. Четыре коротких цикла, шесть независимых пар запусков, лучшее из одиннадцати повторов в каждом; процент в последней колонке — отношение лучших запусков двух режимов:

В колонках не одно число, а размах шести запусков — и это не педантизм: машина дрейфует, и на одной паре запусков разница в четыре процента не значила бы ничего. Запуски чередовались (без JIT, с JIT, без JIT, …), чтобы дрейф попал в оба режима одинаково, а вывод сведён к одному вопросу: пересекаются отрезки или нет.

Не пересекаются ни у одной нагрузки: самый быстрый запуск с JIT остаётся медленнее самого медленного без него.

Пар взято шесть, а не три, и это не запас прочности ради красоты. Вывод здесь держится не на величине разницы, а на том, что отрезки не пересеклись ни разу; для такого утверждения трёх пар мало.

Чего эти числа НЕ значат: приговора JIT. Четыре коротких цикла на двух ядрах в контейнере — не pyperformance и не настоящая программа. Право они дают на одно утверждение: включение второго уровня само по себе выигрыша не гарантирует, и проверять его надо на своём коде, а не по номеру версии.

Что из этого следует для кода

Три вывода, каждый — прямое следствие измеренного выше.

Однотипные места вызова дешевле разнотипных. Не потому, что «Python любит типы», а потому, что специализированная инструкция сверяет ровно одно предположение. Функция, через которую в горячем цикле ходят пять разных классов, платит половину сверху — и лечится это не аннотациями, а разделением на два места вызова. Полтора раза — это результат замера LOAD_ATTR на пяти классах, а не цена полиморфизма вообще: у другого семейства инструкций и другой нагрузки число будет своим. И порядок работ обычный: сначала профиль, потом правка формы вызова, а не наоборот.

__slots__ даёт другую инструкцию, а не только экономию памяти. LOAD_ATTR_SLOT против LOAD_ATTR_INSTANCE_VALUE — разные специализации, и выбор между ними делается один раз, при первом прогреве.

Микрозамеры меряют разогретый интерпретатор. Раз подстановка случается на втором выполнении, любой timeit с числом повторов больше двух работает уже на специализированном коде. Отдельно «мерить холодный старт» через timeit не получится — для этого нужен свежий объект кода на каждый замер.

История версий

Чем измерено

Числа этой статьи получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона: на чём считали, что получилось и с каким разбросом.

• bench/adaptive/cost.py
• bench/adaptive/jit.py
• bench/adaptive/specialize.py