Not worse than Comet Lake in perf/w isn't a very ambitious goal.We will see about that.
Not worse than Comet Lake in perf/w isn't a very ambitious goal.We will see about that.
I dont know why, but it is only in handbrake ZEN acts in this way you describe.. In everything else i've found it to boost normally (4.5ghz+ average effective clocks with 100% usage)Yes that is true. But as you wrote they are squeezing Sunny Cove into 14nm so they could have done it 3 years ago if they had a little foresight. Even at the expense of overall clocks they would be in a better place today with a more efficient architecture even if it were at lower clocks.
They have repeated all of the bad decisions they made with the P4 all over again. Now they have to dig out of that hole. Except this time they don't have a "Core" analog in their back pocket, AMD is all over them, and Apple is in the game along with ARM. Now we'll see what Intel is really made of.
On another thought I don't know if AMD's 7nm parts can all core up to a continuous 4+GHz as reported by HWinfo's Average Effective Clock report.
Can someone with an AMD 7nm part turbo up all cores to 90%+ "Total CPU Usage" (HWinfo) for a few minutes and report "Average Effective Clock?" Also from HWinfo.
I'm starting to think the transistor density is too much at 7nm for all core sustained speeds of 4GHz as reported by HWinfo's Average Effective Clock. We've seen Comet Lake load 10 cores to 4950MHz Average Effective Clock so that's why I'm curious. Something is going on here.
Heh, and that tells you what exactly about power efficiency? Are you accusing someone of denying your opinion which is in turn is based on rumors? LOL.Aa pointed out several times, we know the base clocks, and rough IPC increase. This just reads as denial at this point.
Yeah, I know right? And yet, somehow... well... watch it happen.Not worse than Comet Lake in perf/w isn't a very ambitious goal.
Clocks, IPC, and power consumption can tell you efficiency. I shouldn't have to explain something so basic.Heh, and that tells you what exactly about power efficiency?
While your position seems to be based on literally nothing. I'll take rumors (many of which have proven to be accurate) over that.Are you accusing someone of denying your opinion which is in turn is based on rumors? LOL.
Now you're either handwaving, or citing your own denial as its own cause.There are so many red siren warning signs on this product
Yes, please explain these basic matters. Tell me how you extrapolate power efficiency from IPC. I'd love to hear it.Clocks, IPC, and power consumption can tell you efficiency. I shouldn't have to explain something so basic.
Yeah I know... so many years wasted working at Intel on CPU design and micro-architecture... not worth anything at all.While your position seems to be based on literally nothing. I'll take rumors (many of which have proven to be accurate) over that.
Well, it is not my fault you don't recognize the warning signs. I'll give you one to chew on... ever wonder what the power/perf cost would be cranking the skylake core up to 5 wide decode without the benefit of a gate delay reduction from process? Then you look at the planned frequencies on this thing... and the PL2 power numbers from the spec... doesn't take much to put that together. OK well, it might take a EE degree. Hah. But you know what, enjoy your rumors, if they make you feel better.Now you're either handwaving, or citing your own denial as its own cause.
Efficiency = perf/power = IPC * frequency / TDP.Yes, please explain these basic matters. Tell me how you extrapolate power efficiency from IPC. I'd love to hear it.
You have all the reputability of Piednoel at this point. You certainly have not written anything that demonstrates the least bit of architectural knowledge. On the other hand, you've consistently shown that your sole goal on this forum seems to be trash talking Intel. It's trolling, not technical discussion.Yeah I know... so many years wasted working at Intel on CPU design and micro-architecture... not worth anything at all.
Already taken into account. You're just ignoring the IPC benefit that provides, and thus the ability to hit the same performance at lower clocks and voltage, assuming roughly equal critical path vs CML.I'll give you one to chew on... ever wonder what the power/perf cost would be cranking the skylake core up to 5 wide decode without the benefit of a gate delay reduction from process?
Let's see... IPC moves around and is highly workload dependent, frequency moves around based on the whims of a PCU, and TDP has been rendered utterly meaningless about a decade ago. Nice try though. Pro-tip: all the variables of your "equation" on the right are intertwined. For you to claim to be able to extract efficiency as a function of any of them in isolation is pure fantasy.Efficiency = perf/power = IPC * frequency / TDP.
As I said, very basic.
Ooooof, low blow. FWIW, I did see that guy's resume... let's just say that mine is a bit less.... verbose.You have all the reputability of Piednoel at this point. You certainly have not written anything that demonstrates the least bit of architectural knowledge. On the other hand, you've consistently shown that your sole goal on this forum seems to be trash talking Intel. It's trolling, not technical discussion.
Hope you realize the critical gate depth increase is one of the hardest problems to solve when growing the width of the machine. Put it another way: your assumption is absolutely ridiculous.Already taken into account. You're just ignoring the IPC benefit that provides, and thus the ability to hit the same performance at lower clocks and voltage, assuming roughly equal critical path vs CML.
No, that isn't what they found.Lol that's not why TPU "got raked over the coals", they acknowledged themselves their results weren't accurate and were a result of what looked like a driver bug between Zen 3 and Turing.
Intel platforms do better with speed, AMD with lower CL, at least on Zen 2. This particular kit is optimized for AMD.Also, "Zen 2 friendly RAM kit"? It's a memory kit lol, there's no magic AMD favouring or Intel favouring kits.
Btw, Gamer's Nexus use DDR4-3200 for both AMD and Intel and get some of the best results for Zen 3 vs Comet Lake. So much so that an overclocked 10900K (including memory and cache OC) can't match stock Zen 3 results.
It's Sunny Cove uarch. We know how it behaves.Let's see... IPC moves around and is highly workload dependent
Intel's used base clock all-core non-AVX (high) frequency to define TDP for years now. If you claim they've changed that with Rocket Lake, you'll need to offer evidence.frequency moves around based on the whims of a PCU, and TDP has been rendered utterly meaningless about a decade ago
I literally defined efficiency. If you're just going to ignore the very definition, then you've abandoned even the pretense of honest discussion.Pro-tip: all the variables of your "equation" on the right are intertwined. For you to claim to be able to extract efficiency as a function of any of them in isolation is pure fantasy.
Except all available evidence suggests roughly equal max frequency to Comet Lake on effectively the same process. It can't have changed much.Hope you realize the critical gate depth increase is one of the hardest problems to solve when growing the width of the machine. Put it another way: your assumption is absolutely ridiculous.
Show me a link to some benchmarks. You might get a few fps, but I doubt it would be anything significant.*It is not the best performing speed for Intel. * Intel will continue to get a performance boost to 4600 and beyond.
RAM is RAM. This is nothing more than marketing. It's not like there is RGB "designed" for any certain motherboard brand.Intel platforms do better with speed, AMD with lower CL, at least on Zen 2. This particular kit is optimized for AMD. (citation needed)
![]()
Really? Do you know how it behaves when backported to a different, older process?It's Sunny Cove uarch. We know how it behaves.
That is not remotely close to how it is defined. The base clock is what the part is guaranteed to deliver with all its cores without any turbo gimmicks, and as such, due to die variation, is heavily guard-banded such that normally, running at base clock should get nowhere close to the TDP.Intel's used base clock all-core non-AVX (high) frequency to define TDP for years now. If you claim they've changed that with Rocket Lake, you'll need to offer evidence.
Yeah well, your definition is flawed to the point of being totally useless, so that is your own fault.I literally defined efficiency. If you're just going to ignore the very definition, then you've abandoned even the pretense of honest discussion.
LOL. Here’s one way you can converge a design with a higher gate depth to the same frequency: you increase the voltage. Guess what happens to power when you do that?Except all available evidence suggests roughly equal max frequency to Comet Lake on effectively the same process. It can't have changed much.
Yes yes, I am denying the veracity of your preferred rumors. Guilty as charged. Happy?Unless you insist that every rumor/leak we've seen are wrong, in which case it's as I said - denial.
Process doesn't change uarch, and IPC is solely a factor of uarch.Really? Do you know how it behaves when backported to a different, older process?
That is not remotely close to how it is defined. The base clock is what the part is guaranteed to deliver with all its cores without any turbo gimmicks, and as such, due to die variation, is heavily guard-banded such that normally, running at base clock should get nowhere close to the TDP.
Lol, post your definition then. Fairies per unicorn?Yeah well, your definition is flawed to the point of being totally useless, so that is your own fault.
They can't increase voltage. It goes up to nearly 1.4V on Comet Lake. Not even recommended for sustained overclocks. They've pushed it as far as they can.LOL. Here’s one way you can converge a design with a higher gate depth to the same frequency: you increase the voltage. Guess what happens to power when you do that?
Well then what do you think clocks and TDP will be? If you're so insistent that everyone else is wrong, put a stake in the ground.Yes yes, I am denying the veracity of your preferred rumors. Guilty as charged. Happy?
It's the timings that are set for a particular brand, for one. There are many people who have not been able to effectively use RAM setup for Intel on AMD rigs, this used to be a big issue.Show me a link to some benchmarks. You might get a few fps, but I doubt it would be anything significant.
RAM is RAM. This is nothing more than marketing. It's not like there is RGB "designed" for any certain motherboard brand.
This is interesting. Too bad we don't have more data but let's try to analyze this.I dont know why, but it is only in handbrake ZEN acts in this way you describe.. In everything else i've found it to boost normally (4.5ghz+ average effective clocks with 100% usage)
Normal boosting in IBT high, prime and cinebench etc
View attachment 36018View attachment 36019View attachment 36022
Low effective clock in handbrake
View attachment 36023
Same settings and same run on everything
Too bad for you, power efficiency is dependent on far more than just uarch.Process doesn't change uarch, and IPC is solely a factor of uarch.
No, it's Cypress Cove. It doesn't seem to behave the same per clock as Sunny Cove (nor Willow Cove), at least comparing GB5 results from IceLake-U to the few Rocket Lake-S leaks we have thus far. We need more data to fully understand what has changed. I think it's safe to say that we will not be seeing a +18% IPC uplift.It's Sunny Cove uarch. We know how it behaves.
No matter what they call it, it's a Sunny Cove backport. There may be some fudge factor in the numbers from the uncore, but by and large its measured IPC should be in line with any other Sunny Cove implementation.No, it's Cypress Cove. It doesn't seem to behave the same per clock as Sunny Cove (nor Willow Cove), at least comparing GB5 results from IceLake-U to the few Rocket Lake-S leaks we have thus far. We need more data to fully understand what has changed. I think it's safe to say that we will not be seeing a +18% IPC uplift.
It's a totally new core, backporting as whole core isn't possible. In silicon processes everything goes to one direction, you could take your old design from older process and simply shrink it to to new process with little effort, but taking new design back to older process is something totally different. And as "backporting" to old process means that they have to design new cpu arch to older process, which is just as expensive as to design new arch to new process even Intel didn't even consider that until new processes failed totally.No matter what they call it, it's a Sunny Cove backport. There may be some fudge factor in the numbers from the uncore, but by and large its measured IPC should be in line with any other Sunny Cove implementation.
This is complete nonsense. For most cores, you just take your same RTL (which includes uarch) and redo the backend work to harden it on the new process. Assuming it's not 100% synthesizable, which some are. This works the same for a shrink or a backport.It's a totally new core, backporting as whole core isn't possible. In silicon processes everything goes to one direction, you could take your old design from older process and simply shrink it to to new process with little effort, but taking new design back to older process is something totally different. And as "backporting" to old process means that they have to design new cpu arch to older process, which is just as expensive as to design new arch to new process even Intel didn't even consider that until new processes failed totally.
Rocketlake is totally desperate move from Intel. But as their Skylake-arch is clocked way over it's efficiency point new bigger cpu-arch for 14nm could be more efficient at some point at high frequency making at least some sense with some products.
Hardest part to do is critical path optimization and wire delay - if they design their uarch to given process backporting it to older process means that structures will become bigger and too slow to meet timing targets - it will work but only at much lower frequencies that it was designed originally.This is complete nonsense. For most cores, you just take your same RTL (which includes uarch) and redo the backend work to harden it on the new process. Assuming it's not 100% synthesizable, which some are. This works the same for a shrink or a backport.
There is no evidence to indicate that is the case. There is scant evidence it indicate that is not the case. Backporting is not the same as a die shrink.No matter what they call it, it's a Sunny Cove backport. There may be some fudge factor in the numbers from the uncore, but by and large its measured IPC should be in line with any other Sunny Cove implementation.
Neither of those architectures was designed for 14nm. They need both needed the increase in xtor density and power reduction to effectively replace Skylake. Rocket Lake is so late because the engineers had to figure out how to squeeze a modified *Cove architecture onto 14nm dice.
Beside some changes to make it work on 14 nm I too don't think there's any architectural difference between Sunny and Cypress Cove cores.There is no evidence to indicate that is the case. There is scant evidence it indicate that is not the case. Backporting is not the same as a die shrink.
You're basically just saying that difference processes have different performance characteristics, which is true to an extent, but does not justify repipelining or any other dramatic change. Again, it's the same with a shrink. You don't redesign for the new process; you just pocket the gains as they come.Hardest part to do is critical path optimization and wire delay - if they design their uarch to given process backporting it to older process means that structures will become bigger and too slow to meet timing targets - it will work but only at much lower frequencies that it was designed originally.