В CPython ускорили reference counting
В CPython основа управления памятью это reference counting: у каждого объекта есть счётчик ссылок, и при каждом “взял/отпустил” он инкрементится/декрементится. В цикле, который крутится очень много раз, это превращается в ощутимый оверхед и лишние записи в память (да, даже чтение переменной = запись из-за refcount).
С Python 3.14 добавили новую байткод-инструкцию: LOAD_FAST_BORROW.
Что меняется:
- раньше LOAD_FAST грузил локалку и поднимал refcount
- теперь LOAD_FAST_BORROW грузит локалку без инкремента
- есть ещё “склеенные” опкоды типа LOAD_FAST_BORROW_LOAD_FAST_BORROW (две загрузки за один opcode)
Зачем это нужно:
- меньше дергаем refcount в hot-path
- меньше мусора в CPU cache
- быстрее на циклах, где ты постоянно читаешь одни и те же локальные переменные
Но оптимизация включается не всегда. CPython применяет её только когда может доказать безопасность через статический анализ времени жизни (по CFG):
- значение используется “локально” и быстро потребляется
- не утекает в heap/генераторы/кадры
- источник не перезаписывается так, чтобы сломать “borrow”
Это похоже на упрощённые Rust lifetimes/borrowing, только на уровне байткода.
👉 @PythonPortal
В CPython основа управления памятью это reference counting: у каждого объекта есть счётчик ссылок, и при каждом “взял/отпустил” он инкрементится/декрементится. В цикле, который крутится очень много раз, это превращается в ощутимый оверхед и лишние записи в память (да, даже чтение переменной = запись из-за refcount).
С Python 3.14 добавили новую байткод-инструкцию: LOAD_FAST_BORROW.
Что меняется:
- раньше LOAD_FAST грузил локалку и поднимал refcount
- теперь LOAD_FAST_BORROW грузит локалку без инкремента
- есть ещё “склеенные” опкоды типа LOAD_FAST_BORROW_LOAD_FAST_BORROW (две загрузки за один opcode)
Зачем это нужно:
- меньше дергаем refcount в hot-path
- меньше мусора в CPU cache
- быстрее на циклах, где ты постоянно читаешь одни и те же локальные переменные
Но оптимизация включается не всегда. CPython применяет её только когда может доказать безопасность через статический анализ времени жизни (по CFG):
- значение используется “локально” и быстро потребляется
- не утекает в heap/генераторы/кадры
- источник не перезаписывается так, чтобы сломать “borrow”
Это похоже на упрощённые Rust lifetimes/borrowing, только на уровне байткода.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤9
Что если бы ты мог увидеть всё дерево зависимостей одной командой?
Отлаживать конфликты версий можно только когда понимаешь, какие пакеты от чего зависят. Но вручную разбирать эти связи в куче вложенных зависимостей это уныло и долго.
uv tree делает это автоматически: выводит полный граф зависимостей, чтобы ты мог отследить любой пакет и понять, откуда он подтянулся.
Ключевые возможности:
✅ Полная визуализация зависимостей
✅ Помечает зависимости, для которых есть доступные обновления
✅ Показывает, какие пакеты зависят от конкретной библиотеки
✅ Фильтрует дерево, чтобы показать только зависимости выбранного пакета
Установка
👉 @PythonPortal
Отлаживать конфликты версий можно только когда понимаешь, какие пакеты от чего зависят. Но вручную разбирать эти связи в куче вложенных зависимостей это уныло и долго.
uv tree делает это автоматически: выводит полный граф зависимостей, чтобы ты мог отследить любой пакет и понять, откуда он подтянулся.
Ключевые возможности:
Установка
uv: pip install uvPlease open Telegram to view this post
VIEW IN TELEGRAM
❤14
Коллекция книг по машинному обучению и искусственному интеллекту в формате PDF: забираем
👉 @PythonPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9