Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads

[Tigerick]

As Hot Chips 34 starting this week, Intel will unveil technical information of upcoming Meteor Lake (MTL) and Arrow Lake (ARL), new generation platform after Raptor Lake. Both MTL and ARL represent new direction which Intel will move to multiple chiplets and combine as one SoC platform.

MTL also represents new compute tile that based on Intel 4 process which is based on EUV lithography, a first from Intel. Intel expects to ship MTL mobile SoC in 2023.

ARL will come after MTL so Intel should be shipping it in 2024, that is what Intel roadmap is telling us. ARL compute tile will be manufactured by Intel 20A process, a first from Intel to use GAA transistors called RibbonFET.



Comparison of upcoming Intel's U-series CPU: Core Ultra 100U, Lunar Lake and Panther Lake

Model	Code-Name	Date	TDP	Node	Tiles	Main Tile	CPU	LP E-Core	LLC	GPU	Xe-cores
Core Ultra 100U	Meteor Lake	Q4 2023	15 - 57 W	Intel 4 + N5 + N6	4	tCPU	2P + 8E	2	12 MB	Intel Graphics	4
?	Lunar Lake	Q4 2024	17 - 30 W	N3B + N6	2	CPU + GPU & IMC	4P + 4E	0	12 MB	Arc	8
?	Panther Lake	Q1 2026 ?	?	Intel 18A + N3E	3	CPU + MC	4P + 8E	4	?	Arc	12

Comparison of die size of Each Tile of Meteor Lake, Arrow Lake, Lunar Lake and Panther Lake

	Meteor Lake	Arrow Lake (20A)	Arrow Lake (N3B)	Lunar Lake	Panther Lake
Platform	Mobile H/U Only	Desktop Only	Desktop & Mobile H&HX	Mobile U Only	Mobile H
Process Node	Intel 4	Intel 20A	TSMC N3B	TSMC N3B	Intel 18A
Date	Q4 2023	Q1 2025 ?	Desktop-Q4-2024 H&HX-Q1-2025	Q4 2024	Q1 2026 ?
Full Die	6P + 8P	6P + 8E ?	8P + 16E	4P + 4E	4P + 8E
LLC	24 MB	24 MB ?	36 MB ?	12 MB	?
tCPU	66.48
tGPU	44.45
SoC	96.77
IOE	44.45
Total	252.15

Intel Core Ultra 100 - Meteor Lake



As mentioned by Tomshardware, TSMC will manufacture the I/O, SoC, and GPU tiles. That means Intel will manufacture only the CPU and Foveros tiles. (Notably, Intel calls the I/O tile an 'I/O Expander,' hence the IOE moniker.)

 

[coercitiv]

First, Intel is probably noticing that many apps that only really rely on 8 cores, can do as well with 6 and if those 6 cores have better IPC than Raptor then it's all the better.

Second, as we move into the future applications are getting better at MT so moving some more compute to the E's makes sense.

So, to recap:

• Intel is seeing consumer apps don't scale well past 6 cores (hence lowering focus on P cores count)
• Intel is seeing consumer apps are starting to scale well with more than 6 cores (hence doubling down on E core performance instead of keeping 8 P cores)

I find it very interesting that no matter the trend of the two conflicting above, the prescribed solution is always the same: lower P core count. Entropy sucks.

 

[Geddagod]

So, to recap:

• Intel is seeing consumer apps don't scale well past 6 cores (hence lowering focus on P cores count)
• Intel is seeing consumer apps are starting to scale well with more than 6 cores (hence doubling down on E core performance instead of keeping 8 P cores)

I find it very interesting that no matter the trend of the two conflicting above, the prescribed solution is always the same: lower P core count. Entropy sucks.

Intel is seeing low-latency high ST applications that don't scale well past 6 cores (hence lowering focus on P core count)
Intel is seeing highly parallel applications that do scale well past 6 cores (hence doubling down on e-cores)
And besides, we don't even know if MTL has only 6 cores, there's a reason it's a rumor...
AND meteor lake is primarily a mobile centered architecture, and since main stream high end mobile skus start end with 6 big cores + more little cores, Intel might have just not wanted to spend more money designing an extra die with more big cores, instead of just spamming little cores, or maybe they only had space for two "cores" on the die, and went for little cores instead of big cores.
AAAND it might not even matter as much since there were also leaks of MTL only being mid range, with a quick follow up of ARL high end.

 

