Почему 2 * (i * i) быстрее, чем 2 * i * i в Java?

Когда умножение равно 2 * (i * i), JVM может разложить умножение на 2 из цикла, в результате чего этот эквивалентный, но более эффективный код:

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

но когда умножение (2 * i) * i, JVM не оптимизирует его, так как умножение на константу уже не является правильным перед добавлением.

Вот несколько причин, почему я так думаю:

• Добавление инструкции if (n == 0) n = 1 в начале цикла приводит к тому, что обе версии являются эффективными, поскольку размножение умножения больше не гарантирует, что результат будет таким же
• Оптимизированная версия (путем умножения умножения на 2) выполняется точно так же, как версия 2 * (i * i)

Вот тестовый код, который я использовал для вывода этих выводов:

public static void main(String[] args) {
    long fastVersion = 0;
    long slowVersion = 0;
    long optimizedVersion = 0;
    long modifiedFastVersion = 0;
    long modifiedSlowVersion = 0;

    for (int i = 0; i < 10; i++) {
        fastVersion += fastVersion();
        slowVersion += slowVersion();
        optimizedVersion += optimizedVersion();
        modifiedFastVersion += modifiedFastVersion();
        modifiedSlowVersion += modifiedSlowVersion();
    }

    System.out.println("Fast version: " + (double) fastVersion / 1000000000 + " s");
    System.out.println("Slow version: " + (double) slowVersion / 1000000000 + " s");
    System.out.println("Optimized version: " + (double) optimizedVersion / 1000000000 + " s");
    System.out.println("Modified fast version: " + (double) modifiedFastVersion / 1000000000 + " s");
    System.out.println("Modified slow version: " + (double) modifiedSlowVersion / 1000000000 + " s");
}

private static long fastVersion() {
    long startTime = System.nanoTime();
    int n = 0;
    for (int i = 0; i < 1000000000; i++) {
        n += 2 * (i * i);
    }
    return System.nanoTime() - startTime;
}

private static long slowVersion() {
    long startTime = System.nanoTime();
    int n = 0;
    for (int i = 0; i < 1000000000; i++) {
        n += 2 * i * i;
    }
    return System.nanoTime() - startTime;
}

private static long optimizedVersion() {
    long startTime = System.nanoTime();
    int n = 0;
    for (int i = 0; i < 1000000000; i++) {
        n += i * i;
    }
    n *= 2;
    return System.nanoTime() - startTime;
}

private static long modifiedFastVersion() {
    long startTime = System.nanoTime();
    int n = 0;
    for (int i = 0; i < 1000000000; i++) {
        if (n == 0) n = 1;
        n += 2 * (i * i);
    }
    return System.nanoTime() - startTime;
}

private static long modifiedSlowVersion() {
    long startTime = System.nanoTime();
    int n = 0;
    for (int i = 0; i < 1000000000; i++) {
        if (n == 0) n = 1;
        n += 2 * i * i;
    }
    return System.nanoTime() - startTime;
}

И вот результаты:

Fast version: 5.7274411 s
Slow version: 7.6190804 s
Optimized version: 5.1348007 s
Modified fast version: 7.1492705 s
Modified slow version: 7.2952668 s

ByteCodes: https://cs.nyu.edu/courses/fall00/V22.0201-001/jvm2.html
ByteCodes Viewer: https://github.com/Konloch/bytecode-viewer

На моем JDK (Win10 64 1.8.0_65-b17) я могу воспроизвести и объяснить:

public static void main(String[] args) {
    int repeat = 10;
    long A = 0;
    long B = 0;
    for (int i = 0; i < repeat; i++) {
        A += test();
        B += testB();
    }

    System.out.println(A / repeat + " ms");
    System.out.println(B / repeat + " ms");
}


private static long test() {
    int n = 0;
    for (int i = 0; i < 1000; i++) {
        n += multi(i);
    }
    long startTime = System.currentTimeMillis();
    for (int i = 0; i < 1000000000; i++) {
        n += multi(i);
    }
    long ms = (System.currentTimeMillis() - startTime);
    System.out.println(ms + " ms A " + n);
    return ms;
}


private static long testB() {
    int n = 0;
    for (int i = 0; i < 1000; i++) {
        n += multiB(i);
    }
    long startTime = System.currentTimeMillis();
    for (int i = 0; i < 1000000000; i++) {
        n += multiB(i);
    }
    long ms = (System.currentTimeMillis() - startTime);
    System.out.println(ms + " ms B " + n);
    return ms;
}

private static int multiB(int i) {
    return 2 * (i * i);
}

