Что такое микробенчмаркинг?

Это означает именно то, что написано на консервной банке - это измерение производительности чего-то «маленького», например, системного вызова ядра операционной системы.

Опасность состоит в том, что люди могут использовать любые результаты микробенчмаркинга, чтобы диктовать оптимизацию. И как все мы знаем:

Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - корень всех зол », - Дональд Кнут

Результат микротестов может быть искажен по многим причинам. Оптимизация компилятора - одна из них. Если измеряемая операция занимает так мало времени, что все, что вы используете для измерения, занимает больше времени, чем сама операция, ваши микротесты также будут искажены.

Например, кто-то может провести микробенчмарк накладных расходов for циклов:

void TestForLoop()
{
    time start = GetTime();

    for(int i = 0; i < 1000000000; ++i)
    {
    }

    time elapsed = GetTime() - start;
    time elapsedPerIteration = elapsed / 1000000000;
    printf("Time elapsed for each iteration: %d\n", elapsedPerIteration);
}

Очевидно, компиляторы могут видеть, что цикл абсолютно ничего не делает и вообще не генерирует никакого кода для цикла. Таким образом, значение elapsed и elapsedPerIteration практически бесполезно.

Даже если цикл что-то делает:

void TestForLoop()
{
    int sum = 0;
    time start = GetTime();

    for(int i = 0; i < 1000000000; ++i)
    {
        ++sum;
    }

    time elapsed = GetTime() - start;
    time elapsedPerIteration = elapsed / 1000000000;
    printf("Time elapsed for each iteration: %d\n", elapsedPerIteration);
}

Компилятор может увидеть, что переменная sum не будет использоваться ни для чего, и оптимизирует ее, а также оптимизирует цикл for. Но ждать! Что, если мы сделаем это:

void TestForLoop()
{
    int sum = 0;
    time start = GetTime();

    for(int i = 0; i < 1000000000; ++i)
    {
        ++sum;
    }

    time elapsed = GetTime() - start;
    time elapsedPerIteration = elapsed / 1000000000;
    printf("Time elapsed for each iteration: %d\n", elapsedPerIteration);
    printf("Sum: %d\n", sum); // Added
}

Компилятор может быть достаточно умен, чтобы понять, что sum всегда будет постоянным значением, и оптимизировать все это. Многие были бы удивлены возможностями оптимизации компиляторов в наши дни.

Но как насчет того, что компиляторы не могут оптимизировать?

void TestFileOpenPerformance()
{
    FILE* file = NULL;
    time start = GetTime();

    for(int i = 0; i < 1000000000; ++i)
    {
        file = fopen("testfile.dat");
        fclose(file);
    }

    time elapsed = GetTime() - start;
    time elapsedPerIteration = elapsed / 1000000000;
    printf("Time elapsed for each file open: %d\n", elapsedPerIteration);
}

Даже это бесполезный тест! Операционная система может видеть, что файл открывается очень часто, поэтому может предварительно загрузить его в память для повышения производительности. Практически все операционные системы делают это. То же самое происходит, когда вы открываете приложения - операционные системы могут определить ~ 5 приложений, которые вы открываете чаще всего, и предварительно загрузить код приложения в память при загрузке компьютера!

Фактически, в игру вступает бесчисленное множество переменных: местоположение ссылки (например, массивы или связанные списки), влияние кешей и пропускной способности памяти, встраивание компилятора, реализация компилятора, переключатели компилятора, количество ядер процессора, оптимизация на уровне процессора. , планировщики операционных систем, фоновые процессы операционной системы и т. д.

Так что во многих случаях микробенчмаркинг не совсем полезный показатель. Это определенно не заменяет тесты производительности всей программы четко определенными тестовыми примерами (профилирование). Сначала напишите читаемый код, затем профилируйте, чтобы увидеть, что нужно сделать, если таковые имеются.

Я хотел бы подчеркнуть, что микробенчмарки не являются злом сами по себе, но их нужно использовать осторожно (это верно для многих других вещей, связанных с компьютерами)

Определения микротеста нет, но когда я его использую, я имею в виду небольшой искусственный тест, предназначенный для проверки производительности некоторого конкретного аппаратного ¹ или языковой функции. Напротив, лучший тест - это реальная программа, предназначенная для выполнения реальной задачи. (Проводить жесткую грань между двумя случаями бессмысленно, ИМО, и я не буду пытаться.)

Опасность микробенчмаркинга заключается в том, что легко написать тест, который дает результаты, которые полностью вводят в заблуждение. Вот некоторые распространенные ловушки микро-тестов Java:

• написание кода, который компилятор может определить, бесполезно, и поэтому полностью оптимизировать,
• не принимая во внимание "комковатую" природу управления памятью Java, и
• без учета эффектов запуска JVM; например время, необходимое для загрузки и JIT-компиляции классов, и (наоборот) ускорение выполнения, которое происходит после JIT-компиляции методов.

Однако даже после того, как вы решите вышеперечисленные проблемы, существует системная проблема с тестированием производительности, которую невозможно решить. Код и поведение теста обычно мало связаны с тем, что вас действительно волнует; т.е. как ваше приложение будет работать. Существует слишком много «скрытых переменных», чтобы вы могли сделать выводы, начиная с эталонного теста и заканчивая типичными программами, не говоря уже о вашей программе.

