Intel introducerar Core 14000 "Meteor Lake" – energieffektivitet i fokus

Ingen IPC trots massa nytt… är detta döden för x86? Apple pressade ju fortfarande ut 10% ST på ett år…

Ska bli intressant att se tester sen.
Är inte överdrivet nöjd med min 7800X3D så det kanske blir ett byte.

Intressant att grafikdelen tillverkas hos TSMC. Antar att det betyder att Intel kommer hålla sig till TSMC för grafikkretsar framöver.

Gick inte Apple över till 3nm? Tänker att 10% då är väntat eller till och med lite lågt.

Vad jag vet tillverkar TSMC allt utom Base Die och CPU-tile. Lite osäker på om det gäller även SOC-tile, men jag tror det. Även Arc-grafikkortens kretsar är TSMC, så det är nog högst sannolikt att det fortsätter vara så framgent

Jag tyckte jag såg native stöd för HDMI 2.1 flyga förbi på en annan nyhetssida. Betyder det att vi äntligen kan kliva upp på 4k120 för/med HDR utan att behöva ett extra separat grafitkort?

Känns inte som att den nyttjar mitt 4090 helt.

Alltså, nu låg det ju lite mer i det uttalandet. Om jag inte minns fel pratades det om vilka mjukvaruförändringar som behövde göras för att få samma hastighet som en monolitisk krets. Nu pratar vi Epyc och servrar här, och det är inte alls säkert att du bara kan ta en programvara skriven för en monolitisk krets och få den att fungera bra på en chiplet-based. IOPS, trådning, resource locking osv. Det var i alla falls Intels invändningar, och jag vet inte om dom hade rätt eller fel. Inte mitt bord. Men det är inte orimligt att det behövde skrivas en del kod ett tag framöver för att få upp farten i olika programvaror. Och det kanske pågår fortfarande.

Men detta kan ha förändrats på fem år och kan se helt annorlunda ut nu, AMD har ju självklart jobbat på detta, och så även Intel. Och Intel tycker att dom och deras kunder är mogna för detta nu iallafall.

Kompilering av arm64 borde vara väsentligt enklare än x86-64 (fler register och mindre instruktioner).
Frågan är om Apple M1/M2 är lika grym på att kompilera om den skulle göra samma arbete, dvs emitta x86-64 istället?

Både GB6 (Clang) och SPECInt är ju tänkt att jämföra samma uppgift, så man bygger samma slutgiltiga binärer i dessa benchmarks. D.v.s. binärerna är identiska, de har samma instruktioner i sig.

Men just det du nämner funderade jag själv på, har benchmark:at just att bygga mot "native" på Intel, AMD och Apple. I det fallet var det inte C++, utan Rust (där kompilatorn i.o.f.s. också bygger på LLVM, så "bara" front-end som skiljer mot andra språk). Då blir fördelen ännu lite större, men är inte någon gigantisk skillnad att bygga för olika target CPUer.

Både GCC och Clang/LLVM gör ju exakt samma sak i "front-end" (det som begriper indata, d.v.s. programspråket). Båda bygger sedan till en "virtuell CPU", för att sedan ta denna virtuella maskinkod och översätta den till x86_64, ARM64, olika GPUer etc.

Är den tekniken både Apple och Microsoft utnyttjar i deras x86_64->ARM64 översättningslager. Man översätter x86_64 till LLVM-IR, när man väl har det på den formen går det att översätta till alla CPU-arkitekturer som LLVM stödjer (så tekniken är inte ARM64 specifik).

Så TL;DR är ja, faktum att fördelen är (marginellt) större om man jämför native vs native.

Det klantiga från Intels sida var att skriva något sådant i en officiell presentation.

Just hur delen visade sig ju vara tekniskt korrekt. Tyvärr, för Intels del, fixade AMD det Intel pekade på i efterföljande generation som hade I/O-die.

Intel har ju "limmat" kretsar rätt länge. Redan Pentium Pro var en MCM, deras första dual-core var två "ihoplimmade" single-core CPUer samt Intels Y/U-laptop kretsar har varit MCM >10 år.

Nackdelen med "limmade" kretsar är att det är mindre energieffektivt att ha snabb kommunikation mellan kretsar jämfört med att hålla det inne i kretsen. Men alla kommer behöva gå till chiplets framåt, så man måste göra det bästa av situationen!

Jag vet ju att du är kunnig, men här måste jag fråga. Du använder uttrycket "virtuell CPU". Är det något annat än ett parse-tree (Som man möjligen skulle kunna benämna som virtuell CPU) som används i LLVM? Det låter lite intressant...

Jag har själv skrivit några programmeringsspråk och är väl hyggligt insatt i hur det fungerar.

För LLVM kallas det LLVM-IR (LLVM Intermediate Representation). Kan se ut så här i compiler explorer (LLVM IR i mitten)

Rent krasst är nog LLVM-IR närmare ARM64 och RISC-V än x86_64, men även det är nog rätt irrelevant på det stora hela.

Tack, jag var tvungen att läsa på lite. Tydligen genererar man LLVM-IR ifrån ett parse-tree som man definierar själv. så det är ett extra steg för att få det mer generiskt.

Mycket bra, men väldigt flummigt kring vad de nya processerna kommer prestera bättre för ens applikationer.
Men det handlar väl om vilken typ av presentation som det var, det var ingen releasepresentationerna om processorerna.

Thunderbolt 5 hörde jag inte om, kanske får man vänta till nästa generation? Med Thunderbolt 5 på en laptop så behöver den stora skaran endast plugga i 2st kablar i deras laptop. (en ström och en till data) Där datautgången har bandbredd för den stora okräsna skaran så det räcker åt personens 3st skärmar, ethernet, externa ssd etc.

Jag tycker inte man ska underskatta problematiken med att plugga in och ut väldigt många kablar i ens laptop överallt.

https://wccftech.com/roundup/intel-meteor-lake-core-ultra-cpu...
Intel Meteor Lake stöder endast upp till 96 GB DDR5
När 128GB ram har funnits på laptop i många år nu.