The Intel 12th Gen Core i9-12900K Review: Hybrid Performance Brings Hybrid Complexity
by Dr. Ian Cutress & Andrei Frumusanu on November 4, 2021 9:00 AM ESTInstruction Changes
Both of the processor cores inside Alder Lake are brand new – they build on the previous generation Core and Atom designs in multiple ways. As always, Intel gives us a high level overview of the microarchitecture changes, as we’ve written in an article from Architecture Day:
At the highest level, the P-core supports a 6-wide decode (up from 4), and has split the execution ports to allow for more operations to execute at once, enabling higher IPC and ILP from workflow that can take advantage. Usually a wider decode consumes a lot more power, but Intel says that its micro-op cache (now 4K) and front-end are improved enough that the decode engine spends 80% of its time power gated.
For the E-core, similarly it also has a 6-wide decode, although split to 2x3-wide. It has a 17 execution ports, buffered by double the load/store support of the previous generation Atom core. Beyond this, Gracemont is the first Atom core to support AVX2 instructions.
As part of our analysis into new microarchitectures, we also do an instruction sweep to see what other benefits have been added. The following is literally a raw list of changes, which we are still in the process of going through. Please forgive the raw data. Big thanks to our industry friends who help with this analysis.
Any of the following that is listed as A|B means A in latency (in clocks) and B in reciprocal throughput (1/instructions).
P-core: Golden Cove vs Cypress Cove
Microarchitecture Changes:
- 6-wide decoder with 32b window: it means code size much less important, e.g. 3 MOV imm64 / clks;(last similar 50% jump was Pentium -> Pentium Pro in 1995, Conroe in 2006 was just 3->4 jump)
- Triple load: (almost) universal
- every GPR, SSE, VEX, EVEX load gains (only MMX load unsupported)
- BROADCAST*, GATHER*, PREFETCH* also gains
- Decoupled double FADD units
- every single and double SIMD VADD/VSUB (and AVX VADDSUB* and VHADD*/VHSUB*) has latency gains
- Another ADD/SUB means 4->2 clks
- Another MUL means 4->3 clks
- AVX512 support: 512b ADD/SUB rec. throughput 0.5, as in server!
- exception: half precision ADD/SUB handled by FMAs
- exception: x87 FADD remained 3 clks
- Some form of GPR (general purpose register) immediate additions treated as NOPs (removed at the "allocate/rename/move ellimination/zeroing idioms" step)
- LEA r64, [r64+imm8]
- ADD r64, imm8
- ADD r64, imm32
- INC r64
- Is this just for 64b addition GPRs?
- eliminated instructions:
- MOV r32/r64
- (V)MOV(A/U)(PS/PD/DQ) xmm, ymm
- 0-5 0x66 NOP
- LNOP3-7
- CLC/STC
- zeroing idioms:
- (V)XORPS/PD, (V)PXOR xmm, ymm
- (V)PSUB(U)B/W/D/Q xmm
- (V)PCMPGTB/W/D/Q xmm
- (V)PXOR xmm
Faster GPR instructions (vs Cypress Cove):
- LOCK latency 20->18 clks
- LEA with scale throughput 2->3/clk
- (I)MUL r8 latency 4->3 clks
- LAHF latency 3->1 clks
- CMPS* latency 5->4 clks
- REP CMPSB 1->3.7 Bytes/clock
- REP SCASB 0.5->1.85 Bytes/clock
- REP MOVS* 115->122 Bytes/clock
- CMPXVHG16B 20|20 -> 16|14
- PREFETCH* throughput 1->3/clk
- ANDN/BLSI/BLSMSK/BLSR throughput 2->3/clock
- SHA1RNDS4 latency 6->4
- SHA1MSG2 throughput 0.2->0.25/clock
- SHA256MSG2 11|5->6|2
- ADC/SBB (r/e)ax 2|2 -> 1|1
Faster SIMD instructions (vs Cypress Cove):
- *FADD xmm/ymm latency 4->3 clks (after MUL)
- *FADD xmm/ymm latency 4->2 clks(after ADD)
- * means (V)(ADD/SUB/ADDSUB/HADD/HSUB)(PS/PD) affected
- VADD/SUB/PS/PD zmm 4|1->3.3|0.5
- CLMUL xmm 6|1->3|1
- CLMUL ymm, zmm 8|2->3|1
- VPGATHERDQ xmm, [xm32], xmm 22|1.67->20|1.5 clks
- VPGATHERDD ymm, [ym32], ymm throughput 0.2 -> 0.33/clock
- VPGATHERQQ ymm, [ym64], ymm throughput 0.33 -> 0.50/clock
Regressions, Slower instructions (vs Cypress Cove):
- Store-to-Load-Forward 128b 5->7, 256b 6->7 clocks
- PAUSE latency 140->160 clocks
- LEA with scale latency 2->3 clocks
- (I)DIV r8 latency 15->17 clocks
- FXCH throughput 2->1/clock
- LFENCE latency 6->12 clocks
- VBLENDV(B/PS/PD) xmm, ymm 2->3 clocks
- (V)AESKEYGEN latency 12->13 clocks
- VCVTPS2PH/PH2PS latency 5->6 clocks
- BZHI throughput 2->1/clock
- VPGATHERDD ymm, [ym32], ymm latency 22->24 clocks
- VPGATHERQQ ymm, [ym64], ymm latency 21->23 clocks
E-core: Gracemont vs Tremont
Microarchitecture Changes:
- Dual 128b store port (works with every GPR, PUSH, MMX, SSE, AVX, non-temporal m32, m64, m128)
- Zen2-like memory renaming with GPRs
- New zeroing idioms
- SUB r32, r32
- SUB r64, r64
- CDQ, CQO
- (V)PSUBB/W/D/Q/SB/SW/USB/USW
- (V)PCMPGTB/W/D/Q
- New ones idiom: (V)PCMPEQB/W/D/Q
- MOV elimination: MOV; MOVZX; MOVSX r32, r64
- NOP elimination: NOP, 1-4 0x66 NOP throughput 3->5/clock, LNOP 3, LNOP 4, LNOP 5
Faster GPR instructions (vs Tremont)
- PAUSE latency 158->62 clocks
- MOVSX; SHL/R r, 1; SHL/R r,imm8 tp 1->0.25
- ADD;SUB; CMP; AND; OR; XOR; NEG; NOT; TEST; MOVZX; BSSWAP; LEA [r+r]; LEA [r+disp8/32] throughput 3->4 per clock
- CMOV* throughput 1->2 per clock
- RCR r, 1 10|10 -> 2|2
- RCR/RCL r, imm/cl 13|13->11|11
- SHLD/SHRD r1_32, r1_32, imm8 2|2 -> 2|0.5
- MOVBE latency 1->0.5 clocks
- (I)MUL r32 3|1 -> 3|0.5
- (I)MUL r64 5|2 -> 5|0.5
- REP STOSB/STOSW/STOSD/STOSQ 15/8/12/11 byte/clock -> 15/15/15/15 bytes/clock
Faster SIMD instructions (vs Tremont)
- A lot of xmm SIMD throughput is 4/clock instead of theoretical maximum(?) of 3/clock, not sure how this is possible
- MASKMOVQ throughput 1 per 104 clocks -> 1 per clock
- PADDB/W/D; PSUBB/W/D PAVGB/PAVGW 1|0.5 -> 1|.33
- PADDQ/PSUBQ/PCMPEQQ mm, xmm: 2|1 -> 1|.33
- PShift (x)mm, (x)mm 2|1 -> 1|.33
- PMUL*, PSADBW mm, xmm 4|1 -> 3|1
- ADD/SUB/CMP/MAX/MINPS/PD 3|1 -> 3|0.5
- MULPS/PD 4|1 -> 4|0.5
- CVT*, ROUND xmm, xmm 4|1 -> 3|1
- BLENDV* xmm, xmm 3|2 -> 3|0.88
- AES, GF2P8AFFINEQB, GF2P8AFFINEINVQB xmm 4|1 -> 3|1
- SHA256RNDS2 5|2 -> 4|1
- PHADD/PHSUB* 6|6 -> 5|5
Regressions, Slower (vs Tremont):
- m8, m16 load latency 4->5 clocks
- ADD/MOVBE load latency 4->5 clocks
- LOCK ADD 16|16->18|18
- XCHG mem 17|17->18|18
- (I)DIV +1 clock
- DPPS 10|1.5 -> 18|6
- DPPD 6|1 -> 10|3.5
- FSIN/FCOS +12% slower
Facebook
Twitter
RSS
474 Comments
View All Comments
bananaforscale - Friday, November 5, 2021 - link
I do wonder about the scheduler interactions if we add Process Lasso into the mix.mode_13h - Friday, November 5, 2021 - link
Ian, please publish the source to your 3D Particle Movement benchmark. Let us see what the benchmark is doing. Also, it's not only AMD that can optimize the AVX2 path. Please let the community have a go at it.mode_13h - Friday, November 5, 2021 - link
> The core also supports dual AVX-512 ports, as we’re detecting> a throughput of 2 per cycle on 512-bit add/subtracts.
I thought that was true of all Intel's AVX-512 capable CPUs? What Intel has traditionally restricted is the number of FMAs. And if you look at the AVX-512 performance of 3DPM on Rocket Lake and Alder Lake, the relative improvement is only 6%. That doesn't support the idea that Golden Cove's AVX-512 is any wider than that of Cypress Cove, which I thought was established to be single-FMA.
SystemsBuilder - Saturday, November 6, 2021 - link
Cascade lake X and Skylake X/XE core i9 and Xeons with more that 12 cores (it think) have two AVX-512 capable FMA ports (port 0 and port 5) while all other AVX-512 capable CPUs have 1 (Port 0 fused).the performance gap could be down to coding. you need to vectorize your code in such a way that you feed both ports at maximum bandwidth.
However, in practice it turns out that the bottle neck is seldom the AVX-512 FMA ports but the memory bandwidth, i.e. it is very hard to keep up with the FMAs, each capable of retiring many of the high end vector operations in 4 clock cycles. e.g. multiply two vectors of 16 32bit floats and add to a 3rd vector in 4 clock cycles. Engaging both FMAs => you retire one FMA vector op every 2 cycles. Trying to avoid getting too technical here, but with a bit of math you see that the total bandwidth capability of the FMAs easily outstrips the cache, even if most vectors are kept in the Z registers – the resisters can only absorbs so much and at the steady state, the cache/memory hierarchy becomes the bottleneck depending on the problem size.
Some clever coding can work around that and hide some of the memory reads (using prefetching etc) but again there is only so much you can do. In other words two AVX-512 FMAs are beasts!
coburn_c - Friday, November 5, 2021 - link
This hybrid design smacks of 5+3 year ago thinking when they wanted to dominate mobile. Maybe that's why it needs 200+ watts to be performant.mode_13h - Friday, November 5, 2021 - link
This doesn't make sense. Their P-cores were never suitable for phones or tablets. Still aren't.I think the one thing we can say is *not* behind Alder Lake is the desire to make a phone/tablet chip. It would be way too expensive and the P-core would burn too much power at even the lowest clockspeeds.
tygrus - Saturday, November 6, 2021 - link
It appears the mixing is more trouble than they are worth for pure mid to high range desktop use. Intel should have split the Desktop CPU's from the mobile CPU's. Put P-cores in the new mid to high range desktops. Put the E-cores in mobiles or cheap desktops/NUC.Wrs - Saturday, November 6, 2021 - link
The mixing helps with a very sought-after trait of high-end desktops. Fast single/lightly threaded performance AND high multithreaded capacity. Meaning very snappy and can handle a lot of multitasking. It is true they can pump out more P cores and get rid of E cores, but that would balloon the die size and cut yields, spiking the cost.mode_13h - Saturday, November 6, 2021 - link
> AND high multithreaded capacity.Yes. This is supported with a very simple experiment. Look at the performance delta between 8 P-Cores and the full 8 + 8 configuration, on highly-threaded benchmarks. All the 8 + 8 configuration has to do is beat the P-core -only config by 25%, in order to prove it's a win.
The reason is simple. Area-wise, the 8 E-cores are equivalent to just 2 more P-cores. The way I see it is as an easy/cheap way for Intel to boost their CPU on highly-threaded workloads. That's what sold me on it. Before I saw that, I only thought Big.Little was good for power-savings in mobile.
mode_13h - Saturday, November 6, 2021 - link
Forgot to add that page 9 shows it meets this bar (I get 25.9%), but the reason it doesn't scale even better is due to the usual reasons for sub-linear scaling. Suffice it to say that a 10 P-core wouldn't scale linearly either, meaning the net effect is almost certainly better performance in the 8+8 config (for integer, at least).