blog/2025/01/23/Intro-to-C2-Part04

[utterances-bot]

Introduction to HotSpot JVM C2 JIT Compiler, Part 4 | Emanuel’s Blog

I assume that you have already looked at Part 0, Part 1, Part 2, and Part 3.

https://eme64.github.io/blog/2025/01/23/Intro-to-C2-Part04.html

[Hedge-Lord]

Fire blogpost series

[tarsa]

@eme64 Why transforming loops from long counted to int counted is beneficial? Basic 64-bit (Java long) arithmetic (add, sub, mul, shift, etc) should be as fast as analogous 32-bit (Java int) arithmetic on high performance 64-bit CPUs, so where's the gain on 64-bit CPUs?

[eme64]

@tarsa Thanks for the question!

I think there are at least two explanations:

• I do think there are lots of modern CPU's that have more throughput for 32bit ops than 64bit (especially mul). See https://www.agner.org/optimize/instruction_tables.pdf
• And we started with int loops, and all the infrastructure works with it. It was easier to adapt long-loops to int-loops than changing all optimizations to also deal with long loops.

[tarsa]

@eme64 Thanks for the answer.

Some more thoughts:

• I do think there are lots of modern CPU's that have more throughput for 32bit ops than 64bit (especially mul). See https://www.agner.org/optimize/instruction_tables.pdf

I've compared the latency and throughput between 32-bit and 64-bit muls on many different x86 CPUs from Intel using https://uops.info/table.html (for convenience) and http://users.atw.hu/instlatx64/GenuineIntel/GenuineIntel00C0662_ArrowLake_08_LC_InstLatX64.txt (for having some up to date information) and what I see is:

• 'P-cores' handle 32-bit and 64-bit multiplication equally good (same latency and throughput) since at least Sandy Bridge
• 'E-cores' in Alder Lake and Arrow Lake process 32-bit and 64-bit multiplications with same throughput, but the 64-bit muls have higher latency: 2 extra cycles on Alder Lake-E and 1 extra cycle on Arrow Lake-E

For simpler operations, like addition, shifts, logical operations, etc it seems that both latency and throughput is identical for 32-bit and 64-bit operands on virtually all modern CPUs from Intel.

OTOH, there's a performance loss by using 32-bit arithmetic instead of 64-bit arithmetic in simple cases on modern CPUs. For example, Alder Lake-P and Arrow Lake-E can both do simple additions in the renamer (giving 0 latency and 0 uops generated/ consumed, for maximum of few additions per cycle) if the register is 64-bit (doesn't work for 32-bit registers as the instruction latency tables show) and the addend is small (fits in a byte). See e.g. https://chipsandcheese.com/p/skymont-intels-e-cores-reach-for-the-sky#:~:text=Compared%20to%20Crestmont%2C%20Skymont%20has%20also%20gained%20Golden%20Cove%E2%80%99s%20ability%20to%20do%20simple%20math%20completely%20within%20the%20renamer. It could be the case that, by changing from 64-bit to 32-bit arithmetic, you lose more performance on 'P-cores' than you gain on 'E-cores' (and you can even lose performance on 'E-cores' if you lose more on not having simple math in renamer than you gain on having slightly lower latency of multiplications).

• And we started with int loops, and all the infrastructure works with it. It was easier to adapt long-loops to int-loops than changing all optimizations to also deal with long loops.

Given that OpenJDK and HotSpot is phasing out 32-bit support, maybe it would be wise to switch all loop optimizations to be 64-bit only and forget about converting long-counted loops to int-counter loops completely?

[eme64]

To be honest, I don't know the performance on all platforms.

One issue is that we do currently have our infrastructure work with int-loops. And there are some checks like RangeCheck that then need double the bit width to be performant, so we do the int-RangeChecks in long, which allows us to detect overflows. That would be harder to do if we had long-loops and then had to do long-overflow checking. Would be more expensive probably.

Also, a lot of the address computations based on int loop index still end up being lea or even combined load+add with x86 operations that allow memory access in some arithmetic operations. So I think in the backend, we end up doing a lot in 64bit operations anyway. But I'm less familiar with those backend specific things.