[poke01]

Intel is seeing low-latency high ST applications that don't scale well past 6 cores (hence lowering focus on P core count)
Intel is seeing highly parallel applications that do scale well past 6 cores (hence doubling down on e-cores)
And besides, we don't even know if MTL has only 6 cores, there's a reason it's a rumor...
AND meteor lake is primarily a mobile centered architecture, and since main stream high end mobile skus start end with 6 big cores + more little cores, Intel might have just not wanted to spend more money designing an extra die with more big cores, instead of just spamming little cores, or maybe they only had space for two "cores" on the die, and went for little cores instead of big cores.
AAAND it might not even matter as much since there were also leaks of MTL only being mid range, with a quick follow up of ARL high end.

So, to recap:

• Intel is seeing consumer apps don't scale well past 6 cores (hence lowering focus on P cores count)
• Intel is seeing consumer apps are starting to scale well with more than 6 cores (hence doubling down on E core performance instead of keeping 8 P cores)

I find it very interesting that no matter the trend of the two conflicting above, the prescribed solution is always the same: lower P core count. Entropy sucks.

It don't matter. Arrow Lake takes it back up to 8P cores. MTL is a test bench on desktop.

 

[IntelUser2000]

@Exist50 The extra clocks covering 33% lack of cores are next to impossible unless you are expecting Meteorlake to clock 6GHz+, and all core Turbo at that! They aren't using magic to get those clocks, it's still mostly getting it from using bricks as heatsinks and water cooling being common.

I suspect that the MTL-S will have 6MiB per cluster, faster internal ring bus and we could see double digit IPC boosts on those e cores.

No it doesn't. It has the same 3MB per cluster as Raptorlake mont cores do.

This feels similar to the situation with 10900K to 11900K if 6P core rumors are true for ML-S.

Well, no because MTL-S doesn't cover the high end and Arrowlake will.

Adding Hyperthreading further complicates the scheduling situation when they just got hybrid working properly. In addition to having lower performance in corner case scenarios when Es might be active, you'll have scenarios where it'll perform even worse because E's will be split into two?!

This is Intel's version of the AMD SMT4 rumor that never dies.

Remember, Atoms are pretty much Intel's version of what ARM does. None of them use SMT. Also when you start having many cores, SMT starts becoming redundant in the client space.

When I first heard of SPR my initial impression was that Intel might turn around DC with it. And in 2020 that might have worked. But Milan and Genoa show the superiority of AMD's approach and made Intel rethink theirs as well.

They might have been able to pull it off, if it wasn't for the fact that the entire server validation team was sacked. Basically they go through the process to deal with issues that the early prototypes have and run testing. These people can't be pulled off fresh out of universities - you need decades of experience for that. Also teams need to be able to work together and build cadence and have the right people on top of that and so on. So basically the whole divison had to be rebuilt I guess?

Some are calling for firing of Riviera(head of DC) that came in just few months ago, etc, etc. It's crazy! That kind of thinking is what made things fail in the first place. It's smash your head into the wall stupid. Gelsinger said the server roadmap is "what it is" until at least Emerald Rapids, and even Granite Rapids has aspects that they can't use the new improved methodology on.

 

[moinmoin]

Remember, Atoms are pretty much Intel's version of what ARM does. None of them use SMT.

There is Cortex-A65 which actually does. Seems to be a one-off so far though.

Cortex-A65 | Multithreaded CPU with High Throughput and 8 Cores

Arm Cortex-A65 is the first multithreaded Cortex-A DynamIQ CPU, offering high throughput with dual-thread processing and up to eight cores, for sensor fusion and vision-based systems.

www.arm.com

 

[Hulk]

So, to recap:

• Intel is seeing consumer apps don't scale well past 6 cores (hence lowering focus on P cores count)
• Intel is seeing consumer apps are starting to scale well with more than 6 cores (hence doubling down on E core performance instead of keeping 8 P cores)