private static int multi(int i) {
    return 2 * i * i;
}

Выход:

...
405 ms A 785527736
327 ms B 785527736
404 ms A 785527736
329 ms B 785527736
404 ms A 785527736
328 ms B 785527736
404 ms A 785527736
328 ms B 785527736
410 ms
333 ms

Так почему? Байт-код:

 private static multiB(int arg0) { // 2 * (i * i)
     <localVar:index=0 , name=i , desc=I, sig=null, start=L1, end=L2>

     L1 {
         iconst_2
         iload0
         iload0
         imul
         imul
         ireturn
     }
     L2 {
     }
 }

 private static multi(int arg0) { // 2 * i * i
     <localVar:index=0 , name=i , desc=I, sig=null, start=L1, end=L2>

     L1 {
         iconst_2
         iload0
         imul
         iload0
         imul
         ireturn
     }
     L2 {
     }
 }

Разница заключается в следующем:
С кронштейнами (2 * (i * i)):

• push const stack
• нажимать локально на стек
• нажимать локально на стек
• умножать вершину стека
• умножать вершину стека

Без скобок (2 * я * i):

• push const stack
• нажимать локально на стек
• умножать вершину стека
• нажимать локально на стек
• умножать вершину стека

Загрузка всех в стек и последующая работа обратно вниз быстрее, чем переключение между наложением стека и работой с ним.

Касперд спросил в комментарии к принятому ответу:

Примеры Java и C используют совершенно разные имена регистров. Оба примера используют AMD64 ISA?

xor edx, edx
xor eax, eax
.L2:
mov ecx, edx
imul ecx, edx
add edx, 1
lea eax, [rax+rcx*2]
cmp edx, 1000000000
jne .L2

У меня недостаточно репутации, чтобы ответить на это в комментариях, но это те же самые ISA. Стоит отметить, что версия GCC использует 32-битную целочисленную логику, а скомпилированная версия JVM использует внутреннюю логику 64-битного целого.

R8-R15 являются только новыми x86_64 регистров. EAX to EDX - это нижние части регистров общего назначения RAX для RDX. Важная часть ответа заключается в том, что версия GCC не разворачивается. Он просто выполняет один цикл цикла для каждого цикла машинного кода. Хотя версия JVM имеет 16 циклов цикла в одном физическом цикле (на основе ответа rustyx я не переосмыслил сборку). Это одна из причин, по которой используется больше регистров, поскольку тело цикла на самом деле в 16 раз больше.

Хотя я не имел прямого отношения к среде вопросов, просто для любопытства, я сделал тот же тест на.Net Core 2.1, x64, режим выпуска. Вот интересный результат, подтверждающий аналогичную фонетию (по-другому) вокруг темной стороны силы. Код:

static void Main(string[] args)
    {
        Stopwatch watch = new Stopwatch();

        Console.WriteLine("2 * (i * i)");

        for (int a = 0; a < 10; a++)
        {
            int n = 0;

            watch.Restart();

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

            watch.Stop();

            Console.WriteLine($"result:{n}, {watch.ElapsedMilliseconds}ms");
        }

        Console.WriteLine();
        Console.WriteLine("2 * i * i");

        for (int a = 0; a < 10; a++)
        {
            int n = 0;

            watch.Restart();

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

            watch.Stop();

            Console.WriteLine($"result:{n}, {watch.ElapsedMilliseconds}ms");
        }
    }

Результат:

2 * (i * i)

• результат: 119860736, 438мс
• результат: 119860736, 433ms
• результат: 119860736, 437мс
• результат: 119860736, 435мс
• результат: 119860736, 436ms
• результат: 119860736, 435мс
• результат: 119860736, 435мс
• результат: 119860736, 439ms
• результат: 119860736, 436ms
• результат: 119860736, 437мс

2 * я * i

• результат: 119860736, 417мс
• результат: 119860736, 417мс
• результат: 119860736, 417мс
• результат: 119860736, 418мс
• результат: 119860736, 418мс
• результат: 119860736, 417мс
• результат: 119860736, 418мс
• результат: 119860736, 416ms
• результат: 119860736, 417мс
• результат: 119860736, 418мс

Я получил аналогичные результаты:

2 * (i * i): 0.458765943 s, n=119860736
2 * i * i: 0.580255126 s, n=119860736

Я получил ИГРЫ, если обе циклы были в одной программе, или каждый из них был в отдельном файле.java/.class, выполненном в отдельном прогоне.

