Instruction 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

 

Power: P-Core vs E-Core, Win10 vs Win11 CPU Tests: Core-to-Core and Cache Latency, DDR4 vs DDR5 MLP
Comments Locked

474 Comments

View All Comments

  • Wrs - Saturday, November 6, 2021 - link

    Nah, they just weren't that competitive. Athlon64 was decent (lot of credit to Jim Keller) but didn't let AMD take massive advantage of Intel's weakness during the Pentium 4 era because AMD fabs were capacity limited. Once Conroe came out mid 2006 the margins dried up rapidly and AMD had no good response and suffered a talent exodus. It's true Intel made it worse with exclusivity bonuses, but I think AMD's spiral toward selling their fabs would have happened anyway. No way they were going to catch up with tick-tock and Intel's wallet.
  • GeoffreyA - Monday, November 8, 2021 - link

    I've always felt the K10 wasn't aggressive enough, owing to AMD not having factored Conroe into their equations when K10 was designed. Then, like startled folk, they tried to take back the lead by a drastic departure in the form of Bulldozer; and that, as we know, sank them into the ditch. Nonetheless, I'm glad they went through the pain of Bulldozer: Zen wouldn't have been as good otherwise.
  • mode_13h - Tuesday, November 9, 2021 - link

    > FX series was as bad as it was for a couple of reasons

    I thought I also heard they switched from full-custom layout to ASIC flow (maybe for the sake of APUs?). If so, that definitely left some performance on the table.
  • bunnyfubbles - Thursday, November 4, 2021 - link

    3D v-cache will be out before Zen 4 and should help close the gap if not regain the overall lead on the high end. The problem for AMD is the competition below the i9 vs R9 realm, where the E cores really pull more than their weight and help the i9 compete with the R9s in multi, but for the i5s and i7s vs their R5 and R7 counterparts, its even-Steven with performance cores, then you have the E cores as the trump card.
  • MDD1963 - Thursday, November 4, 2021 - link

    If AMD gains an averge of ~10% in gaming FPS with the 3D cache onslaught, that should put them right back near the top...certainly much closer to the 12900K....
  • geoxile - Thursday, November 4, 2021 - link

    15% on average. 25% at the highest. Intel really should have offered a 16 P-core die for desktop smdh, classic intel blunder
  • Spunjji - Friday, November 5, 2021 - link

    That would be a hell of a large die and necessitate a total redesign of the on-chip fabric. I don't think it would really make any sense at all.
  • RSAUser - Monday, November 8, 2021 - link

    12900K is already huge, each performance core is the size of about 4 E cores, going 16C P-Core would probably mean a 70% die size increase, and then you run into core to core communication issues, AMD got around it with infinity fabric but that's why you have the higher latency access between cores in different core complexes and Intel gives a more consistent access time on higher end products. Intel's current cores are mosly ringbus, so travel from one core to the next, getting to 16 doesn't scale well, they used a mesh topology in some Skylake CPU's, that latency was too high and hampered performance badly, you'd run into that same issue with 16C.
    That's without checking into yield, getting 16C on one wafer that are all perfectly clocking high is going to be a very, very rare chip; AMD gets around it using the core complexes (CX) of 4 cores each, together into a CCD (core chiplet die) and then in Zen 3 (5000 series) is supposedly 8C CCX, which makes rare chips 8C if full ccx works well, else 6C if 2 can't make it turns into a 5600X.
  • StevoLincolnite - Friday, November 5, 2021 - link

    AMD has an answer before Zen 4.

    And that is Zen 3 with V-Cache.
  • Spunjji - Friday, November 5, 2021 - link

    "This is their Zen 1 moment"
    Indeed!

    "at a lower price"
    Not really, if you take platform into account (and you have to!)

    "Zen 4 isnt even competing with Alder Lake, Raptor Lake is rumored to be out before Zen 4"
    Potentially, but Zen 4 is a bigger jump from Zen 3 than Raptor is predicted to be from Alder. Raptor will have more E cores but it's on the same process, so it's likely to offer better perf/watt in multithreading but unlikely to increase overall performance substantially (unless they allow maximum power draw to increase).

    "AMD has really screwed up with their launch cycle"
    Not really? They're still competitive in both price/performance (accounting for platform cost) and perf/watt. Zen 3D should shore up that position well enough.

    "Intel is truly back"
    Yup!

Log in

Don't have an account? Sign up now