News Core i9-14900K, Core i7-14700K CPUs Benchmarked

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.
I expect a bump in power consumption here for sure. Intel's 10nm is pushed to its limits with Raptor Lake given the boost in core count and clockspeed (increased cache likely also uses more power). This refresh is going to push everything off the charts. I suspect that with this refresh, the i7 will also become very difficult to cool with conventional AIO cooler, in addition to i9.
Oh please, go ahead and explain to us how difficult it is to cool an i9...
A cheap $20 cooler gets you 245W out of 251W and just above 5Ghz all core, how is that difficult?! Even passive cooling gets you 198W and 4.7Ghz all core.
Starting with the Thermalright SFF cooler, clocks of 4722MHz were maintained consuming 198W on average. The $20 Assassin 120 R SE sustained 5055MHz (an increase of 333MHz) with the CPU consuming an average of 245W.
 

ilukey77

Reputable
Jan 30, 2021
794
331
5,290
No, they said that p-cores will support 512.

Also e-cores are far less power-efficient in multi they are more area and cost efficient which is why intel uses them
efficiency-multithread.png


It wasn't fixed...
And it doesn't matter what part of the CPU can't stand the power, the point is still that too much power fries the CPU.

The only thing they did was to force-limit the amount of power that the CPU can use, turning an unlocked CPU into a locked one, so that it doesn't melt down right away, that's not fixing the problem that is avoiding the problem.

We have no official statement yet, even the 14700 might be released without extra cores and this one that surfaced might just be a test CPU or for a special customer or something.
Also most people are not rich and they buy the CPU they need and stick with it for 5 years and more, a dead platform is zero argument for most people, until they can spend money on a CPU again they would have to change everything anyway, or they go for a used/older part where a dead platform is a good thing because it lowers prices.
Ohh WOW its my buddy with his stupid graphs and contradictions ..

Franky its past a joke now you talk BS just for the sake of it and show your stupid graphs for a rise go away !!
 

bit_user

Titan
Ambassador
I just wanted to point out that Raptor isn't a refresh of Alder any more than Zen 4 is a refresh of Zen 3 or Haswell was of Ivy Bridge.
That's rubbish. The microarchitecture of the cores didn't change between Alder Lake and Raptor Lake, whereas it did in those other examples.

Even an i5 13600k downclocked 4-500mhz from it's capabilities (aka stock) beats a 12900k using more cores and a lot more power in games.
Oh, there's a news flash: increased core count + bigger caches = better performance.

Again, same thing we saw when more cores were added in Coffee Lake. You could run it @ lower clocks in the same power budget and get more performance than Skylake, because adding cores is a more efficient way to scale multithreaded performance.
 

bit_user

Titan
Ambassador
We've been through this. I think it's abundantly clear they're talking about P-core only Xeons, as I quoted from the other more detailed PDF that Intel published about AVX10.

Believe whatever you want. It won't change anything.

Also e-cores are far less power-efficient in multi they are more area and cost efficient which is why intel uses them
efficiency-multithread.png
Thank you for proving my point. If you look at the P + E combination, it yields the best result.

Interpreting those system power comparisons is problematic, because the E-cores are slower and have to drag along higher system overheads with them. In actual fact, the E-cores don't run by themselves in multithreaded workloads, they run along side the P-cores. When run in that way, we see they actually do provide a net benefit.

Even so, I'll bet that if you tried the exact same test with the N300 or Raptor Lake i9, we should see the E-cores really showing their stuff.
 
We've been through this. I think it's abundantly clear they're talking about P-core only Xeons, as I quoted from the other more detailed PDF that Intel published about AVX10.
Xeons are the only ones that currently have avx 512 which is why they singled them out.
When they say p-cores they have to mean p-cores and not 'xeon p-cores'.
Thank you for proving my point. If you look at the P + E combination, it yields the best result.
No, even if the combination would be better, even though it's probably not because the '8p-core only' is without HTT, doesn't mean that the e-cores are more power-efficient than the p-cores, they are not, the e-cores alone are 20% less power efficient than the p-cores without htt, combinations are meaningless for the individual cores which you were talking about.
 
Ohh WOW its my buddy with his stupid graphs and contradictions ..

Franky its past a joke now you talk BS just for the sake of it and show your stupid graphs for a rise go away !!
I know right?!
We should all just be lying and not need to prove anything we say by providing links to the things we say.
Just insult people all the time and tell them things you make up.
 
