Машина исполнения

Фрейм — это всё, что нужно для одного активного вызова: массив локальных переменных, стек значений, ссылка на code object, указатель текущей инструкции f_lasti и ссылка на вызывающий фрейм.

В 3.11 устройство поменялось принципиально. Раньше каждый вызов создавал полноценный объект frame в куче — со счётчиком ссылок, заголовком и участием в сборке мусора. Теперь фреймы выделяются подряд в непрерывном куске памяти, своём на каждый поток (Include/internal/pycore_frame.h), а объект frame создаётся только если кто-то его попросил: трассировка исключения, sys._getframe(), отладчик, профилировщик.

import sys, timeit

s = '''
import sys
def plain(n):
    t = 0
    for _ in range(n): t += 1
    return t
def with_frame(n):
    t = 0
    for _ in range(n):
        sys._getframe(); t += 1
    return t
plain(100); with_frame(100)
'''
print(min(timeit.repeat("plain(1_000_000)", s, number=1, repeat=5)))
print(min(timeit.repeat("with_frame(1_000_000)", s, number=1, repeat=5)))
# → 0.033
# → 0.057   ← +23 нс за материализацию объекта фрейма

Двадцать три наносекунды за каждый sys._getframe() — это и есть цена того, чего в обычном исполнении больше не платят. Отсюда практическое: библиотека логирования, определяющая вызывающего через фрейм, стоит дороже, чем кажется, и в горячем цикле это видно.

Урок 22, фаза 6: таблица символов расставила локальным переменным индексы. Поэтому LOAD_FAST 0 — чтение нулевого элемента массива, а не поиск по имени. Массив лежит в начале фрейма, сразу за ним — стек значений глубиной ровно co_stacksize, размер известен с компиляции.

Следствие, которое регулярно ловит людей в отладчике:

import sys

def f():
    x = 1
    sys._getframe().f_locals["x"] = 999
    return x

print(f())
# → 1     ← запись не подействовала

f_locals у функции — снимок, собранный из массива по требованию, а не живой словарь. Записать через него нельзя. На уровне модуля всё иначе: там локальные и есть глобальные, и f_locals is globals() истинно.

Выражение раскладывается в постфиксную запись, как на калькуляторе с обратной польской нотацией:

import dis
def expr(a, b, c): return a + b * c
dis.dis(expr)
print(expr.__code__.co_stacksize)
# →  2 LOAD_FAST   0 (a)
# →  4 LOAD_FAST   1 (b)
# →  6 LOAD_FAST   2 (c)
# →  8 BINARY_OP   5 (*)
# → 12 BINARY_OP   0 (+)
# → 16 RETURN_VALUE
# → 3

Три значения на стеке в пике — ровно co_stacksize. Проверок переполнения при исполнении нет: место выделено заранее, потому что компилятор посчитал максимум статически.

Python/ceval.c, функция _PyEval_EvalFrameDefault — несколько тысяч строк, по ветке на инструкцию. Формат простой: каждая инструкция ровно два байта — опкод и однобайтовый аргумент. Аргументы больше 255 собираются из префиксов EXTENDED_ARG.

Переход к следующей инструкции — не switch, а computed goto: таблица адресов меток (Python/opcode_targets.h), и в конце каждой ветки прямой прыжок по адресу следующего опкода. Это даёт процессору отдельную точку предсказания перехода на каждую инструкцию вместо одной общей, и стоит порядка пятнадцати процентов скорости.

import sysconfig
print(sysconfig.get_config_var("USE_COMPUTED_GOTOS"))
# → 1

Замер пропускной способности на этой машине: цикл t += 1 на десять миллионов итераций — 0.325 с, то есть около шести наносекунд на инструкцию байткода. Для сравнения, вызов пустой функции — 27 нс, то есть примерно пять инструкций.

Это главное изменение 3.11 (PEP 659) и прямое следствие R2: типы неизвестны при компиляции, значит их надо узнавать при исполнении — и запоминать.

Фрагмент B показывает механику в байтах. У LOAD_ATTR четыре ячейки кеша, то есть восемь байт, лежащих внутри потока инструкций сразу за ней. Хранится там версия типа и смещение атрибута. Опкод CACHE имеет номер 0, и цикл вычисления его просто перешагивает.

import dis
print(dis.opmap["CACHE"], dis.opmap["LOAD_ATTR"])
# → 0 106
print(dis._inline_cache_entries[dis.opmap["LOAD_ATTR"]], "ячеек по 2 байта")
# → 4 ячеек по 2 байта
print(len(dis.opmap), "базовых опкодов,", len(dis._specialized_instructions), "специализированных")
# → 110 базовых опкодов, 71 специализированных
print(sum(1 for x in dis._inline_cache_entries if x), "опкодов носят кеш")
# → 11 опкодов носят кеш

Как это работает. Сначала стоит общая инструкция со счётчиком «прогрева». Когда счётчик срабатывает, инструкция превращается в *_ADAPTIVE, которая смотрит на фактические операнды и переписывает себя в узкоспециализированную: LOAD_ATTR_INSTANCE_VALUE, LOAD_ATTR_SLOT, LOAD_ATTR_MODULE, BINARY_OP_ADD_INT и так далее. Специализированная версия проверяет только своё предположение — одно сравнение версии типа — и делает работу напрямую.

Если предположение перестало выполняться, инструкция деоптимизируется обратно в общую. Отсюда результат из урока 21: однородная коллекция обходится в 1.4 раза быстрее смеси классов. Не потому, что смесь «сложнее», а потому, что кеш промахивается и специализация не удерживается.

