Performance Optimization Analysis: Why 2*(i*i) is Faster Than 2*i*i in Java

Performance Difference Phenomenon Analysis

In Java programming, the expressions 2 * (i * i) and 2 * i * i are mathematically equivalent but exhibit significant differences in actual execution performance. Through rigorous benchmarking, the former averages 0.50-0.55 seconds while the latter requires 0.60-0.65 seconds, representing a performance gap of approximately 20%. This difference stems from variations in the underlying optimization mechanisms of the Java Virtual Machine.

Bytecode Level Differences

From a bytecode perspective, the two expressions generate instruction sequences with subtle but critical differences:

// Bytecode for 2 * (i * i)
iconst_2
iload0
iload0
imul
imul
iadd

// Bytecode for 2 * i * i
iconst_2
iload0
imul
iload0
imul
iadd

Superficially, the 2 * i * i version uses one less stack slot and should theoretically be more efficient. However, this difference is amplified during the JIT compiler optimization phase, resulting in dramatically different final performance.

JIT Compiler Optimization Mechanisms

The Java HotSpot VM's Just-In-Time compiler performs deep optimization of loop code. For the 2 * (i * i) expression, JIT employs a 16x loop unrolling strategy:

// Simplified assembly code example
movl R11, R13
imull R11, R13
sall R11, #1
addl R13, #16
cmpl R13, #999999985
jl loop_label

This optimization combines 16 iterations into one, reducing loop control overhead. More importantly, this version has only one register that needs spilling to the stack, with most computations completed within registers.

In contrast, the 2 * i * i version, while also employing loop unrolling, generates more intermediate results that require preservation:

// Examples of extensive stack access operations
movl [rsp + #32], RBX
movl [rsp + #36], R11
movl [rsp + #40], R10
addl R9, [RSP + #32 (32-bit)]
addl R9, [RSP + #60 (32-bit)]

This version exhibits numerous stack memory access operations, and these additional memory accesses create significant performance overhead in tight loops.

Modern CPU Architecture Impact

Modern x86-64 CPUs employ complex microarchitecture designs, including micro-op caches, register renaming, and loop buffers. According to Agner Fog's optimization guide, excessive loop unrolling can be counterproductive:

The gain in performance due to the µop cache can be quite considerable if the average instruction length is more than 4 bytes. The following methods of optimizing the use of the µop cache may be considered: Make sure that critical loops are small enough to fit into the µop cache, align the most critical loop entries and function entries by 32, avoid unnecessary loop unrolling, avoid instructions that have extra load time.

Even L1 cache hits require 4 clock cycles, and additional registers and micro-ops can harm performance in tight loops. The extensive stack access operations in the 2 * i * i version precisely trigger these performance bottlenecks.

Vectorization Optimization Potential

The current Java JIT compiler fails to fully utilize modern CPU vectorization capabilities. Comparative experiments using C language and GCC compiler demonstrate the substantial performance improvements achievable through vectorization:

// AVX2 vectorization code example
vmovdqa ymm0, YMMWORD PTR .LC0[rip]
vmovdqa ymm3, YMMWORD PTR .LC1[rip]
vpmulld ymm1, ymm0, ymm0
vpslld ymm1, ymm1, 1
vpaddd ymm2, ymm2, ymm1

Performance comparison of different vectorization technologies:

• SSE: 0.24 seconds, 2x faster than original Java code
• AVX: 0.15 seconds, 3x faster than original Java code
• AVX2: 0.08 seconds, 5x faster than original Java code

Optimization Recommendations and Conclusion

Based on the above analysis, the following optimization recommendations can be derived:

1. Expression Writing: In performance-sensitive scenarios, prefer 2 * (i * i) over 2 * i * i
2. JIT Tuning: Analyze JIT-generated assembly code using the -XX:+PrintOptoAssembly parameter
3. Vectorization Consideration: For numerical computation-intensive tasks, consider using languages or libraries with better vectorization support
4. Benchmarking: Performance optimization must be based on reliable benchmarking data

This case fully demonstrates the complex relationship between programming language surface syntax and underlying execution efficiency, reminding developers that pursuing performance requires deep understanding of compiler and hardware architecture principles.