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 ESTPower: P-Core vs E-Core, Win10 vs Win11
For Alder Lake, Intel brings two new things into the mix when we start talking about power.
First is what we’ve already talked about, the new P-core and E-core, each with different levels of performance per watt and targeted at different sorts of workloads. While the P-cores are expected to mimic previous generations of Intel processors, the E-cores should offer an interesting look into how low power operation might work on these systems and in future mobile systems.
The second element is how Intel is describing power. Rather than simply quote a ‘TDP’, or Thermal Design Power, Intel has decided (with much rejoicing) to start putting two numbers next to each processor, one for the base processor power and one for maximum turbo processor power, which we’ll call Base and Turbo. The idea is that the Base power mimics the TDP value we had before – it’s the power at which the all-core base frequency is guaranteed to. The Turbo power indicates the highest power level that should be observed in normal power virus (usually defined as something causing 90-95% of the CPU to continually switch) situation. There is usually a weighted time factor that limits how long a processor can remain in its Turbo state for slowly reeling back, but for the K processors Intel has made that time factor effectively infinite – with the right cooling, these processors should be able to use their Turbo power all day, all week, and all year.
So with that in mind, let’s start simply looking at the individual P-cores and E-cores.
Listed in red, in this test, all 8P+8E cores fully loaded (on DDR5), we get a CPU package power of 259 W. The progression from idle to load is steady, although there is a big jump from idle to single core. When one core is loaded, we go from 7 W to 78 W, which is a big 71 W jump. Because this is package power (the output for core power had some issues), this does include firing up the ring, the L3 cache, and the DRAM controller, but even if that makes 20% of the difference, we’re still looking at ~55-60 W enabled for a single core. By comparison, for our single thread SPEC power testing on Linux, we see a more modest 25-30W per core, which we put down to POV-Ray’s instruction density.
By contrast, in green, the E-cores only jump from 5 W to 15 W when a single core is active, and that is the same number as we see on SPEC power testing. Using all the E-cores, at 3.9 GHz, brings the package power up to 48 W total.
It is worth noting that there are differences between the blue bars (P-cores only) and the red bars (all cores, with E-cores loaded all the time), and that sometimes the blue bar consumes more power than the red bar. Our blue bar tests were done with E-cores disabled in the BIOS, which means that there might be more leeway in balancing a workload across a smaller number of cores, allowing for higher power. However as everything ramps up, the advantage swings the other way it seems. It’s a bit odd to see this behavior.
Moving on to individual testing, and here’s a look at a power trace of POV-Ray in Windows 11:
Here we’re seeing a higher spike in power, up to 272 W now, with the system at 4.9 GHz all-core. Interestingly enough, we see a decrease of power through the 241 W Turbo Power limit, and it settles around 225 W, with the reported frequency actually dropping to between 4.7-4.8 GHz instead. Technically this all-core is meant to take into account some of the E-cores, so this might be a case of the workload distributing itself and finding the best performance/power point when it comes to instruction mix, cache mix, and IO requirements. However, it takes a good 3-5 minutes to get there, if that’s the case.
Intrigued by this, I looked at how some of our other tests did between different operating systems. Enter Agisoft:
Between Windows 10 and Windows 11, the traces look near identical. The actual run time was 5 seconds faster on Windows 11 out of 20 minutes, so 0.4% faster, which we would consider run-to-run variation. The peaks and spikes look barely higher in Windows 11, and the frequency trace in Windows 11 looks a little more consistent, but overall they’re practically the same.
For our usual power graphs, we get something like this, and we’ll also add in the AVX-512 numbers from that page:
Compared to Intel’s previous 11th Generation Processor, the Alder Lake Core i9 uses more power during AVX2, but is actually lower in AVX-512. The difficulty of presenting this graph in the future is based on those E-cores; they're more efficient, and as you’ll see in the results later. Even on AVX-512, Alder Lake pulls out a performance lead using 50 W fewer than 11th Gen.
When we compare it to AMD however, with that 142 W PPT limit that AMD has, Intel is often trailing at a 20-70 W deficit when we’re looking at full load efficiency. That being said, Intel is likely going to argue that in mixed workloads, such as two software programs running where something is on the E-cores, it wants to be the more efficient design.
Facebook
Twitter
RSS
474 Comments
View All Comments
mode_13h - Friday, November 5, 2021 - link
It basically comes down to a context-switch. And those take a couple microseconds (i.e. many thousands of CPU cycles), last I checked. And that assumes there's a P-core available to run the thread. If not, you're potentially going to have to wait a few timeslices (often 1 -10 ms).Now, consider the case of some software that assumes all cores are AVX-512 capable. This would be basically all AVX-512 software written to date, because we've never had a hybrid one, or even the suggestion from Intel that we might need to worry about such a thing. So, the software spawns 1 thread per hyperthread (i.e. 24 threads on the i9-12900K) but can only run 16 of them at any time. That's going to result in a performance slowdown, especially when you account for all the fault-handling and context-switching that happens whenever any of these threads tries to run on an E-core. You'd basically end up thrashing the E-cores, burning a lot of power and getting no real work done on them.
mode_13h - Friday, November 5, 2021 - link
Forgot to address the case where the OS blocks the thread from running on the E-core, again.So, if we think about how worker threads are used to split up bigger tasks, you really want to have no more worker threads than actual CPU resources that can execute them. You don't want a bunch of worker threads all fighting to run on a smaller number of cores.
So, even the solution of having the OS block those threads from running on the E-cores would yield lower performance than if the the app knew how many AVX-512 capable cores there were and spawned only that many worker threads. However, you have to keep in mind that whether some function uses AVX-512 is not apparent to a software developer. It might even do this dynamically, based on whether AVX-512 is detected, but this detection often happens at startup and then the hardware support is presumed to be invariant. So, it's problematic to dump the problem in the application developer's lap.
eastcoast_pete - Thursday, November 4, 2021 - link
Plus, enabling AVX-512 on the big Cores would have meant having it on the E (Gracemont) cores also, or switching workloads from P to E cores on the fly won't "fly". And having AVX-512 in Gracemont would have interfered with the whole idea of Gracemonts being low-power and small footprint on the die. I actually find what Ian and Andrei did here quite interesting: if AVX-512 can really speed up whatever you want to do, disable the Gracemonts and run AL in Cove only. If that could be a supported option with a quick restart, it might be worthwhile under the right circumstances.AntonErtl - Friday, November 5, 2021 - link
There is no relevant AVX-512 state before the first AVX-512 instruction is executed. So trapping and switching to a P-core is entirely doable. Switching back would probably be a bigger problem, but one probably does not want to do that anyway.Spunjji - Friday, November 5, 2021 - link
Possible problem: how would you account for a scenario where the gain from AVX-512 is smaller than the gain from running additional threads on E cores? Especially when some processors have a greater proportion of E cores to P cores than others. That could get quite complicated.TeXWiller - Friday, November 5, 2021 - link
If you look at the Intel's prerelease presentation about Thread Director carefully, you see they are indeed talking about moving the integer (likely control) sections of AVX threads to E-cores and back as needed.kobblestown - Friday, November 5, 2021 - link
I'll reply to my comment because it seems the original one was not understood.When you have an AVX512-using thread on a P thread, it might happen that it needs to be suspended, say, because the CPU is overloaded. Then the whole CPU state is saved to memory so the execution can later be resumed as if nothing has happened. In particular, it may be rescheduled on another core when its time for it run again. If that new core is a P core, then we're safe. But if it's an E core, it might happen that we hit an AVX512 instruction. Obviously, the core cannot execute it so it traps into the OS. The OS can check what was the offending instruction and determine that the problem is not the instruction, but the core. So it moves it back to a P core, stores a flag that this thread should not be rescheduled on an E-core and keeps chugging.
Now, someone suggested that there might be a problem with the CPU state. And, indeed, you can not restore the AVX512 part of the state on an E core. But it cannot get changed by an E core either, because at the first attempt to do it it will trap. So the AVX512 part of the state that was saved on a P core is still correct.
Since this isn't being done, there might be (but not "must be" - intel, like AMD, will only do what is good for them, not what is good for us) some problem. One being that an AVX512 thread will never be rescheduled on an E core even if it executes a single AVX512 instruction. But it's still better than the current situation which postpones the wider adoption of AVX512 yet again. I mean, the transistors are already there!
factual - Thursday, November 4, 2021 - link
Great win for consumers! AMD will need to cut prices dramatically to be competitive otherwise Intel will dominate until Zen4 comes out!kobblestown - Friday, November 5, 2021 - link
Let's first see Zen3D early next year. It will let me keep my investment into the AM4 platform yet offer top notch performance.Spunjji - Friday, November 5, 2021 - link
"AMD will need to cut prices dramatically"Not until Intel's platform costs drop. Nobody's buying an ADL CPU by itself.