Where did you see them increasing power limits for the 14th gen?!
Ah, that's fair to point out. It is an educated guess based on the extra 200Mhz and additional E-cores they're slapping on some SKUs. I sincerely doubt their process has improved enough to keep the same power to performance ratio with the extra hertz AND extra E-cores.

Regards.
 

bit_user

Titan
Ambassador
Xeons are the only ones that currently have avx 512 which is why they singled them out.
When they say p-cores they have to mean p-cores and not 'xeon p-cores'.
Here's an excerpt from the Architecture Specification, providing further insight into their plans for 512-bit support:
A “converged” version of Intel AVX10 with maximum vector lengths of 256 bits and 32-bit opmask registers will be supported across all Intel processors, while 512-bit vector registers and 64-bit opmasks will continue to be supported on some P-core processors.​

I think "some P-core processors" means their P-core -only Xeons.

Also, this part:
"This converged version will be supported on both P-cores and E-cores. While the converged version is limited to a maximum 256-bit vector length"

There really doesn't seem to be any ambiguity, at this point. I think Intel just nailed shut the coffin on having 512-bit in their client processors.

No, even if the combination would be better, even though it's probably not because the '8p-core only' is without HTT,
On the question of HTT, workloads like Cinebench typically gain very little from it, with it sometimes being worse. However, you're missing the forest for the trees, here. Adding the E-cores to the mix indisputably increases performance. Doing that at at slightly less total energy is actually very impressive! It's usually very hard to scale up performance without hurting efficiency.

doesn't mean that the e-cores are more power-efficient than the p-cores, they are not, the e-cores alone are 20% less power efficient than the p-cores without htt,
Again, you're misreading the data. It's measuring system power, which means the poor E-cores's energy usage gets lumped together with the RAM, SSD, GPU, etc. The cores, themselves are certainly not less power-efficient than the P-cores. It's just that there's a lot of dead weight they have to drag along.

Again, find the same/similar experiment conducted on Raptor Lake or a N300 and you'll see the E-cores start to shine.
 
Last edited:
Ah, that's fair to point out. It is an educated guess based on the extra 200Mhz and additional E-cores they're slapping on some SKUs. I sincerely doubt their process has improved enough to keep the same power to performance ratio with the extra hertz AND extra E-cores.

Regards.
Ok sure, if the 14700k will have more cores it will use more power than the 13700k in some tests but the maximum allowed power won't change.
It's 251w for both the 13700 and the 13900 and it probably will stay 251W for the 14th gen, at least there is no info on it being otherwise.
On the question of HTT, workloads like Cinebench typically gain very little from it, with it sometimes being worse. However, you're missing the forest for the trees, here. Adding the E-cores to the mix indisputably increases performance. Doing that at at slightly less total energy is actually very impressive! It's usually very hard to scale up performance without hurting efficiency.
Yeah it's only like 25-40% .... very little...
You are again confusing the whole CPU with only the cores that have HTT, if you have more cores that don't have htt than you have cores that do have it only then the effect of htt is very small.

Cinebench R20 results and looking at the Core i7-8700K we see a 24% reduction in performance with Hyper-Threading disabled
WinRAR sees a massive 36% reduction in throughput for the 8700K.
Corona is a high performance renderer and here the 8700K saw a 31% performance decrease with Hyper-Threading disabled,

Again, you're misreading the data. It's measuring system power, which means the poor E-cores's energy usage gets lumped together with the RAM, SSD, GPU, etc. The cores, themselves are certainly not less power-efficient than the P-cores. It's just that there's a lot of dead weight they have to drag along.
Well then give us some numbers that actually show that the e-cores are more power-efficient than the p-cores since that was what you said.
The dead weight is there when using the p-cores alone as well.
You can't use cores in a vacuum and this bench shows the efficiency of the cores with all else being the same, the dead weight drags both down the same amount.
 

PEnns

Reputable
Apr 25, 2020
703
746
5,770
The X3d parts are junk and prone to catching on fire or frying your motherboard. Check the video by gamers Nexus where this problem with X3d parts is shown to be relatively easy with overclocking
Yeah man, and they're causing solar flares and those monstrous heatwaves around the globe too!!

The only thing ctaching fire are the pants of Intel shills on Youtube and elsewhere.
 
  • Like
Reactions: bit_user

M42

