Ауф 🐺🐺🐺

С великим и ужасным @M0rtyMerr!!

«Python для собесов - 2026 🚀»

На днях я понял, что хоть мой канал и называется P(hD)ython, на нём всё ещё нет ни одного полноценного поста про Python 😅.

Исправим это! Запускаю серию постов, которые помогут Вам при прохождении Python-собеседований в 2026 году 😎.

Один из моих любимых вопросов на Python-собесах звучит так: «если все ругают Python за скорость, то почему на нём пишут столько ML и математики?!». Удивительно, но часто на нём сыплются даже матёрые разработчики.

Отвечаю! Сам по себе Python и правда медленный (почему - отдельный вопрос), но когда дело доходит до тяжёлых вычислений, оказывается, что он вызывает функции, написанные на компилируемых языках вроде Rust, C\C++ или... Fortran!

Так, например, numpy по сути является обёрткой над С-массивами, а scipy.linalg.lapack обычно импортирует Fortran-библиотеку LAPACK! Даже pytorch, исполняясь на GPU, по факту делает это на C\C++ & CUDA ⚙️.

Всё это достигается за счёт Foreign Function Interface (FFI) - механизма, позволяющего коду на одном языке вызывать функции, написанные на другом. FFI есть не только в Python. Он имеется в Rust (extern "C" & unsafe), Java (JNI & JNA), Go (cgo) и т.д., так что идея этого поста легко обобщается и на другие языки.

А теперь пример! Сегодня мы напишем свой собственный numpy с поэлементным умножением float-векторов!

Сперва реализуем функцию fmul поэлементного умножения float-векторов на C в файле fmul.c:

#include <stddef.h>
void fmul(const float* a, const float* b, float* out, size_t n) {
    for (size_t i = 0; i < n; ++i) out[i] = a[i] * b[i];
}

Скомпилируем его как разделяемую библиотеку:

gcc -O3 -fPIC -shared -o libfmul.so fmul.c

Установим cffi для поддержки FFI в Python:

pip install cffi

Теперь напишем Python-класс для работы с float-векторами и fmul в файле fmul.py:

from array import array
from pathlib import Path
from cffi import FFI

# через FFI подгружаем разделяемую библиотеку в Python-код
ffi = FFI()
ffi.cdef("void fmul(const float* a,const float* b,float* out,size_t n);")
C = ffi.dlopen(str(Path(__file__).with_name("libfmul.so")))

class F32Vec:
    # используем __slots__ для более компактного и производительного представления объектов класса
    __slots__ = ("a",)

    # требуем, чтобы наш класс конструировался из float-массива Python
    def __init__(self, data):
        self.a = (
            data
            if isinstance(data, array) and data.typecode == "f"
            else array("f", data)
        )

    def __len__(self):
        return len(self.a)

    def _mul_arr(self, other):
        if len(self.a) != len(other):
            raise ValueError("len mismatch")

        # готовим выходной массив
        out = array("f", [0.0]) * len(self.a)

        # вызываем через FFI C-функцию fmul
        C.fmul(
            ffi.from_buffer("float[]", self.a),
            ffi.from_buffer("float[]", other),
            ffi.from_buffer("float[]", out),
            len(self.a),
        )
        return F32Vec(out)

    # перегружаем операторы умножения, чтобы поэлементное произведение работало как в numpy
    def __mul__(self, other):
        if isinstance(other, F32Vec):
            return self._mul_arr(other.a)
        if isinstance(other, (int, float)):
            return self._mul_arr(array("f", [float(other)]) * len(self.a))
        return self._mul_arr(array("f", other))

    __rmul__ = __mul__

    def tolist(self):
        return list(self.a)

    def __repr__(self):
        return f"F32Vec({list(self.a)})"


if __name__ == "__main__":
    x = F32Vec([0.0, 0.5, 1.0, 1.5])
    y = F32Vec([1.0, 2.0, 3.0, 4.0])

    print(x._mul_arr(y.a))
    print((x * y).tolist())
    print((x * 2.0))
    print((2.0 * x).tolist())

Наконец, запустим код:

python3 fmul.py
F32Vec([0.0, 1.0, 3.0, 6.0])
[0.0, 1.0, 3.0, 6.0]
F32Vec([0.0, 1.0, 2.0, 3.0])
[0.0, 1.0, 2.0, 3.0]

Сегодня мы узнали, почему медленный Python способен быстро перемножать вектора, и как работает FFI! К сожалению, FFI громоздок и требует знания других языков. Как этого избежать - поговорим в следующем посте 🚀!

С уважением,
Михаил Масягин

«Python для собесов - 2026 🚀»

Продолжаем подготовку к Python-собесам!

В прошлом посте мы перенесли тяжёлую функцию из Python в C, используя механизм FFI. Сегодня мы научимся делать это более элегантно 💅 посредством Python-компиляторов, таких как Numba, Pythran или JAX. Они компилируют подмножество Python в машинный код для CPU или GPU, тем самым повышая производительность и оставаясь в рамках Python.

У каждого из приведённых инструментов своё собственное поддерживаемое подмножество Python, но базово можно считать, что все они способны компилировать функции, принимающие на вход, порождающие внутри себя и возвращающие:
- numpy-структуры данных, исключая object;
- Python-примитивы (int, float, complex, bool, str, ...);
- реже - гомогенные числовые списки (List[float], List[int], ...).

Python-компиляторы работают следующим образом:
- Вы пишете Python-функцию и помечаете её компилируемой с помощью декоратора (Numba, JAX) или комментария (Pythran).
- Далее, если компилятор работает как JIT (Just-in-Time), то он... ничего не делает 😄 (Numba, JAX), а вот AOT-компилятор сразу приступает к «конвертации» функции в машинный код (Pythran). Недостатком второго подхода является то, что он требует задавать типы входных данных на этапе написания кода. Кстати, в Numba так тоже можно сделать.
- При исполнении Python-кода в случае AOT'а сразу запускается «бинарная» версия функции, а в случае JIT'а - функция компилируется при первом вызове, а при последующих уже используется её производительная версия. В связи с этим JIT'ованные функции важно «прогревать» - вызывать их с примером входных параметров при инициализации приложения, дабы исключить задержки компиляции при исполнении. Отмечу, что Numba и Pythran налагают ограничения только на типы входных данных, а JAX - ещё и на их размер, то есть для Numba и Pythran вызовы func([1, 2, 3]) и func([4, 5]) идентичны, а для JAX они, грубо говоря, приводят к двум разным функциям.

Пара важных нюансов:
- Переходы между Python и скомпилированным кодом дороги. Чтобы их минимизировать, следует делать компилируемые функции крупнее. Например, если в коде есть обработка данных в цикле, то лучше компилировать цикл целиком.
- Чтобы не бить проект на отдельные компилируемые функции, можно использовать режим jit в Numba: он скомпилирует лишь то, что сможет. К сожалению, его производительность непредсказуема.

К примерам! Напишем функцию fmul из прошлого поста на Numba и Pythran. А на JAX можете написать сами 😄.

Numba:

Поставим Numba:

pip install numba

Затем создадим файл numba_demo.py:

import numpy as np
from numba import njit

@njit
def fmul_numba(a, b, out, n):
    for i in range(n):
        out[i] = a[i] * b[i]

out = np.empty(4, dtype=np.float64)
fmul_numba(np.array([0.0, 0.5, 1.0, 1.5]), np.array([1.0, 2.0, 3.0, 4.0]), out, 4)
print(out)

Запустим его:

python3 numba_demo.py
[0. 1. 3. 6.]

Pythran:

pip install pythran

fmul_pythran.py:

# pythran export fmul_pythran(float[], float[], float[], int)
def fmul_pythran(a, b, out, n):
    for i in range(n):
        out[i] = a[i] * b[i]

pythran_demo.py:

import numpy as np
from fmul_pythran import fmul_pythran
import sys

print(sys.modules["fmul_pythran"])

out = np.empty(4, dtype=np.float64)
fmul_pythran(np.array([0.0, 0.5, 1.0, 1.5]), np.array([1.0, 2.0, 3.0, 4.0]), out, 4)
print(out)