I find it very interesting that no matter the trend of the two conflicting above, the prescribed solution is always the same: lower P core count. Entropy sucks.

No you missed the point. No conflict. Two separate cases.
There is some nuance. Perhaps I should have spelled it out better.

1. Apps that don't scale well past 6 cores, 6 stronger P's might be enough. This is becoming a smaller and smaller category as Intel sees it. These apps may not do any better with 8P's so those resources are better spent on more E's for apps that do scale well.

2. For the ever growing highly MT optimized apps the E's generate more computer per square mm.

The trend is Intel is predicting is that we are moving in to a MT software dominated landscape and as that occurs they can reduce the P count and increase the E count because as noted above the E's provide more compute per square mm.

That's just my guess on Intel's strategy.

If yours is different I'd love to hear it?

 

[igor_kavinski]

One cool thing possible with a "sea of low power cores" is executing instructions ahead of time before they are actually needed by the user and storing their results in a cache shared by both P and E cores. This way all the cores can be doing something all the time and instant results available for complex and time consuming instruction sequences for the cost of cache lookup. The P-cores would then just execute those instructions that would be completed in less time than it would take to look them up in the cache. The power consumed should be less than if it was just the P-cores burning power.

For this approach to work successfully, there would need to be tighter coupling between the P and E cores. Not like currently how the E cores seem to be tacked onto the die. A future design may involve each P core surrounded by a cluster of E cores to minimize communication latency and all of them having a common cache. It would be exciting if AMD comes up with this approach in Zen 5.

 

[poke01]

If yours is different I'd love to hear it?

Yes, mine is all you said does not make sense as Intel is going back to 8 P cores in Arrow Lake.

Your response is just idealistic to support whatever Intel does

 

[nicalandia]

No it doesn't. It has the same 3MB per cluster as Raptorlake mont cores do.

I believe you are mistaken.


A single OG Gracemont Cluster has 2MiB of Shared L2$.
An enhanced Gracemont Cluster(A.K.A Raptormont) has 4MiB shared L2$

MTL-H(The only die we have seen so far) has the next evolution of the e cores, called Crestmont(design wise they look identical TBH), the ones we have seen show to have only 3MiB per cluster, I suspect that is because it's a good compromise between energy efficiency and performance. I fully expect that MTL-S the desktop counter part will have a huge 6MiB of L2$ Per cluster and fully expect double digit IPC gains from OG Gracemont, bringing those e cores to Sunny Cove IPC performance level and leaving Skylake behind.

 

[LightningZ71]

I would like to point out that, in the most recent round of processor releases, the benchmarks clearly show that, when normalized for achievable clock speeds, the 6 core processors are within 1-2% of the performance of the 8 core processors in the majority of gaming benchmarks. It is often the case that the intel 8 core processors show a bigger difference between their 6 core and 8 core processor performance because the L3 cache increases with the extra cores for most of their parts. This is, overall, for both Intel AND AMD processors. There are a few, like the latest Spiderman game, that have a solid use case for extra threads (pre-compiled shaders on the e-cores) and the benchmarks show it, but, they are definite outliers. When you look at productivity benchmarks, it's a very similar outcome. There are, absolutely, cases where lots of available threads makes a BIG difference, especially in certain professional content creation and editing applications. The people that use those applications know who they are, and Puget does a good job of showing those cases.

A 6-P-core meteor lake that has an improved memory system and improved process for the CPU die will likely outperform 8-P-core Raptor lake processors at similar power limits in most gaming benchmarks that aren't heavily dependent on L3 cache amounts. Those extra 4 threads are rarely used, and if they are, they aren't running any of the time critical threads that heavily affect frame times. There WILL be outliers. This doesn't disprove the premise TODAY.

I am not saying this to support Intel going back to 6 P cores for meteor lake. I am saying this because it's just the facts of the matter. If 6 cores is all they can pull off right now, that's on them, but it's not going to affect games much.

 

[nicalandia]

I am not saying this to support Intel going back to 6 P cores for meteor lake. I am saying this because it's just the facts of the matter. If 6 cores is all they can pull off right now, that's on them, but it's not going to affect games much.

