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

Page 603 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Tigerick

Senior member
Apr 1, 2022
702
632
106






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

ModelCode-NameDateTDPNodeTilesMain TileCPULP E-CoreLLCGPUXe-cores
Core Ultra 100UMeteor LakeQ4 202315 - 57 WIntel 4 + N5 + N64tCPU2P + 8E212 MBIntel Graphics4
?Lunar LakeQ4 202417 - 30 WN3B + N62CPU + GPU & IMC4P + 4E012 MBArc8
?Panther LakeQ1 2026 ??Intel 18A + N3E3CPU + MC4P + 8E4?Arc12



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

Meteor LakeArrow Lake (N3B)Lunar LakePanther Lake
PlatformMobile H/U OnlyDesktop & Mobile H&HXMobile U OnlyMobile H
Process NodeIntel 4TSMC N3BTSMC N3BIntel 18A
DateQ4 2023Desktop-Q4-2024
H&HX-Q1-2025
Q4 2024Q1 2026 ?
Full Die6P + 8P8P + 16E4P + 4E4P + 8E
LLC24 MB36 MB ?12 MB?
tCPU66.48
tGPU44.45
SoC96.77
IOE44.45
Total252.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.)



 

Attachments

  • PantherLake.png
    283.5 KB · Views: 24,014
  • LNL.png
    881.8 KB · Views: 25,501
Last edited:

dullard

Elite Member
May 21, 2001
25,554
4,050
126
Reactions: igor_kavinski

AMDK11

Senior member
Jul 15, 2019
438
360
136


Got one for Skymont too?
In the case of Skymont, it is more difficult for me to recognize the structures. I found the description, but it looks like someone confused Front-end with Back-end (I think).




In ArrowLake's LionCove variant, there is a larger space between the lower half of L2 and the upper half of L2, so that the upper half of L2 extends beyond the outline of the core. The rest of the logic seems to be similar.
 
Last edited:

DavidC1

Golden Member
Dec 29, 2023
1,211
1,932
96
In ArrowLake's LionCove variant, there is a larger space between the lower half of L2 and the upper half of L2, so that the upper half of L2 extends beyond the outline of the core. The rest of the logic seems to be similar.
Of course. The L2 is larger so it needs more Tag structures. The picture isn't clear enough but usually is between them.
ARL skymont appears to have way more L2 cache than the LNL variant or the SRAM cells used are less dense
It looks similar. Explain?
 

OneEng2

Senior member
Sep 19, 2022
259
357
106
We already have accelerators. GPUs are ones, sound cards pretty much were ones. Specifically lower latency sound mixing I honestly think that ship sailed ages ago already. We had excellent hardware mixing of sound already, but then Microsoft came and instead of standardizing hardware mixing made all the driver models incompatible with the new Windows OS release. Since then cheap on board sound and software mixing had been considered good enough for like 99.99% of all use cases.
I used to have a Creative Soundblaster Platinum which had an external logic box to keep the noise level down. It was outstanding. I now use a firefly red, but honestly, A/B between the two (when I still had the Platinum) the old Platinum had better sound (using a high quality PA). So yea, I think we definitely have gone backwards there.

Still, we have P Cores, E Cores, GPU's and AI processors today. I remember reading something about cores designed to run JVM stuff ultra fast (although any interpreted language and "fast execution" should never be used in the same sentence ). I suspect that moving forward, specific hardware will be used more and more to improve performance by orders of magnitude. This will be especially true as process technology advances grind to a screeching halt and the cost of new nodes continues on its exponential curve.
Or maybe software developers will be able to specifically access certain cores in the CPU through the software for specific routines in the code.

This takes me back to the early '90's when I was using the CardD and Software Audio Workshop (SAW), written by Bob Lentini in Assembly. It was absolutely miraculous that you could multitrack record and mix with a pentium class computer. I was at Javits centers in NY way back when saw the demo of CardD and SAW. I bought them within a week, convining the band we HAD to have them. We also had a small recording studio. I used it instead of a DAT recorder to digitize final mixdown and for mastering. It was fabulous for the time and even holds up today. SAW, coded in Assembly was a few MB and ran from the exe file. It was stable, tiny, fast, and brilliant. I remember Bob had studied the Windows API for a bit and decided he couldn't do this through Windows, it was going to have to happen in Assembly and just made it happen.