pythran fmul_pythran.py
ls
fmul_pythran.cpython-312-x86_64-linux-gnu.so  fmul_pythran.py  pythran_demo.py
python3 pythran_demo.py
<module 'fmul_pythran' from './fmul_pythran...so'>
[0. 1. 3. 6.]

Кстати, пару лет назад на одном из собесов мне пришлось писать Numba-код, так что это даже более актуально, чем FFI 🤓.

Сегодня мы познакомились с Python-компиляторами, в следующем посте поговорим о том, как понять, какие именно функции нам надо компилировать! ⚙️🚀

С уважением,
Михаил Масягин

«Python для собесов - 2026 🚀»

Продолжаем серию постов для Python-собесов!

В прошлых постах мы научились ускорять Python (FFI & Python Compilers). Теперь поговорим о том, что именно нужно ускорять, потому что оптимизировать абсолютно всё - сложно, долго и дорого (да зачастую и не нужно) 😵.

Базовый алгоритм выглядит следующим образом:
1. Замерили время выполнения кода.
2. Нашли узкое место.
3. Оптимизировали.
4. Проверили, что стало лучше. Если нет или недостаточно, то возвращаемся к пункту 1 😄.

Начнём с простейших измерений.

На собесах часто спрашивают как в коде замерить время выполнения отдельной функции. К сожалению, ответ time() встречается неприлично часто. Однако time() это так называемые «wall clock» 🕚 - они не монотонны (могут перепрыгивать из-за NTP, смены поясов, гибернации), а их точность и разрешение невысоки и зависят от настроек ОС. Вместо них лучше использовать монотонные счётчики:
- perf_counter_ns() - точный и монотонный аналог time() (для общих случаяев);
- process_time_ns() - только время на CPU (удобен для числодробилок).

Пример кода:

from time import perf_counter_ns as pc_ns

def work(n):
    s = 0
    for i in range(n):
        s += i*i
    return s

if __name__ == "__main__":
    t = pc_ns()
    work(1000000)
    dt = pc_ns() - t
    print(f"{dt/1e6:.3f} ms")

и его запуск:

python3 pc_ns_demo.py 
23.767 ms

Один прогон не слишком показателен - виной тому «шум» планировщика, кэши, вызовы GC и т.д. diff счётчиков можно сохранять в массив в цикле, но лучше использовать готовый инструмент - timeit. Он позволяет запускать много раз функции или даже программы, задавая как число прогонов в замере (number), так и число самих замеров (repeat), тем самым получая устойчивое распределение времени.

Пример кода:

import timeit
from pc_ns_demo import work

rs = timeit.repeat(lambda: work(1000000), number=10, repeat=10)

print("runs:")
for i, t in enumerate(rs, 1):
    print(f"  {i:02d}: {t/10*1e3:.3f} ms") 

bs = min(rs)
print(f"min: {bs/10*1e3:.3f} ms")

и его вызов:

python3 timeit_demo.py 
runs:
  01: 23.849 ms
  ...
  10: 23.650 ms
min: 23.650 ms

Ещё короче:

python3 -m timeit -n 10 -r 10 -u msec -s "from pc_ns_demo import work" "work(1000000)"
10 loops, best of 10: 23.5 msec per loop

Поговорим о профилировании - определении конкретных медленных участков кода с cProfile. Он позволяет подсчитать число вызовов каждой функции (ncalls), её целевое и суммарное время исполнения (без/с учётом вызовов функций внутри) (tottime, percall, cumtime, percall) с привязкой к определению (filename:...).

Запуск профайлера для программы:

python3 -m cProfile -o prof.bin pc_ns_demo.py
24.467 ms

python -c "import pstats;p=pstats.Stats('prof.bin');p.sort_stats('tottime').print_stats(20)"
Fri Dec 19 06:00:17 2025    prof.bin

         7 function calls in 0.024 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.024    0.024    0.024    0.024 pc_ns_demo.py:3(work)
   ...

Файл prof.bin можно визуализировать пакетом snakeviz - скрин в комментах.

И внутри python-кода:

import cProfile
import pstats
from io import StringIO
from pc_ns_demo import work

