www.pcworld.com
Only schockingly it doesn't.Yeah, totally doesn't suck 20% more power. 12900K capping around 240-260 watts with whatever boosting alg it was using, TVB2 pt whatever; 13900K pulling an extra fifty watts with the TVB3 PL1/PL2 LOCKEDIntel's Core i9-13900K consumes insane power. You can tame it.
For Intel's new flagship chip, unrepentant power doesn't have to mean unbridled energy consumption.
Well, you can view it that way, but it is NOT cast in stone. Intel is leaving an opening for AVX10.2/512 on p-cores. Look at Figure 1.2 in section 1.5 at this link, which in the AVX10.2 column clearly indicates all p-cores and e-cores get the AVX-10 instructions and there is an optional FP/Int 512-bit variant:
And 74 to 79 is a meager 6.5% even though in the article they say that the e-cores are like 50% the performance of the p-cores with htt enabled, even in the graph the e-cores alone are at 38 but together with the p-cores they only add 5 and drop to adding only 6.5%I'm not confusing anything.
Let's leave aside obsolete products and focus on modern cores, shall we?
In modern cores, HyperThreading typically is not a big win for floating-point workloads, and sometimes even a detriment, as this clearly shows:
Compare 73.92 (8P2T + 0E) vs. 72.38 (8P1T + 0E). That's a meager 2.1% benefit.
Yes, I had seen that diagram and indeed that document. Yes, the ISA allows it, and maybe someday there will be a hybrid CPU which implements AVX10.x/512 on all cores.
First, you should round consistently. In actual fact, 79.76 / 73.92 -> 7.9% faster.
Yes, exactly. Their standalone performance should tell you that scaling is being artificially hampered by some of the factors I mentioned, above.
Ahhh! But you think that HTT is magic and doesn't need more power right?!
So you show it yourself, the e-cores are only better if you run at upto 3-3.5Ghz so at default speeds they DEcrease the efficiency of the whole CPU especially in the libx264 one, how do you link a test without even reading it and only linking the pictures that you like?!These tests seem to measure only package power, showing the E-cores do quite well for most of their frequency envelope:
But the P-cores have more absolute performance. So, when you're looking at perf/(W_cores + W_system) the numerator is big enough to overcome the W_system term of the denominator. I know the test isn't exactly defined that way, but just to illustrate my point.
Thats been happening since forever, that's the only reason that intel CPUs show up with 315-330W power draw at "stock" in benches very often, intel never had CPUs burning up despite having them tortured at well above 30% above warranty levels of power.
You're both talking circles around each other at this point. Golden Cove has much higher IPC than Gracemont so if it wasn't winning when both are running out of the peak efficiency curve something would be very wrong. Gracemont also doesn't have anywhere near the FP/Vector scheduler capability of Golden Cove so you have wider gaps in certain workloads. What you end up with is situationally better efficiency for each type of core.So you show it yourself, the e-cores are only better if you run at upto 3-3.5Ghz so at default speeds they DEcrease the efficiency of the whole CPU especially in the libx264 one, how do you link a test without even reading it and only linking the pictures that you like?!
But then again you do this all the time, you just post a wall of text and hope that people just get bored with you...
"This looks bad for the Gracemont based E-Cores. According to Intel, they can’t beat the P-Cores at any power level, meaning the E-Cores are only efficient in terms of area. Anyway, let’s run our own tests.
With a vectorized workload, Gracemont only beats Golden Cove when running at ultrabook-throttlefest speeds and drawing under 6W. Remember that Gracemont isn’t optimized for 256-bit vectors. That’s over 17% of instructions in libx264, so Gracemont is not having a good time. It looks much better with a pure integer workload:"
" Golden Cove can be efficient too – just not at stock. Between 3 and 4 GHz, these P-Cores can give the E-Cores a run for their money. In an integer workload, Golden Cove consumes about the same amount of total energy while completing the task faster. With a vectorized load, Golden Cove finishes the task so much faster that it ends up using less total energy than Gracemont, even though Gracemont draws less power That means running Gracemont above 3.2 GHz is pointless if energy efficiency is your primary concern. Running the E-Cores at 3.8 GHz basically makes them worse P-Cores. But that’s exactly what Alder Lake does by default."
The e-cores are only good at extracting a bit more performance at extremely low power. As you can see at 5.5W per 4 cores the p-cores already start to dominate the e-cores.
And the only way to extract that would be for the thread director to send workloads to the appropriate core that would get you more efficiency.
Whether or not it's power-limited, it added far less performance than the E-cores. That performance question is ultimately what dictates efficiency. So, in this context, the reason HT didn't add significant performance is somewhat irrelevant.
I don't follow. SPECbench uses real-world apps and workloads. It's not synthetic.
CPU pipeline occupancy isn't the only thing determining HTT's impact. Increasing the number of threads also increases cache contention. And, if memory bandwidth is really the bottleneck, then simply adding more threads probably won't help.
That's a mistaken assumption. What the graph is showing is that, if you have a single thread and want it to run with greatest efficiency for a given performance level, the point where you'd want to switch it over to a P-core is at 3.1 GHz.
This is getting pretty close to crossing the line to a personal attack. You don't know that I didn't read it. Until we discuss it, you can't know why our interpretations of it differ. Accusing me of not reading it is therefore a baseless accusation.
No, what I do is try to get to the heart of the matter. I try to be data-driven, not agenda-driven. I'm not someone who just says "brand X sucks". I want to look at the data and analysis and understand what it's telling us. If you push for a simplistic conclusion where one might not exist, then you're going to get frustrated. That's on you, not me.
As I explained above, they're only talking about peak-efficiency. That's not how either core is actually used, in practice.
This should've been your boldest quote. If energy efficiency were your primary concern, you'd just run the E-cores at 1.1 GHz and the P-cores at 1.4 GHz. Once you try to scale performance, the addition of E-cores can improve overall efficiency at all points on the scale. Whether they're actually operated in that way is another matter.
I hope I've adequately explained why this is not the case. Please take the time to read through my posts and try to understand the points I'm making.
e-core gets less than 6FPS at ~27W p-core gets more than 8FPS at the same ~27W that is more than 33% better efficiency that you were trying to discard with this article...
The graph you are talking about is still about a cluster of four cores so not one thread but at least four.
Nope, e-cores don't go to 4.4 so this is completely irrelevant.
As I carefully explained, the graph can be misleading, if you don't think about the way cores in a hybrid CPU are used in practice. For instance, one thing that graph shows is that the P-cores @ max power get only 0.14 FPS/W, which is far worse than worst-case 0.22 FPS/W the E-cores deliver. And you don't have to run the E-cores at their max power, either.
The two are further apart than that. They're also measuring package vs. system power and groups of 4 cores.
My statement roughly holds, as far as looking at cross-over points. If it were core vs. core, then we should expect to see a crossover at about the same spot.
It's not wrong, if you let the P-cores go above 4.4 GHz. At that point, it becomes more efficient to add further performance via the E-cores running at any clock they support!
Please re-read. I never said nor implied the E-cores run at 4.4 GHz. What I said was:
Again, you're cherry-picking. You focus only on the x264 case, yet we know the E-cores aren't as good at floating-point and vectorized workloads as integer. As a reminder, here are the core-power curves for 7zip:
But you are forced to run the p-cores at their max power right?! That's why this statement makes sense to you?!
Yes you are not wrong as long as you use enough qualifiers, that's what I already proposed you do.It's not wrong, if you let the P-cores go above 4.4 GHz. At that point, it becomes more efficient to add further performance via the E-cores running at any clock they support!
I think this part needs to be emphasized: it's not an either/or scenario. You can continue to operate E-cores in their efficiency sweet-spot, regardless of what the P-cores are doing. Doing so improves the overall efficiency of the CPU, because performance is cumulative, while efficiency is an average.
When you are accusing people of cherry-picking you shouldn't be cherry-picking yourself...or I guess this is more of a goal post shifting.Again, you're cherry-picking. You focus only on the x264 case, yet we know the E-cores aren't as good at floating-point and vectorized workloads as integer. As a reminder, here are the core-power curves for 7zip:
Here, Gracemont is the same or more efficient across the entire range. The only thing that makes it worse is if you compare package-level energy usage, but then we're not comparing core-to-core, but instead measuring them in a somewhat artificial context.
For the same reason they do it on the desktop, the fewer expensive p-cores they need to use per sold unit increases the money they make per unit and also allows them to make more units to make even more money.
Of course not. That's why I talked about core-scheduling and dialing in the optimal blend of clock speeds for a given power target and number of threads.
My point about comparing efficiency at peak utilization was to show that the P-cores' efficiency becomes worse than the worst of the E-cores', past a certain point. Much worse. If you focus only on the overlap, you can easily lose sight of that.
Complex data defies simple explanations. Nuances matter.
That was just a thought experiment. In reality, a user expects a certain level of responsiveness or throughput, is running a certain amount of threads, and is prepared for a certain amount of power/heat to be dissipated. If we take the simplistic case of a performance-oriented scheduler, it will nearly always push the cores past their "sweet spot", in order to maximize performance. That's often not a matter of simply running any of the cores at max speed/power, unless the number of threads is low or the power limit (and cooling capacity) is very high.
I'm not. I just included a dataset you omitted. I've never shifted goalposts, either. My contention is the same as it always was: E-cores are a more energy-efficient way to scale performance.
The problem is that you're taking this raw data outside the context of how it's used. In practice, you're not running both P-cores and E-cores at the same frequency, which is the only way that graph shows parity. In practice, you're usually running the P-cores at significantly higher frequency than the E-cores, which is why adding E-cores to the mix helps improve the overall efficiency of the solution.
That's a false equivalence. The precise interpretation of the data matters. The tagline of Chips & Cheese is: "The Devil is in the Details", which is why they do such in-depth micro-benchmarking, mixed with extensive analysis. Even when I don't agree with their analysis, the data is still very useful.
Not to agree with you, but just to explore this line of reasoning: you're saying Intel intentionally builds a mobile product with worse battery-life, just to save money?
I have yet to see an intel cpu being fed 20% to 40% voltages above the LIMITS (not recommended guidance.. LIMITS) in both the memory side AND the core side.
No you are the one that takes the graphs with the fixed clock speeds and tries to use them to make your point...
I don't know much about the laptop landscape and I don't care much about it, this is just my guess of why they are doing it.
But only if you believe the media and think that running a CPU not only at its limit but way above it is the normal way to use a CPU.
Do you even know what the voltage limit is for intel???
The energy vs. frequency plots show how efficiency changes over the cores' respective operational ranges.
You don't seem to understand how frequency-scaling is managed, in these CPUs. It's not like you just mash your pedal on the gas and run a core at its maximum frequency, because if you have a multithreaded workload, you'll often be constrained by power or thermal limits.
But, they're using the same cores in a way contrary to how you describe. Can Intel really be so dumb or oblivious to battery life? Battery life is something every laptop review measures and it's an issue for key market segments, like premium corporate laptops by execs who don't want to always be hunting for a place to plug in. It's also an area where Apple is excelling.
No, I don't see how that's related to anything I said.
Show me one benchmark that shows that happening because for the last forever years every single benchmark is with the clocks running pedal to the metal, either with unlimited power or with the a certain power target but always with all cores running as fast as the power allows.The energy vs. frequency plots show how efficiency changes over the cores' respective operational ranges.
You don't seem to understand how frequency-scaling is managed, in these CPUs. It's not like you just mash your pedal on the gas and run a core at its maximum frequency, because if you have a multithreaded workload, you'll often be constrained by power or thermal limits.
See, if I'm designing a core frequency governor, based on this data, what I'd do is run the E-cores up to 3.1 GHz, where they achieve 1.33 MB/s per W. Then, don't increase them until performance demands and power budgets push the P-cores beyond 31 W. At that point, they're only doing 0.90 MB/s per W, whereas the worst that the E-cores do is 0.96 MB/s per W. So, then it makes sense to boost the E-cores to their max frequency before devoting any more power to the P-cores.
As I said I don't know much about the laptop world, how is the battery life at very low power where the e-cores are the most efficient?
Look at this picture, if you can allow your CPU to use more than 90W and unless you have to run every core in your CPU at full power all the time then you can replace every single e-core with the equal amount of p-cores and make those replacement p-cores use the same amount of power as the e-cores do now and you would get higher performance for the same amount of total power, hence the e-cores are not more power efficient to scale performance,
No, I don't see how that's related to anything I said.
Facebook
Twitter
Instagram