Это не JIT: машинный код не генерируется, инструкции остаются байткодом. JIT появился в 3.13 и работает поверх этого механизма, а не вместо него.

До 3.11 вызов Python-функции означал рекурсивный заход в _PyEval_EvalFrameDefault: кадр C-стека на каждый кадр Python. Отсюда историческая связка «предел рекурсии 1000, иначе сегфолт».

В 3.11 инструкция CALL на Python-функцию просто подкладывает новый фрейм в чанк и продолжает тот же цикл. C-стек не растёт:

import sys
sys.setrecursionlimit(30000)

def rec(n): return 0 if n == 0 else rec(n - 1)
print(rec(20000))
# → 0     ← двадцать тысяч кадров, процесс жив

Но sys.setrecursionlimit по-прежнему опасен, и вот почему: рекурсия, проходящая через C, C-стек тратит. __repr__ вложенной структуры, __eq__ с рекурсивным вызовом, сравнение глубоко вложенных списков — всё это идёт через C-функции, и там предел защищает от настоящего исчерпания стека, а не от логической ошибки. Поднимать лимит можно, только если точно знаешь, что рекурсия чисто питоновская.

Фрагмент C: try, в котором ничего не бросается, стоит ровно ноль. До 3.11 вход в блок исполнял SETUP_FINALLY, которая клала обработчик на стек блоков — то есть за каждый проход платили, даже когда исключений не было.

Теперь информация об обработчиках вынесена в co_exceptiontable — таблицу, которая не исполняется, а читается только в момент броска:

import dis

def with_try(n):
    t = 0
    for i in range(n):
        try: t += i
        except ValueError: pass
    return t

for e in dis._parse_exception_table(with_try.__code__):
    print(e)
# → _ExceptionTableEntry(start=40, end=50, target=52, depth=1, lasti=False)
# → _ExceptionTableEntry(start=52, end=72, target=78, depth=2, lasti=True)
# → _ExceptionTableEntry(start=76, end=78, target=78, depth=2, lasti=True)

Читается так: «если исключение возникло на смещении от 40 до 50 — прыгай на 52, стек при этом раскрути до глубины 1». При броске интерпретатор берёт текущий f_lasti, ищет подходящую строку, и если её нет — снимает фрейм и ищет в вызывающем. Это и есть раскрутка стека.

Пока не бросает — бесплатно; когда бросает — 154 наносекунды за штуку. Это точная формулировка того, когда EAFP выигрывает у LBYL, а когда проигрывает.

В цикле вычисления есть один флаг, который проверяется на границах инструкций, — eval breaker. Он объединяет всё, что должно случиться «не прямо сейчас, но скоро»: просьба отдать GIL (урок 19), доставленный сигнал ОС, отложенные вызовы.

Отсюда три вещи, которые обычно знают по отдельности:

• Ctrl-C не прерывает длинный вызов в C. Обработчик сигнала на уровне ОС только выставляет флаг; Python-обработчик вызовется, когда управление вернётся в цикл. Пока numpy считает матрицу, возвращаться некуда.
• GIL переключается на границе инструкции, а не в произвольный момент. Поэтому одна инструкция байткода неделима — и поэтому же x += 1 всё равно гонка: это несколько инструкций.
• Составная операция не атомарна ровно по той же причине: между двумя инструкциями может влезть кто угодно.

Урок 13 сказал: генератор хранит приостановленный кадр. Здесь видно, что это буквально:

def gen():
    a = 1
    yield a
    b = 2
    yield a + b

g = gen()
print(g.gi_frame.f_lasti)              # → 0    ещё не начинали
next(g)
print(g.gi_frame.f_lasti, g.gi_frame.f_locals)   # → 12 {'a': 1}
next(g)
print(g.gi_frame.f_locals)                       # → {'a': 1, 'b': 2}
try: next(g)
except StopIteration: pass
print(g.gi_frame)                                # → None   фрейм отпущен

yield не разрушает фрейм, а сохраняет f_lasti и отдаёт управление. Следующий next продолжает с той же инструкции. У генератора фрейм не может жить в общем чанке потока — он переживает вызов, — поэтому для него фрейм копируется в объект генератора.

На этом же механизме стоит await: корутина — тот же приостановленный фрейм, только с другим протоколом возобновления (урок 14).

Py_FinalizeEx из Python/pylifecycle.c разбирает интерпретатор в фиксированном порядке. Порядок наблюдаем:

import atexit

class Noisy:
    def __init__(self, name): self.name = name
    def __del__(self): print("__del__", self.name)

keep = Noisy("модульная переменная")
atexit.register(lambda: print("atexit сработал"))

def main():
    local = Noisy("локальная")
    print("main закончилась")

main()
print("конец модуля")
# → main закончилась
# → __del__ локальная          ← счётчик ссылок, сразу на выходе из функции
# → конец модуля
# → atexit сработал            ← до разбора модулей
# → __del__ модульная переменная

Локальная умирает по счётчику ссылок в момент выхода из функции (урок 09). atexit отрабатывает, пока модули ещё целы. Модульные глобальные обнуляются последними — и вот здесь начинается зона, где __del__ уже не гарантирован: модули частично разобраны, импортов больше нет, порядок не определён 🕳.

И совсем мимо всего этого проходит os._exit: он завершает процесс системным вызовом, не давая отработать ни atexit, ни деструкторам, ни сбросу буферов. Иногда это ровно то, что нужно после fork; во всех остальных случаях это способ потерять данные.