def kek(a, b, c):
    return work(a) + work(b) + work(c)

pr = cProfile.Profile()
pr.enable()
print(kek(1000000, 2000000, 3000000))
pr.disable()

s = StringIO()
pstats.Stats(pr, stream=s).sort_stats("cumtime").print_stats(5)
print(s.getvalue())

и запуск:

python3 cprofile_demo.py
11999993000001000000
         6 function calls in 0.146 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.146    0.146 /home/mikhail/cprofile_demo.py:6(kek)
        3    0.146    0.049    0.146    0.049 /home/mikhail/pc_ns_demo.py:3(work)
...

Существуют и другие инструменты вроде py-spy и scalene. Они позволяют периодически дампить callstack процесса, а scalene показывает ещё и аллокации 🤓. Вот мы и познакомились с джентльменским набором тайминга и профайлинга в Python! ⚙️🚀

С уважением,
Масягин Михаил

«Итоги 2025: Python 3.14 🐍 и немного моей жизни 🎄»

Ну что, под Новый Год самое время подвести итоги. 7 октября 2025 вышла финальная версия Python 3.14.0, меняющая как внутреннее устройство языка, так и добавляющая в него новые полезные функции. Число и значимость изменений сравнимы с 3.4.0, подарившей нам asyncio в 2014 году!

1. Kill GIL! Как известно, у змей - раздвоенный язык, и Python теперь - не исключение. Начиная с 3.14.0 существуют 2 сборки CPython - стандартная 3.14 и... 3.14t без GIL! Теперь, пусть и с рядом новых трудностей, мы можем достигать в Python истинного параллелизма потоков исполнения прямо как в C\C++, Java и т.д.!
2. concurrent.interpreters - до тех пор, пока 3.14t не станет стандартом запуск нескольких независимых интерпретаторов всё ещё актуален. Что же, теперь мы можем делать это в рамках одного процесса, минимизируя траты на IPC!
3. Отладка современного Python-кода стала ещё проще и приятнее - к целевому процессу можно подключиться на лету без необходимости его перезапуска!
4. Инкрементальный GC - осталось лишь 2 поколения объектов: молодое и старое, и на каждом цикле GC сканируется всё молодое и эвристически лишь часть старого. За счёт этого работа сборщика мусора стала предсказуемее и стабильнее.
5. Ряд оптимизаций байткода Python, включая Tail Calling.
6. t-strings - всё те же f-strings, но теперь завёрнутые в отдельный класс!
7. Аннотации больше не тормозят import'ы, так как вычисляются отложенно, а ещё их можно анализировать через annotationlib.
8. Все мы знаем, что zstd - это база, а теперь это знает и Python! zstandard теперь входит в стандартную поставку интерпретатора!
9. И много-много чего ещё!

Все фичи подробно разберём в постах 2026 года!

Ну и пару слов о моих итогах 😅:

1. Начал разбирать Кабанчика 🐷 на System Design World с @vova_dev!
2. Запустили с @vova_dev наш курс по System Design! Уже прошло 3 потока и на подходе 4!
3. + 1 новая статья ВАК/WoS и Conference Paper в IEEE - за последнее отдельное спасибо @Kvassir!
4. Выступил с лекциями по HFT на ICPC, FaangTalk (@volyx ❤️) и в Бауманке!
5. Пережил ремонт и даже несмотря на него побывал в новой стране - Вьетнаме!
6. Познакомился со столькими замечательными людьми: @vova_dev, @LooksOfTheMoon, @terapsyda - вы лучшие ❤️!
7. Начал активно собесить не только питонистов, но и растовчан на работе 💪!
8. Завёл канал, где вы сейчас и читаете этот пост! Нас уже 160+ 👫!

Были и факапы, главный - диссер с конца 2025 года переехал на весну 2026 года 😢.

К чему я это всё? Думаю, к тому, что надо работать, фигачить, выкладываться на 110%! Достичь всего - нереально, многого - очень сложно, но возможно 💪!

С Новым Годом, друзья 🎄! Соблюдаем Work-Job Balance и идём седлать огненного коня 2026 года 🎠!

С уважением,
Михаил Масягин