Reputable
Nov 5, 2020
99
48
4,560
Here's an excerpt from the Architecture Specification, providing further insight into their plans for 512-bit support:
A “converged” version of Intel AVX10 with maximum vector lengths of 256 bits and 32-bit opmask registers will be supported across all Intel processors, while 512-bit vector registers and 64-bit opmasks will continue to be supported on some P-core processors.​
Isn't that quote from the AVX 10.1 instruction set reference?

Recent news about AVX Version 2 (AVX 10.2/512) implies 512-bit will be available to all p-cores.
 

bit_user

Titan
Ambassador
Isn't that quote from the AVX 10.1 instruction set reference?

Recent news about AVX Version 2 (AVX 10.2/512) implies 512-bit will be available to all p-cores.
AVX10.1 and AVX10.2 were announced at the same time. The statements I quoted therefore cover all of AVX10, or else they would've stipulated otherwise.

Please reread the quotes and check the source, if you require further clarification.
 

bit_user

Titan
Ambassador
Yeah it's only like 25-40% .... very little...
You are again confusing the whole CPU with only the cores that have HTT,
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:
127436.png

Compare 73.92 (8P2T + 0E) vs. 72.38 (8P1T + 0E). That's a meager 2.1% benefit.

If you want to dig into the details, you can see that it's definitely a mixed bag:
127438.png

WinRAR sees a massive 36% reduction in throughput for the 8700K.
My claim was about Cinebench and similar floating-point workloads. In the above data, you can see a 17.5% average improvement for integer workloads.

And the reason we're talking about Cinebench is that's what your data is from. So, it's no use talking about WinRAR, especially when we see that the effect of Hyperthreading is much different for such programs.

Well then give us some numbers that actually show that the e-cores are more power-efficient than the p-cores since that was what you said.
These tests seem to measure only package power, showing the E-cores do quite well for most of their frequency envelope:

The dead weight is there when using the p-cores alone as well.
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.

You can't use cores in a vacuum
Exactly. But, if you wanted to see the efficiency cores on their own, then use something like a N300.

and this bench shows the efficiency of the cores with all else being the same, the dead weight drags both down the same amount.
It doesn't, because that's not how the math works.

This graph looks at package power and core power. You can see the same effect:
gmt_power.png

The package power is about 10 W higher than the cores. When you're looking at the 8 E-cores at full load, that adds 22% overhead (54.7 W / 44.7 W). However, when looking at the P-cores, that same overhead becomes just 5.9% (178.4 W / 168.4 W).

Again, this graph just plots core power and CPU package power. If you're measuring system power, as in the data you cited, that 10 W overhead is replaced with an even bigger number.
 
Last edited:

WrongRookie

Reputable
Oct 23, 2020
670
44
4,940
"probably the last breath of air for Intel's LGA1700 platform."

Wait...what do you mean by this? That this is the last LGA1700 chipsets? What happens after that?
 

rluker5

Distinguished
Jun 23, 2014
824
531
19,760
That's rubbish. The microarchitecture of the cores didn't change between Alder Lake and Raptor Lake, whereas it did in those other examples.


Oh, there's a news flash: increased core count + bigger caches = better performance.

Again, same thing we saw when more cores were added in Coffee Lake. You could run it @ lower clocks in the same power budget and get more performance than Skylake, because adding cores is a more efficient way to scale multithreaded performance.
The 12900k has 2 more p cores and the same number of e cores. And the p cores run faster while the e cores run the same speed ( both stock).
They also have the same l2+l3 cache.
The 13600k got more l2 and had how the cores communicate change enough that the e cores don't have added latency and don't hold up the p cores. If you look at the die shots they look different because they are.
The 13600k has been improved enough that, even running at a lower speed, it surpasses the 12900k with 2less p cores and the same l2+l3 in games. Can you say the same for 10th Gen vs 6th?
Also 6th gen Skylake overclocked to 4.7-4-8 all core in reviews and 10th gen was 5.1.
Compared to jumping from 5.0-5.1 all core for the 12900k vs 5.6 all core for the 136/7/900k.

Not rubbish.
 

bit_user

Titan
Ambassador
The 12900k has 2 more p cores and the same number of e cores. And the p cores run faster while the e cores run the same speed ( both stock).
They also have the same l2+l3 cache.
The 13600k got more l2 and had how the cores communicate change enough that the e cores don't have added latency and don't hold up the p cores. If you look at the die shots they look different because they are.
Just so we're clear: I'm not the one saying Raptor Lake is a refresh. All I said was that it's not as big of a change as the other non-refresh examples you cited.

