Por que 2 * (i * i) é mais rápido que 2 * i * i em Java?

Quando a multiplicação é 2 * (i * i), a JVM é capaz de fatorar a multiplicação por 2 do loop, resultando nesse código equivalente, porém mais eficiente:

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

mas quando a multiplicação é (2 * i) * i, a JVM não a otimiza, pois a multiplicação por uma constante não está mais logo antes da adição.

Aqui estão algumas razões pelas quais eu penso que este é o caso:

• Adicionando uma instrução if (n == 0) n = 1 no início do loop resulta em ambas as versões sendo tão eficientes, já que fatorar a multiplicação não garante mais que o resultado seja o mesmo.
• A versão otimizada (fatorando a multiplicação por 2) é exatamente tão rápida quanto a versão 2 * (i * i)

Aqui está o código de teste que usei para tirar essas conclusões:

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;
}

E aqui estão os resultados:

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

Códigos de bytes: https://cs.nyu.edu/courses/fall00/V22.0201-001/jvm2.html Byte codes Visualizador: https://github.com/Konloch/bytecode-viewer

No meu JDK (Windows 10 64 bits, 1.8.0_65-b17) posso reproduzir e explicar:

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;
}

Saída:

...
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

Então por que? O código de byte é este:

 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 {
     }
 }

A diferença é: com parênteses (2 * (i * i)):

• Empilhar pilha const
• Empurre local na pilha
• Empurre local na pilha
• multiplique o topo da pilha
• multiplique o topo da pilha

Sem colchetes (2 * i * i):

• Empilhar pilha const
• Empurre local na pilha
• multiplique o topo da pilha
• Empurre local na pilha
• multiplique o topo da pilha

Carregar tudo na pilha e depois voltar a trabalhar é mais rápido do que trocar entre colocar na pilha e operar nela.

Kasperd perguntou em um comentário da resposta aceita:

Os exemplos Java e C usam nomes de registro bastante diferentes. Ambos os exemplos estão usando o 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

Eu não tenho reputação suficiente para responder isso nos comentários, mas estes são os mesmos ISA. Vale a pena ressaltar que a versão do GCC usa lógica de inteiros de 32 bits e a versão compilada da JVM usa lógica inteira de 64 bits internamente.

R8 a R15 são apenas novos registros X86_64 . EAX para EDX são as partes inferiores dos registradores de propósito geral RAX para RDX. A parte importante na resposta é que a versão do GCC não é desenrolada. Ele simplesmente executa uma rodada do loop por loop de código de máquina real. Enquanto a versão da JVM tem 16 rodadas do loop em um loop físico (com base na resposta rustyx, eu não reinterpreti o Assembly). Essa é uma das razões pelas quais há mais registros sendo usados, já que o corpo do loop é 16 vezes mais longo.

Embora não esteja diretamente relacionado ao ambiente da questão, apenas pela curiosidade, fiz o mesmo teste no .NET Core 2.1, x64, no modo de liberação.

Aqui está o resultado interessante, confirmando que fenômenos similares (outros caminhos) acontecem sobre o lado negro da força. Código:

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");
    }
}

Resultado:

2 * (i * i)

• resultado: 119860736, 438 ms
• resultado: 119860736, 433 ms
• resultado: 119860736, 437 ms
• resultado: 119860736, 435 ms
• resultado: 119860736, 436 ms
• resultado: 119860736, 435 ms
• resultado: 119860736, 435 ms
• resultado: 119860736, 439 ms
• resultado: 119860736, 436 ms
• resultado: 119860736, 437 ms

2 * i * i

• resultado: 119860736, 417 ms
• resultado: 119860736, 417 ms
• resultado: 119860736, 417 ms
• resultado: 119860736, 418 ms
• resultado: 119860736, 418 ms
• resultado: 119860736, 417 ms
• resultado: 119860736, 418 ms
• resultado: 119860736, 416 ms
• resultado: 119860736, 417 ms
• resultado: 119860736, 418 ms

Eu tenho resultados semelhantes:

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

Eu obtive os resultadosSAMEse ambos os loops estavam no mesmo programa, ou cada um estava em um arquivo .Java separado/.class, executado em uma execução separada.

Finalmente, aqui está um javap -c -v <.Java> decompile de cada:

     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

vs.

     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

PARA SUA INFORMAÇÃO -

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)

Eu tentei um JMH usando o arquétipo padrão: eu também adicionei uma versão otimizada com base em explicação do 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;
  }
}

O resultado está aqui:

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

No meu PC ( Core i7 860 - não está fazendo nada além de ler no meu smartphone):

• n += i*i então n*2 é o primeiro
• 2 * (i * i) é o segundo.

A JVM claramente não está otimizando da mesma forma que um humano (com base na resposta de Runemoro).

Agora, então, lendo bytecode: javap -c -v ./target/classes/org/sample/MyBenchmark.class

• Diferenças entre 2 * (i * i) (esquerda) e 2 * i * i (direita) aqui: https://www.diffchecker.com/cvSFppWI
• Diferenças entre 2 * (i * i) e a versão otimizada aqui: https://www.diffchecker.com/I1XFu5dP

Eu não sou especialista em bytecode, mas nós iload_2 antes de imul: é provavelmente onde você obtém a diferença: Eu suponho que a JVM otimize a leitura i duas vezes (i já está aqui, e não há necessidade de carregá-la novamente) enquanto estiver em o 2*i*i não pode.

Mais de um adendo. Eu reproduzi o experimento usando a última JVM Java 8 da 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)

E isso mostra resultados muito semelhantes:

0.374653912 s
n = 119860736
0.447778698 s
n = 119860736

(segundos resultados usando 2 * i * i).

Curiosamente, quando executado na mesma máquina, mas usando o 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)

os resultados são um pouco mais lentos:

0.414331815 s
n = 119860736
0.491430656 s
n = 119860736

Resumindo: até mesmo o menor número de versão do HotSpot importa, pois diferenças sutis na implementação do JIT podem ter efeitos notáveis.

Observação interessante usando Java 11 e desativando o desenrolar do loop com a seguinte opção VM:

-XX:LoopUnrollLimit=0

O loop com a expressão 2 * (i * i) resulta em código nativo mais compacto¹:

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

em comparação com a versão 2 * i * i:

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

Versão de 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)

Resultados de referência:

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

Código fonte do benchmark:

@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 opções usadas: -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:LoopUnrollLimit=0}

Os dois métodos de adição geram código de byte ligeiramente diferente:

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

Para 2 * (i * i) vs:

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

Para 2 * i * i.

E quando usando um JMH benchmark como este:

@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;
    }

}

A diferença é clara:

# 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

O que você observa está correto, e não apenas uma anomalia do seu estilo de benchmarking (ou seja, sem aquecimento, veja Como eu escrevo uma micro-referência correta em Java? )

Correndo novamente com o Graal:

# 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

Você vê que os resultados estão muito mais próximos, o que faz sentido, já que o Graal é um compilador de desempenho geral e mais moderno.

Então, isso é apenas o quão bem o compilador JIT é capaz de otimizar uma parte específica do código, e não necessariamente tem uma razão lógica para isso.