Good software can be the way "around" insufficient hardware and it is the more elegant approach. We've already seen what good game drivers can do.
I have made plenty of code where you can specify core affinity in Windows. If you are careful, you can also get a time critical thread devoted to a core. I suspect that in the future, you will be able to dedicate tasks to a specific kind of core in addition to a core (if you can't already).

I have found that good C code (and even C++) will operate as quickly as assembly. In fact, in many cases (most all cases for me) the compiler will know cool tricks that you don't know about for different processors and use a more efficient binary than you can get using assembly. I actually tried this in the 90's. Once I found the compiler wrote better assembly than me (using the option to output the asm file of the C code), I never wrote another asm program again, but instead used inline assembly in C to do the low low level dirty work .

Now days, software engineers don't have the very first clue how low level instructions are created or carried out. Ask them about what a linker does, or God forbid, how to set one up for an embedded system (when the OS doesn't do all the work for you) and they are lost.

Shoot, most of them only program in Python .... which only barely ranks in my book as a real programming language, and only then because of the crazy extensive data analysis libraries it has.
Including larger Front-End, 8x wider predictor, 8-Wide decode, L1-I 64KB, UOP Cache(L0) 5250, Queue 192, ROB 576, Branch Order Buffer 180, Scheduler FP 114 and PRF ~400, Scheduler INT 97 and PRF 290, Execution units on 10 (4x FP + 6x ALU) ports instead of 5 (3x FP/ALU + 2x ALU), Non-Scheduling-Queue Buffer, L0-D 48KB, L1-D 192KB and L2 3MB. + all resource control logic.

Also, splitting the unified FP/ALU scheduler with 97 entries for 5 execution ports into a separate scheduler for 6 ALU units with 97 entries and 4 FP units with 114 entries required large resources.
I recall many a post where all of those individual elements were estimated to provide some % IPC uplift. When all of them were combined numbers like 30% were being thrown about.

Sooooo. There are really only a couple of explanations I see. 1) Intel has some awful flaw in Lion Cove architecture that needs fixing. 2) All of those core improvements are implemented horribly .... I mean really horribly.

I personally am going with #1. I think that Intel is going to seriously surprise some people with the NEXT core improvement in Lion Cove. Not sure I am buying 30% IPC, but 20% might be easily the case.
 
Reactions: moinmoin

Hulk

Diamond Member
Oct 9, 1999
4,701
2,863
136
I used to have a Creative Soundblaster Platinum which had an external logic box to keep the noise level down. It was outstanding. I now use a firefly red, but honestly, A/B between the two (when I still had the Platinum) the old Platinum had better sound (using a high quality PA). So yea, I think we definitely have gone backwards there.

Still, we have P Cores, E Cores, GPU's and AI processors today. I remember reading something about cores designed to run JVM stuff ultra fast (although any interpreted language and "fast execution" should never be used in the same sentence ). I suspect that moving forward, specific hardware will be used more and more to improve performance by orders of magnitude. This will be especially true as process technology advances grind to a screeching halt and the cost of new nodes continues on its exponential curve.

I have made plenty of code where you can specify core affinity in Windows. If you are careful, you can also get a time critical thread devoted to a core. I suspect that in the future, you will be able to dedicate tasks to a specific kind of core in addition to a core (if you can't already).

I have found that good C code (and even C++) will operate as quickly as assembly. In fact, in many cases (most all cases for me) the compiler will know cool tricks that you don't know about for different processors and use a more efficient binary than you can get using assembly. I actually tried this in the 90's. Once I found the compiler wrote better assembly than me (using the option to output the asm file of the C code), I never wrote another asm program again, but instead used inline assembly in C to do the low low level dirty work .

Now days, software engineers don't have the very first clue how low level instructions are created or carried out. Ask them about what a linker does, or God forbid, how to set one up for an embedded system (when the OS doesn't do all the work for you) and they are lost.