So, if you're simply trying to make the case that it wasn't simply a refresh, then we agree. If you're trying to make the case that it was a bigger change than Haswell or Zen 4 (which is what I actually said was rubbish), that's objectively and demonstrably false. If you want to go there, we can. However, I suggest you save us both time and drop that claim (if you're indeed making it).
 
Last edited:
  • Like
Reactions: rluker5

M42

Reputable
Nov 5, 2020
99
48
4,560
AVX10.1 and AVX10.2 were announced at the same time. The statements I quoted therefore cover all of AVX10, or else they would've stipulated otherwise.

Please reread the quotes and check the source, if you require further clarification.
AVX10.1 and 10.2 may have been announced simultaneously, but what you quoted was from the AVX 10.1 reference. The quote you specified indicates that AVX512 will be supported by Xeons for backward compatibility. However, AVX512 is not the same as AVX 10.2/512, which will be supported by future p-cores (not just Xeon).
 

bit_user

Titan
Ambassador
AVX10.1 and 10.2 may have been announced simultaneously, but what you quoted was from the AVX 10.1 reference. The quote you specified indicates that AVX512 will be supported by Xeons for backward compatibility. However, AVX512 is not the same as AVX 10.2/512, which will be supported by future p-cores (not just Xeon).
The introduction section, which I quoted from, discussed both 10.1 and 10.2. The discusison of the "Converged implementation" was not restricted in scope to 10.1. If you look at Table 1-3 (Feature Differences Between Intel® AVX-512 and Intel® AVX10), it even provides a 5-way comparison between AVX-512, AVX10.1/256, AVX10.2/256, AVX10.1/512, and AVX10.2/512. So, the document was clearly written with full knowledge of what's coming in AVX10.2.

If Intel were planning on enabling 512-bit on only some cores in P+E-hybrid CPUs, they would be crystal clear about that fact! The reason being that they would want software developers and their apps to be ready, which is why Intel goes to the trouble of circulating these specifications well in advance of any products reaching the market.

Instead, what we got was a very clear statement to the contrary, which I'll reiterate:
"This converged version will be supported on both P-cores and E-cores. While the converged version is limited to a maximum 256-bit vector length"

They're not going to say that, and then turn right around and contradict themselves a generation later. Especially when it would be a extremely nontrivial undertaking for apps to effectively use different vector widths on different cores. If that's what they're planning, then they would leave the door open to different vector widths, rather that taking such a clear stance.
 
Last edited:

PEnns

Reputable
Apr 25, 2020
703
746
5,770
"probably the last breath of air for Intel's LGA1700 platform."

Wait...what do you mean by this? That this is the last LGA1700 chipsets? What happens after that?

That means Intel wants you to buy a new motherboard if you want their newest CPU.

This whole new CPU charade is Intel telling users that it's not true that Intel forces users to have a new motherboard every 2-3 years.....
 

bit_user

Titan
Ambassador
That means Intel wants you to buy a new motherboard if you want their newest CPU.
For me, the big question is going to be how long LGA-1800 sticks around. Will it be just 1 generation or 2? There's no real precedent for this, since the socketed Broadwell CPUs were meant to be the second generation on that socket.

For the vast majority of users, it won't matter. It's a more relevant question/issue for OEMs and board makers, as it limits how long they have to recoup their investment on designing and validating LGA-1800 based products.
 

rluker5

Distinguished
Jun 23, 2014
824
531
19,760
Just so we're clear: I'm not the one saying Raptor Lake is a refresh. All I said was that it's not as big of a change as the other non-refresh examples you cited.

So, if you're simply trying to make the case that it wasn't simply a refresh, then we agree. If you're trying to make the case that it was a bigger change than Haswell or Zen 4 (which is what I actually said was rubbish), that's objectively and demonstrably false. If you want to go there, we can. However, I suggest you save us both time and drop that claim (if you're indeed making it).
Ok, I guess we were in agreement then. I just picked Haswell and Zen 4 as examples of not being refreshes.
Sometimes when I'm being reactive I argue a point that is not even in contention because I start making a response before I've finished reading.
 
  • Like
Reactions: bit_user
Status
Not open for further replies.