Наконец, вот javap -c -v <.java>:

     3: ldc           #3                  // String 2 * (i * i):
     5: invokevirtual #4                  // Method java/io/PrintStream.print:(Ljava/lang/String;)V
     8: invokestatic  #5                  // Method java/lang/System.nanoTime:()J
     8: invokestatic  #5                  // Method java/lang/System.nanoTime:()J
    11: lstore_1
    12: iconst_0
    13: istore_3
    14: iconst_0
    15: istore        4
    17: iload         4
    19: ldc           #6                  // int 1000000000
    21: if_icmpge     40
    24: iload_3
    25: iconst_2
    26: iload         4
    28: iload         4
    30: imul
    31: imul
    32: iadd
    33: istore_3
    34: iinc          4, 1
    37: goto          17

против

     3: ldc           #3                  // String 2 * i * i:
     5: invokevirtual #4                  // Method java/io/PrintStream.print:(Ljava/lang/String;)V
     8: invokestatic  #5                  // Method java/lang/System.nanoTime:()J
    11: lstore_1
    12: iconst_0
    13: istore_3
    14: iconst_0
    15: istore        4
    17: iload         4
    19: ldc           #6                  // int 1000000000
    21: if_icmpge     40
    24: iload_3
    25: iconst_2
    26: iload         4
    28: imul
    29: iload         4
    31: imul
    32: iadd
    33: istore_3
    34: iinc          4, 1
    37: goto          17

FYI -

java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Я попробовал JMH с использованием архетипа по умолчанию: я также добавил объяснение оптимизированной версии Runemoro.

@State(Scope.Benchmark)
@Warmup(iterations = 2)
@Fork(1)
@Measurement(iterations = 10)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
//@BenchmarkMode({ Mode.All })
@BenchmarkMode(Mode.AverageTime)
public class MyBenchmark {
  @Param({ "100", "1000", "1000000000" })
  private int size;

  @Benchmark
  public int two_square_i() {
    int n = 0;
    for (int i = 0; i < size; i++) {
      n += 2 * (i * i);
    }
    return n;
  }

  @Benchmark
  public int square_i_two() {
    int n = 0;
    for (int i = 0; i < size; i++) {
      n += i * i;
    }
    return 2*n;
  }  

  @Benchmark
  public int two_i_() {
    int n = 0;
    for (int i = 0; i < size; i++) {
      n += 2 * i * i;
    }
    return n;
  }
}

Результат здесь:

Benchmark                           (size)  Mode  Samples          Score   Score error  Units
o.s.MyBenchmark.square_i_two           100  avgt       10         58,062         1,410  ns/op
o.s.MyBenchmark.square_i_two          1000  avgt       10        547,393        12,851  ns/op
o.s.MyBenchmark.square_i_two    1000000000  avgt       10  540343681,267  16795210,324  ns/op
o.s.MyBenchmark.two_i_                 100  avgt       10         87,491         2,004  ns/op
o.s.MyBenchmark.two_i_                1000  avgt       10       1015,388        30,313  ns/op
o.s.MyBenchmark.two_i_          1000000000  avgt       10  967100076,600  24929570,556  ns/op
o.s.MyBenchmark.two_square_i           100  avgt       10         70,715         2,107  ns/op
o.s.MyBenchmark.two_square_i          1000  avgt       10        686,977        24,613  ns/op
o.s.MyBenchmark.two_square_i    1000000000  avgt       10  652736811,450  27015580,488  ns/op

На моем ПК (Core i7 860, ничего не делая, кроме чтения на моем смартфоне):

• n += i*i то сначала n*2
• 2 * (i * i) является вторым.

JVM явно не оптимизирует то же самое, что делает человек (на основе ответа Руньеро).

Теперь прочитайте байт-код: javap -c -v./target/classes/org/sample/MyBenchmark.class

• Различия между 2 * (i * i) (слева) и 2 * я * я (справа): https://www.diffchecker.com/cvSFppWI
• Различия между 2 * (i * i) и оптимизированной версией здесь: https://www.diffchecker.com/I1XFu5dP

Я не эксперт по байт-коду, но мы iload_2 прежде чем мы imul: возможно, где вы получите разницу: я могу предположить, что JVM оптимизирует чтение i дважды (i уже здесь, нет необходимости загружать его снова), в то время как в 2*i*i это не может.

Интересное наблюдение с использованием Java 11 и отключение цикла с помощью следующей опции VM:

-XX:LoopUnrollLimit=0

Цикл с выражением 2 * (i * i) дает более компактный собственный код ¹:

L0001: add    eax,r11d
       inc    r8d
       mov    r11d,r8d
       imul   r11d,r8d
       shl    r11d,1h
       cmp    r8d,r10d
       jl     L0001