Shoot, most of them only program in Python .... which only barely ranks in my book as a real programming language, and only then because of the crazy extensive data analysis libraries it has.

I recall many a post where all of those individual elements were estimated to provide some % IPC uplift. When all of them were combined numbers like 30% were being thrown about.

Sooooo. There are really only a couple of explanations I see. 1) Intel has some awful flaw in Lion Cove architecture that needs fixing. 2) All of those core improvements are implemented horribly .... I mean really horribly.

I personally am going with #1. I think that Intel is going to seriously surprise some people with the NEXT core improvement in Lion Cove. Not sure I am buying 30% IPC, but 20% might be easily the case.
My only assembly programming was for my old Atari 800 when I was in high school. We could use the time during a vertical blank interupt to change a color clock or other trickery to fake more colors than were available.
 

coercitiv

Diamond Member
Jan 24, 2014
6,760
14,682
136
What stability issues are they talking about?

BSODs. Probably firmware related. Based on recent events and the fact that the 285K seems to be one affected, I would hazard to guess it's related to power delivery at high clocks.

This launch really should not have any issues like this. Unless it's limited to only a few chips or only one motherboard model, I'd rather they delay it.
 

DrMrLordX

Lifer
Apr 27, 2000
22,184
11,889
136
What stability issues are they talking about?
If you watch the MLID video, he explains that some early reviewers and leakers are indicating that the 285k in particular just . . . doesn't work. Allegedly Intel is aware of the problem and is working on a microcode fix.

edit: @coercitiv beat me to it, though I'll add (as I indicated above) that MLID claims that Intel has identified the problem as microcode-related and is gonna fix it that way. Let's see if that's how it actually works out eh.
 
sale-70-410-exam    | Exam-200-125-pdf    | we-sale-70-410-exam    | hot-sale-70-410-exam    | Latest-exam-700-603-Dumps    | Dumps-98-363-exams-date    | Certs-200-125-date    | Dumps-300-075-exams-date    | hot-sale-book-C8010-726-book    | Hot-Sale-200-310-Exam    | Exam-Description-200-310-dumps?    | hot-sale-book-200-125-book    | Latest-Updated-300-209-Exam    | Dumps-210-260-exams-date    | Download-200-125-Exam-PDF    | Exam-Description-300-101-dumps    | Certs-300-101-date    | Hot-Sale-300-075-Exam    | Latest-exam-200-125-Dumps    | Exam-Description-200-125-dumps    | Latest-Updated-300-075-Exam    | hot-sale-book-210-260-book    | Dumps-200-901-exams-date    | Certs-200-901-date    | Latest-exam-1Z0-062-Dumps    | Hot-Sale-1Z0-062-Exam    | Certs-CSSLP-date    | 100%-Pass-70-383-Exams    | Latest-JN0-360-real-exam-questions    | 100%-Pass-4A0-100-Real-Exam-Questions    | Dumps-300-135-exams-date    | Passed-200-105-Tech-Exams    | Latest-Updated-200-310-Exam    | Download-300-070-Exam-PDF    | Hot-Sale-JN0-360-Exam    | 100%-Pass-JN0-360-Exams    | 100%-Pass-JN0-360-Real-Exam-Questions    | Dumps-JN0-360-exams-date    | Exam-Description-1Z0-876-dumps    | Latest-exam-1Z0-876-Dumps    | Dumps-HPE0-Y53-exams-date    | 2017-Latest-HPE0-Y53-Exam    | 100%-Pass-HPE0-Y53-Real-Exam-Questions    | Pass-4A0-100-Exam    | Latest-4A0-100-Questions    | Dumps-98-365-exams-date    | 2017-Latest-98-365-Exam    | 100%-Pass-VCS-254-Exams    | 2017-Latest-VCS-273-Exam    | Dumps-200-355-exams-date    | 2017-Latest-300-320-Exam    | Pass-300-101-Exam    | 100%-Pass-300-115-Exams    |
http://www.portvapes.co.uk/    | http://www.portvapes.co.uk/    |