История профайлеров и ловушки микробенчей: от Кнута до GWP

Дефолтный warmup JMH для Java — 5 итераций. Он существует не ради производительности — он нужен потому, что без него твой бенчмарк измеряет интерпретатор, а не production JIT. Большинство команд, впервые самостоятельно пишущих микробенчмарки, делают эту ошибку с первого прогона.

Интеллектуальная родословная: от Амдала до GWP

Дисциплина «профиль первым» имеет 60-летнюю родословную.

Джин Амдал, 1967 — «Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities». Показал, что последовательная часть нагрузки ограничивает ускорение, которое способно дать любое количество параллельных процессоров. Исходный аргумент за измерение доли перед оптимизацией.

Дональд Кнут, 1974 — «Structured Programming with Go To Statements», ACM Computing Surveys. Ввёл формулировку «преждевременная оптимизация — корень всех зол», с полным предложением, называющим разделение 97/3: большая часть кода не имеет значения; критическая доля имеет, и её идентификация — это и есть инженерная работа.

Джон Густафсон, 1988 — «Reevaluating Amdahl’s Law». Утверждал, что по мере роста размера задач параллелизуемая доля растёт, так что пессимизм Амдала занижает достижимое ускорение на реальных нагрузках. Закон Густафсона: масштабированное_ускорение = s + p × N, где N — количество процессоров, а нагрузка растёт вместе с N.

Google Wide Profiling (GWP), 2010 — Рен и соавторы, IEEE Micro. Показали непрерывное профилирование всего датацентра при накладных расходах менее 0.01% с помощью статистического мультиплексирования. Эта техника стала Pyroscope, Parca, Polar Signals и категорией непрерывного профилирования.

Дуга: идентифицируй узкое место (Амдал 1967) → назови это дисциплиной (Кнут 1974) → уточни модель при масштабировании (Густафсон 1988) → сделай измерение бесплатным и постоянным (GWP 2010, Pyroscope 2020-е). Каждый слой добавил ограничение, ставшее стандартной практикой.

Ловушки микробенчей в JIT-рантаймах

Наивные микробенчи почти по умолчанию неверны в JIT-компилируемых рантаймах (JVM, V8, .NET CLR, PyPy).

Проблема JIT warmup. Ступенчатая компиляция HotSpot: ~10k вызовов для C1 (базовый), ~100k для C2 (оптимизированный). Микробенч, вызывающий функцию 1k раз, измеряет интерпретатор или базовый JIT, а не оптимизированный код, работающий в продакшене. JMH справляется с этим явными warmup-итерациями (по умолчанию 5 итераций × 10 с каждая до начала измерения).

Устранение мёртвого кода. Если результат бенчмарка не используется, оптимизатор полностью удаляет тело цикла. Цикл выполняется за микросекунды и репортирует невозможное ускорение. testing.B в Go требует записи результата в sink-переменную пакета (var sinkResult = result). JMH использует Blackhole.consume(result).

Свёртка констант. Если входные данные цикла — константы времени компиляции, оптимизатор вычисляет ответ один раз и заменяет цикл литералом. Цикл, вычисляющий md5("fixed-string") 1M раз, может свернуться в единственную загрузку константы. Решение: параметризовать входные данные во время выполнения из непостоянного источника (JMH @Param, Go benchmark + внешние данные).

Различия в инлайнинге. Микробенч может инлайнить функцию, которую продакшен не инлайнит (или наоборот), потому что дерево вызовов бенчмарка проще. Аннотации @CompilerControl в JMH позволяют принудительно включать или отключать инлайнинг для соответствия production-поведению.

Масштабирование частоты CPU. CPU ноутбуков агрессивно троттлятся: время бенчмарка функции варьируется на 30% между холодным стартом и троттлингом. Production-железо имеет другие политики частоты. Всегда бенчмаркируй на представительном железе с отключенным масштабированием частоты или зафиксированными тактами.