по сравнению с версией 2 * я * i:

L0001: add    eax,r11d
       mov    r11d,r8d
       shl    r11d,1h
       add    r11d,2h
       inc    r8d
       imul   r11d,r8d
       cmp    r8d,r10d
       jl     L0001

Версия Java:

java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)

Результаты тестов:

Benchmark          (size)  Mode  Cnt    Score     Error  Units
LoopTest.fast  1000000000  avgt    5  694,868 ±  36,470  ms/op
LoopTest.slow  1000000000  avgt    5  769,840 ± 135,006  ms/op

Исходный код:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS)
@State(Scope.Thread)
@Fork(1)
public class LoopTest {

    @Param("1000000000") private int size;

    public static void main(String[] args) throws RunnerException {
        Options opt =
            new OptionsBuilder().include(LoopTest.class.getSimpleName())
                                .jvmArgs("-XX:LoopUnrollLimit=0")
                                .build();
        new Runner(opt).run();
    }

    @Benchmark
    public int slow() {
        int n = 0;
        for (int i = 0; i < size; i++) {
            n += 2 * i * i;
        }
        return n;
    }

    @Benchmark
    public int fast() {
        int n = 0;
        for (int i = 0; i < size; i++) {
            n += 2 * (i * i);
        }
        return n;
    }
}

^{1 - используемые опции VM: -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:LoopUnrollLimit=0}

Больше добавлений. Я воспроизвел эксперимент, используя новейшую Java 8 JVM от IBM:

java version "1.8.0_191"
Java(TM) 2 Runtime Environment, Standard Edition (IBM build 1.8.0_191-b12 26_Oct_2018_18_45 Mac OS X x64(SR5 FP25))
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

и это показывает очень похожие результаты:

0.374653912 s
n = 119860736
0.447778698 s
n = 119860736

(второй результат с использованием 2 * я * i).

Интересно, что при работе на одной машине, но с использованием Oracle java:

Java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

результаты в среднем немного медленнее:

0.414331815 s
n = 119860736
0.491430656 s
n = 119860736

Короче говоря: даже незначительное количество версий HotSpot здесь, поскольку тонкие различия в реализации JIT могут иметь заметные эффекты.

Два метода добавления генерируют немного другой байт-код:

  17: iconst_2
  18: iload         4
  20: iload         4
  22: imul
  23: imul
  24: iadd

Для 2 * (i * i) против:

  17: iconst_2
  18: iload         4
  20: imul
  21: iload         4
  23: imul
  24: iadd

Для 2 * я * i.

И при использовании теста JMH, как это:

@Warmup(iterations = 5, batchSize = 1)
@Measurement(iterations = 5, batchSize = 1)
@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
public class MyBenchmark {

    @Benchmark
    public int noBrackets() {
        int n = 0;
        for (int i = 0; i < 1000000000; i++) {
            n += 2 * i * i;
        }
        return n;
    }

    @Benchmark
    public int brackets() {
        int n = 0;
        for (int i = 0; i < 1000000000; i++) {
            n += 2 * (i * i);
        }
        return n;
    }

}

Разница очевидна:

# JMH version: 1.21
# VM version: JDK 11, Java HotSpot(TM) 64-Bit Server VM, 11+28
# VM options: <none>

Benchmark                      (n)  Mode  Cnt    Score    Error  Units
MyBenchmark.brackets    1000000000  avgt    5  380.889 ± 58.011  ms/op
MyBenchmark.noBrackets  1000000000  avgt    5  512.464 ± 11.098  ms/op

То, что вы наблюдаете, является правильным, а не просто аномалией вашего стиля бенчмаркинга (т.е. Без разминки, см. Как написать правильный микро-бенчмарк в Java?)

Бегом снова с Граалем:

# JMH version: 1.21
# VM version: JDK 11, Java HotSpot(TM) 64-Bit Server VM, 11+28
# VM options: -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler

Benchmark                      (n)  Mode  Cnt    Score    Error  Units
MyBenchmark.brackets    1000000000  avgt    5  335.100 ± 23.085  ms/op
MyBenchmark.noBrackets  1000000000  avgt    5  331.163 ± 50.670  ms/op

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

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

Помните, что JIT имеет тенденцию очень интенсивно разворачивать маленькие циклы.

Это быстрее, потому что JIT генерирует более оптимальный ассемблерный код для первого случая.

Если взять только два члена суммирования, то можно видеть, что -

в прежнем случае справедлив простой математический факт:

(3 multiplications)

но из-за правил приоритета оператора мы получаем в последнем случае:

(4 multiplications)