Ваш код работает быстро — если вам повезло: почему ваши микро-бенчмарки врут

Вирусный твит ставит под сомнение надёжность микро-бенчмарков: один и тот же код может показывать разницу в 30% в зависимости от порядка символов, расположения в памяти или имени пользователя. Что это меняет для крафта.

Простыми словами

Разработчик показал, что один и тот же фрагмент кода может работать на 30% быстрее или медленнее в зависимости от параметров, не имеющих отношения к алгоритму: порядок символов при линковке, размер переменных окружения, выравнивание памяти. Иными словами, значительная часть измерений в микросекундах зависит от удачи.

История

Автор на

tiki.li/blog/lucky_code[/ENCADRE] возвращается к хорошо известной теме в компиляторах (Emery Berger, Stabilizer, ASPLOS 2013) и освежает её: он выполняет один и тот же бинарный файл без изменений, варьируя периферийные параметры (название директории сборки, порядок линковки объектных файлов, размер $PATH). Время выполнения меняется значительно, до 30% на микро-тестах. Причина: выравнивание инструкций в кэшах L1i/uop, декодере x86 и предсказании ветвлений, которые зависят от виртуального адреса кода.

То, что должно беспокоить всех: в реальной жизни мы сравниваем PR до/после, отмечаем прирост в 8%, и вливаем изменения. Сколько из этих приростов — реальный сигнал? Сколько — шум от выравнивания?

Под капотом

• Stabilizer (Berger 2013)
  Stabilizer (Berger 2013)[/ENCADRE] рандомизирует выделение стека, кучи и кода при каждом запуске — измерения становятся распределениями, а не точками.
• Hyperfine + `-warmup` + `-runs 50`
  Hyperfine + -warmup + -runs 50[/ENCADRE] не решает проблему: оно усредняет, но выравнивание остаётся одинаковым при каждом запуске одного и того же бинарного файла.
• Хорошая практика
  Хорошая практика[/ENCADRE]: пересобрать с случайными смещениями (Stabilizer или ручное паддинг) ИЛИ запускать с -randomize-address и приводить 95% доверительный интервал, а не среднее.

Что делать

Три последствия для мастерства. Первое: любой прирост производительности менее 10% на одном микро-тесте, скорее всего, шум. Его стоит отвергнуть или повторить с рандомизацией. Второе: регрессии производительности в CI (например, Codspeed) должны использовать рандомизацию, иначе мы будем пропускать реальные регрессии и паниковать из-за шума. Третье: маркетинговые бенчмарки компиляторов и рантаймов (Bun vs Node, Zig vs C…) стоит читать с этой поправкой. Производительность на этом уровне зависит не меньше от инженерии сборки, чем от алгоритма.