По этим причинам мы регулярно советуем НЕ тратить время на микротест. Вместо этого лучше писать простой и естественный код и использовать профилировщик для определения областей, которые необходимо оптимизировать вручную. Интересно, что обычно оказывается, что наиболее значительные проблемы с производительностью в реальных приложениях возникают из-за плохого проектирования структур данных и алгоритмов (включая узкие места, связанные с сетью, базами данных и потоковой передачи), а не из-за того, что типичные микротесты пытаются решить. контрольная работа.

@BalusC предоставил отличную ссылку на материалы по этой теме в FAQ по Hotspot страница. А вот ссылка на технический документ IBM от Брайана Гетца.

^{1 - Эксперты даже не стали бы пытаться проводить тестирование оборудования на Java. Между байт-кодами и оборудованием происходит слишком много «сложных вещей», чтобы сделать правильные / полезные выводы об оборудовании из необработанных результатов. Вам будет лучше использовать язык, более близкий к аппаратному обеспечению; например C или даже код сборки.}

В книге «Производительность Java: полное руководство» есть это определение и пример микробенчмарков:

1. Микробенчмарки

   Микробенчмарк - это тест, предназначенный для измерения производительности очень небольшого устройства: времени для вызова синхронизированного метода по сравнению с несинхронизированным методом; накладные расходы на создание потока по сравнению с использованием пула потоков; время выполнения одного арифметического алгоритма по сравнению с альтернативной реализацией; и так далее.

   Микробенчмарки могут показаться хорошей идеей, но их очень сложно написать правильно. Рассмотрим следующий код, который представляет собой попытку написать микробенчмарк, который проверяет производительность различных реализаций метода вычисления 50-го числа Фибоначчи:

public void doTest(){
double l;
long then = System.currentTimeMillis();

for(int i = 0; i < nLoops; i++){
 l = fibImpl1(50);
}

long now = system.currentTimeMillis();
System.out.println("Elapsed time: " + (now - then))

}

...

private double fibImpl1(int n){
if(n < 0) throw new IllegalArgumentException("Must be > 0");
if(n == 0) return 0d;
if(n == 1) return 1d;
double d = fibImpl1(n - 2) + fibImpl(n - 1);
if(Double.isInfinited(d)) throw new ArithmeticException("Overflow");
return d;
}

Микробенчмарки должны использовать их результаты.

Самая большая проблема с этим кодом заключается в том, что он никогда не меняет состояние программы. Поскольку результат вычисления Фибоначчи никогда не используется, компилятор может отказаться от этого вычисления. Умный компилятор (включая текущие компиляторы Java 7 и 8) в конечном итоге выполнит этот код:

long then = System.currentTimeMillis();
long now = System.currentTimeMillis();
System.out.println("Elapsed time: " + (now - then));

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

Есть способ обойти эту конкретную проблему: убедиться, что каждый результат читается, а не просто записывается. На практике изменение определения l с локальной переменной на переменную экземпляра (объявленную с ключевым словом volatile) позволит измерить производительность метода.

• Что это означает, а что НЕ?

Я бы сказал, что микротест - это просто измерение чего-то крошечного. Tiny, вероятно, зависит от контекста, но обычно на уровне отдельного системного вызова или чего-то подобного. Бенчмаркинг относится ко всему вышеперечисленному.

• Какие примеры микробенчмаркинга ЕСТЬ и НЕ НЕТ?

В этой (заархивированной) статье перечислены измерение времени системного вызова getpid () и измерение времени для копирования памяти с помощью memcpy () в качестве примеров микробенчмаркинга.

Любое измерение реализации алгоритма и т. Д. Не будет считаться микробенчмаркингом. В частности, отчеты о результатах, в которых перечислены задачи с уменьшающимся временем выполнения, вероятно, редко считаются микробенчмаркингом.

• В чем опасность микробенчмаркинга и как его избежать?

Очевидная опасность состоит в том, что это соблазняет разработчиков оптимизировать неправильные части программы. Другая опасность заключается в том, что, как известно, трудно точно измерить что-то маленькое. Самый простой способ избежать этого, вероятно, - просто получить хорошее представление о том, где больше всего времени проводится в программе.

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

• (или это хорошо?)

Само по себе это совсем не плохо, как другие здесь, и многие веб-страницы, кажется, предполагают. В нем есть свои места. Я работаю с переписыванием программ и переплетением аспектов времени выполнения и т. Д. Обычно мы публикуем микротесты наших добавленных инструкций не для направления каких-либо оптимизаций, а для того, чтобы убедиться, что наш дополнительный код практически не влияет на выполнение переписанной программы.

Однако это искусство, особенно в контексте виртуальной машины с JIT, временем прогрева и т. Д. Хорошо описанный подход для Java описан здесь (архив).

Вот несколько хороших статей Брайана Гетца, объясняющих, почему (микро) бенчмаркинг особенно сложен в Java:

• Динамическая компиляция и измерение производительности
• Анатомия некорректный микробенчмарк
• Сборка мусора и производительность

Я не думаю, что микробенчмаркинг стоит того. Я думаю, что эффективный бенчмаркинг стоит потраченного времени.

Вообще говоря, микробенчмаркинг (как говорится в in silico) пытается измерить производительность некоторой очень детализированной задачи, которую сложно выполнить хорошо и обычно бессмысленно в контексте реальных проблем с производительностью.