Jmh указывает, что M1 быстрее, чем M2, но M1 делегирует M2

Ответ 1

В этом конкретном случае assertMethod действительно скомпилирован лучше, чем requireMethod из-за проблем с распределением регистров.

Тест выглядит правильно, и я могу последовательно воспроизводить ваши результаты.
Чтобы проанализировать проблему, я сделал упрощенный тест:

package bench;

import com.google.common.collect.ImmutableMap;
import org.openjdk.jmh.annotations.*;

@State(Scope.Benchmark)
public class Requirements {
    private static boolean enabled = true;

    private String name = "name";
    private String value = "value";

    @Benchmark
    public Object assertMethod() {
        if (enabled)
            return requireThat(value, name);
        return null;
    }

    @Benchmark
    public Object requireMethod() {
        return requireThat(value, name);
    }

    public static Object requireThat(String parameter, String name) {
        if (name.trim().isEmpty())
            throw new IllegalArgumentException();
        return new StringRequirementsImpl(parameter, name, new Configuration());
    }

    static class Configuration {
        private Object context = ImmutableMap.of();
    }

    static class StringRequirementsImpl {
        private String parameter;
        private String name;
        private Configuration config;
        private ObjectRequirementsImpl asObject;

        StringRequirementsImpl(String parameter, String name, Configuration config) {
            this.parameter = parameter;
            this.name = name;
            this.config = config;
            this.asObject = new ObjectRequirementsImpl(parameter, name, config);
        }
    }

    static class ObjectRequirementsImpl {
        private Object parameter;
        private String name;
        private Configuration config;

        ObjectRequirementsImpl(Object parameter, String name, Configuration config) {
            this.parameter = parameter;
            this.name = name;
            this.config = config;
        }
    }
}

Прежде всего, я проверил -XX:+PrintInlining, что весь эталон встроен в один большой метод. Очевидно, что в этом компиляционном блоке много узлов, и для хранения всех промежуточных переменных недостаточно регистров процессора. То есть, компилятор должен spill некоторые из них.

• В assertMethod 4 регистра просочились в стек перед вызовом trim().
• В requireMethod 7 регистров просыпаются позже, после вызова new Configuration().

-XX:+PrintAssembly вывод:

  assertMethod             |  requireMethod
  -------------------------|------------------------
  mov    %r11d,0x5c(%rsp)  |  mov    %rcx,0x20(%rsp)
  mov    %r10d,0x58(%rsp)  |  mov    %r11,0x48(%rsp)
  mov    %rbp,0x50(%rsp)   |  mov    %r10,0x30(%rsp)
  mov    %rbx,0x48(%rsp)   |  mov    %rbp,0x50(%rsp)
                           |  mov    %r9d,0x58(%rsp)
                           |  mov    %edi,0x5c(%rsp)
                           |  mov    %r8,0x60(%rsp) 

Это почти единственное различие между двумя скомпилированными методами в дополнение к проверке if (enabled). Таким образом, разница в производительности объясняется большим количеством переменных, разлитых в память.

Почему меньший метод скомпилирован менее оптимальным? Хорошо, проблема распределения регистров, как известно, является NP-полной. Поскольку он не может быть решен идеально в разумные сроки, компиляторы обычно полагаются на определенные эвристики. В большом методе крошечная вещь, такая как дополнительный if, может значительно изменить результат алгоритма распределения регистров.

Однако вам не нужно об этом беспокоиться. Эффект, который мы видели, не означает, что requireMethod всегда скомпилирован хуже. В других случаях использование графа компиляции будет совершенно иным, поскольку вложение. Во всяком случае, разница в 1 наносекунде не является ничем для реальной производительности приложения.

Ответ 2

Вы запускаете свой тест в рамках одного процесса VM, задавая forks(1). Во время выполнения виртуальная машина просматривает ваш код и пытается выяснить, как он действительно выполняется. Затем он создает так называемые профили для оптимизации вашего приложения в соответствии с этим наблюдаемым поведением.

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

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

Вы также должны проверить образец в состоянии; вы не должны ссылаться на свой ввод как константы, но пусть JMH обрабатывает значение escape, чтобы применить фактическое вычисление.

Я предполагаю, что - если применить их правильно - оба теста будут иметь сходное время выполнения.

Обновить. Вот что я получаю для фиксированного теста:

Benchmark                  Mode  Cnt   Score   Error  Units
MyBenchmark.assertMethod   avgt   40  17,592 ± 1,493  ns/op
MyBenchmark.requireMethod  avgt   40  17,999 ± 0,920  ns/op

Ради завершения, я также провел тест с перфекционизмом, и оба метода в основном скомпилированы в одно и то же.

Ответ 3

Отвечая на мой собственный вопрос:

Кажется, что наложение искажает результаты. Все, что мне нужно было сделать, чтобы получить последовательные, значимые результаты, было следующее:

• Блокировка часов процессора (минимальный/максимальный CPU установлен на 99% в Windows Power Options)
• Отключить inlining, аннотируя оба метода с помощью @CompilerControl(CompilerControl.Mode.DONT_INLINE).

Теперь я получаю следующие результаты:

Benchmark                  Mode  Cnt   Score   Error  Units
MyBenchmark.assertMethod   avgt  200  11.462 ± 0.048  ns/op
MyBenchmark.requireMethod  avgt  200  11.138 ± 0.062  ns/op

Я попытался проанализировать вывод -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining, но не смог найти ничего плохого. Оба метода, похоже, встраиваются одинаково. < & развести руками GT;

Исходный код исходного кода:

import java.util.concurrent.TimeUnit;
import static org.bitbucket.cowwoc.requirements.Requirements.assertThat;
import static org.bitbucket.cowwoc.requirements.Requirements.requireThat;
import org.bitbucket.cowwoc.requirements.StringRequirements;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.CompilerControl;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

@State(Scope.Benchmark)
public class MyBenchmark {

    private String name = "name";
    private String value = "value";

    @Benchmark
    public void emptyMethod() {
    }

    // Inlining leads to unexpected results: https://stackoverflow.com/a/38860869/14731
    @Benchmark
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public StringRequirements assertMethod() {
        return assertThat(value, name).isNotNull().isNotEmpty();
    }

    @Benchmark
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public StringRequirements requireMethod() {
        return requireThat(value, name).isNotNull().isNotEmpty();
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(MyBenchmark.class.getSimpleName())
                .jvmArgsAppend("-ea")
                .forks(3)
                .timeUnit(TimeUnit.NANOSECONDS)
                .mode(Mode.AverageTime)
                .build();

        new Runner(opt).run();
    }
}

UPDATE: apangin, кажется, понял, почему assertMethod() быстрее, чем requireMethod().

Ответ 4

Это очень часто встречается в микрообъектах. Когда я загружаю свой код, я получаю тот же результат, но с другими цифрами, по-видимому, мой компьютер медленнее вашего. Однако, если я изменю ваш источник, чтобы использовать 5 вилок, 100 итераций прогрева и 20 итераций измерений, то requireMethod будет немного быстрее, чем assertMethod, как ожидалось.

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