🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Москве и поборись за призовой фонд 1 200 000 рублей!

Когда: 25–28 ноября
Формат: онлайн + финал на площадке

Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности
🔹развиваешься в направлении разработки, системной администрации, AI/ML или DevOps
🔹сможешь быть в Москве 28 ноября.

Выбери свой кейс:

✴️VibeCode Jam: собеседование будущего. Создай ИИ-платформу для прохождения технических собеседований с виртуальным интервьюером.

✴️Self-Deploy: CI/CD без DevOps. Автоматизируй генерацию CI/CD пайплайнов по анализу структуры Git-репозитория.

Почему стоит участвовать:
🔘Кейс в портфолио и полезная обратная связь от менторов Т1
🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний
🔘Реальный опыт командной работы
🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.

Регистрация открыта!
➡️ Успей до 23 ноября по ссылке.

Реклама.
О рекламодателе.

«Это же Python.. что ни сделай - всё в итоге аллоцируется».

Насколько это правда?

Разработчик внёс правку в CPython, чтобы логировались все аллокации объектов int. Затем запустил простой цикл сложения чисел 100 тысяч раз. В терминал прилетело 101006 сообщений.

Почему так много?

Во внутренних механизмах CPython каждое целое число представлено объектом PyLongObject в куче. И маленькие тоже.

Большинство VM используют tagged pointers, чтобы обойтись без лишних аллокаций. Даже Smalltalk в 80-х уже умел это. Python же идёт по тяжёлому пути: каждая аллокация тормозит работу, а редкий случай больших чисел ухудшает производительность самого частого кейса — простых интов.

Допущение: в тесте использовался print, который тоже может порождать новые ints. Разработчик убрал print. Количество аллокаций резко снизилось.

Куда делись остальные ~100k?

Смотрим функцию сложения ints. Если оба операнда меньше 2^30, их значения просто достаются и складываются напрямую. Тип stwodigits так и называется потому, что PyLongObject хранит число в основании 2^30 - каждый элемент массива хранит такой разряд.

Дальше вызывается _PyLong_FromSTwoDigits. В зависимости от величины числа - три пути.

Для маленьких чисел есть оптимизация: готовый статический массив маленьких PyLongObject, без аллокаций в куче. Просто возвращается указатель.

Для средних значений подключается другая функция. И вот что важно:

long_alloc тут не используется

Сначала пытается взять объект из freelist

Если нет свободных = создаёт новый

Freelist - типичная техника для переиспользования освобождённых объектов, чтобы лишний раз не трогать аллокатор.

В long_dealloc объект аккуратно возвращается в этот список.

Разработчик перенёс отладочный вывод в _PyLong_FromMedium: стало видно, что приличная часть объектов переиспользуется.

Но даже так накладные расходы огромные. На уровне процессора сложение двух int - одна инструкция ADD, исполняемая за один такт. В Python же вокруг неё целый аттракцион.

Плюс заметно отсутствие довольно старых оптимизаций, известных индустрии десятки лет.

Хороший пример того, что возможность контролировать аллокации позволяет строить специализированные аллокаторы и избавляться от мусора по пути.

И именно такие вещи делают языки вроде Zig привлекательными для разработчиков.

Подробнее с кодом: тык

👉 @PythonPortal