I can guarantee you that 6 Redwood Cove cores will outperform 8 Raptor Cove cores in gaming.

 

[S'renne]

Btw- errr is there any news on Meteor Lake to Arrow Lake for the iGPU?

 

[coercitiv]

That's just my guess on Intel's strategy.

If yours is different I'd love to hear it?

My take is Intel used the Atom cores as a crutch on the desktop after allowing AMD to dictate the narrative in the consumer space. It's a reactionary move, probably borrowing from a coherent plan on their mobile side, and therefore lacks the strategic depth people tend to assign it. Once tiles are fully embedded in Intel's consumer line, alleviating the die area problems they've been having, we'll finally get a sense of where Intel is heading with P core / E core balance for desktops.

 

[Geddagod]

My take is Intel used the Atom cores as a crutch on the desktop after allowing AMD to dictate the narrative in the consumer space. It's a reactionary move, probably borrowing from a coherent plan on their mobile side, and therefore lacks the strategic depth people tend to assign it. Once tiles are fully embedded in Intel's consumer line, alleviating the die area problems they've been having, we'll finally get a sense of where Intel is heading with P core / E core balance for desktops.

Reactionary or not, it does have a "strategic" depth of increasing MT perf/area.
Even if Intel has tiles fully working, why not have increased MT perf/area as a "cherry on top"?
Afterall, Intel would already be developing little cores regardless, at least as a competitor for future bergamo based AMD products

 

[moinmoin]

Afterall, Intel would already be developing little cores regardless, at least as a competitor for future bergamo based AMD products

If Intel wants to counter Bergamo with E cores there is a lot to catch up to though. I'd think Intel should better have spent the time to make P cores more area efficient. As is E cores are barely competitive in INT workloads, and worlds behind in FP ones.

 

[Geddagod]

If Intel wants to counter Bergamo with E cores there is a lot to catch up to though. I'd think Intel should better have spent the time to make P cores more area efficient. As is E cores are barely competitive in INT workloads, and worlds behind in FP ones.

I'm actually curious about this. As soon as I'm done with my college apps I might just do a bunch of napkin math to see how bad it really is haha, unless you know someone who already has done something similar to this?

 

[DrMrLordX]

I'd think Intel should better have spent the time to make P cores more area efficient.

It looks like we'll see some of that with Meteor Lake. Maybe.

 

[poke01]

It looks like we'll see some of that with Meteor Lake. Maybe.

More like Arrow Lake

 

[DrMrLordX]

More like Arrow Lake

Locuza's pics of Redwood Cove make it look like they're at least enjoying some improvements to area efficiency just from the process shrink. It remains to be seen how many layout improvements there are as well that contribute to the smaller silicon area for a 6+8 config.

 

[nicalandia]

Locuza's pics of Redwood Cove make it look like they're at least enjoying some improvements to area efficiency just from the process shrink.

SemiAnalysis shows a 25.17% Area reduction as a whole when compared to Golden Cove. If Redwood Cove brings 25% IPC there will be no gains in Performance/Area



Just for comparison Zen4 is 3.84 mm^2

 

[Hulk]

SemiAnalysis shows a 25.17% Area reduction as a whole when compared to Golden Cove. If Redwood Cove brings 25% IPC there will be no gains in Performance/Area

View attachment 70580

Just for comparison Zen4 is 3.84 mm^2

I'm not following? I'm missing something because based on the data you presented it seems like even if Golden/Raptor have the same IPC as Redwood then there is a 25% reduction in area for equal performance. Performance/Area gains will be even larger if Redwood has a better IPC than Golden/Raptor.

 

[poke01]

Some members here predicted that Crestmont will have a configurble cache system.

Well is that what this is?

https://twitter.com/x/status/1589808451068518403

 

[Saylick]

Some members here predicted that Crestmont will have a configurble cache system.

Well is that what this is?

https://twitter.com/x/status/1589808451068518403

Dang, we haven't seen that much L2 cache since Core 2.

 

[poke01]

Looks like Crestmont is going be actually different than Gracemont.

 

[lightisgood]

Some members here predicted that Crestmont will have a configurble cache system.

Well is that what this is?

https://twitter.com/x/status/1589808451068518403

Sierra Forest?