Why is 2 * (i * i) faster than 2 * i * i in Java?

<i>So it&#x27;s an issue of the optimizer; as is often the case, it unrolls too aggressively and shoots itself in the foot, all the while missing out on various other opportunities.</i><p>In my experience, loop unrolling should basically never be done except in extremely degenerate cases; I remember not long ago someone I know who also optimises Asm remarking &quot;it should&#x27;ve died along with the RISC fad&quot;. The original goal was to reduce per-iteration overhead associated with checking for end-of-loop, but any superscalar&#x2F;OoO&#x2F;speculative processor can &quot;execute past&quot; those instructions anyway; all that unrolling will do is bloat the code and work against caching. Memory bandwidth is often the bottleneck, not the core.

You should translate your program to C++ and build with clang ; it turns the loop into a single constant load. <a href="https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;slznbU" rel="nofollow">https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;slznbU</a>

With all the optimisations being implemented in compilers today, it is impressive to see how this opportunity to optimise is missed. Put differently, compiler writers bother about optimisations that gain 0.1% performance in some special cases, but others that could gain 20% performance are not implemented.<p>Why? Is this optimisation particularly difficult to implement? Or is it just missed low-hanging fruit? It sure looks easy (like: rearrange expressions to keep the expression tree shallow and left-branching to avoid stack operations).

That just might be the most dedicated answer I&#x27;ve ever seen on Stack Overflow.

I thought at first this was because integer squaring is potentially faster than general integer multiplication and the compiler wasn&#x27;t seeing the square operation in the second case, but that&#x27;s not the explanation here.

I&#x27;m surprised it&#x27;s not doing a left shift for the x2.

The graal behavior is a lot more sane:<p><pre><code> graal: [info] SoFlow.square_i_two 10000 avgt 10 5338.492 ± 36.624 ns&#x2F;op &#x2F;&#x2F; 2 *\sum i * i [info] SoFlow.two_i_ 10000 avgt 10 6421.343 ± 34.836 ns&#x2F;op &#x2F;&#x2F; \sum 2 * i * i [info] SoFlow.two_square_i 10000 avgt 10 6367.139 ± 34.575 ns&#x2F;op &#x2F;&#x2F; \sum 2 * (i * i) regular 1.8: [info] SoFlow.square_i_two 10000 avgt 10 6393.422 ± 27.679 ns&#x2F;op [info] SoFlow.two_i_ 10000 avgt 10 8870.908 ± 35.715 ns&#x2F;op [info] SoFlow.two_square_i 10000 avgt 10 6221.205 ± 42.408 ns&#x2F;op </code></pre> The graal-generated assembly for the first two cases is nearly identical, featuring unrolled repetitions of sequences like<p><pre><code> [info] 0x000000011433ec03: mov %r8d,%ecx [info] 0x000000011433ec06: shl %ecx ;*imul {reexecute=0 rethrow=0 return_oop=0} [info] ; - add.SoFlow::test_two_i_@15 (line 41) [info] 0x000000011433ec08: imul %r8d,%ecx ;*imul {reexecute=0 rethrow=0 return_oop=0} [info] ; - add.SoFlow::test_two_i_@17 (line 41) [info] 0x000000011433ec0c: add %ecx,%r9d ;*iadd {reexecute=0 rethrow=0 return_oop=0} [info] ; - add.SoFlow::test_two_i_@18 (line 41) [info] 0x000000011433ec0f: lea 0x5(%r11),%r8d ;*iinc {reexecute=0 rethrow=0 return_oop=0} [info] ; - add.SoFlow::test_two_i_@20 (line 40) </code></pre> while the third case does a single shl at the end.<p><pre><code> [info] 0x000000010e2918bb: imul %r8d,%r8d ;*imul {reexecute=0 rethrow=0 return_oop=0} [info] ; - add.SoFlow::test_square_i_two@15 (line 32) [info] 0x000000010e2918bf: add %r8d,%ecx ;*iadd {reexecute=0 rethrow=0 return_oop=0} [info] ; - add.SoFlow::test_square_i_two@16 (line 32) [info] 0x000000010e2918c2: lea 0x3(%r11),%r8d ;*iinc {reexecute=0 rethrow=0 return_oop=0} [info] ; - add.SoFlow::test_square_i_two@18 (line 31) </code></pre> Both graal and C2 inline, but as usual the graal output is a lot more comprehensible.

I don&#x27;t see how generating different code for the same mathematical expression can be a good thing.<p>The compiler should detect that the two expressions are strictly equivalent and generate whatever code it believes is the fastest.<p>Any idea why it is this way?

TIL about printing ASM from debug JVMs.

Is Overflow UB so the compiler can choose to ignore the fact that 2x(i x i) could overflow differently from 2 x i x i?<p>I’m not sure it does overflow differently but I would expect overflow to behave consistently as written, and not be dependent on optimization, is that not the case?

At first, I thought it was because i * i == -1.

I guess they do not use value numbering, which is typically how you get equivalent results for cases like this.

IMHO some kind of logic preprocesor should take care of this before the actual compilation.

I wonder if the same applies to .net (fx&#x2F;core).

Has anyone tried this with Go?

The database is fast enough for a few extra trips to it, so this is definitely what we should be focusing on.<p>(My cup of bitterness doth overflow.)