Rykte: Intel Ocean Cove är namnet på nästa generations processorarkitektur

Spännande Core har ju snarare evolutionerats än revolutionerats på sistonne så det är väl dags för något helt nytt kanske.

Intel Cove i5?

Jag hittar ut själv...

Intel kan inte mjölka gamla produkter längre om de ska hänga med AMD's aggressiva frammarsh. Intel har på en del plan ett försprång men inser att de måste kavla upp ärmarna då deras gamla rival är tillbaka på banan.

Saknat när teknik rivaler slåss om oss konsumenter istället för att mjölka oss 😊

Får hoppas amd släpper nått så nvidia får lite eld i baken dom med.

Skickades från m.sweclockers.com

Dagens Core må ha en blodslinje (fast kanske är kisellinje för kretsar?) tillbaka till PentiumPro, men de en PPro och Skylake har väldigt lite gemensamt...

Och varför behöver denna design ersättas? Så vitt jag känner till är det fortfarande bara Apple som har en design med bättre IPC, men den kan än så länge inte klockas i närheten lika högt.

Går det att göra en bättre x86 design än vad vi har i dag? Självklart!
Är dock rätt övertygad om att vad man än gör kommer det inte bli någon större skillnad, att Apple kunna gå förbi är väldigt mycket en konsekvens av att man kan utgå från en ISA som är långt bättre lämpad för dagens krav jämfört med x86.

Men man ska inte överdriva vikten av ISA heller, en rimlig ansats är att en "perfekt ISA" (vilket Aarch64 och även RISC-V kommer väldigt nära att var) kanske ger upp mot 20-30 % bättre IPC allt annat lika.

Vad vi så här långt utnyttjat extremt dåligt i mainstream-programvara är SIMD. Inte speciellt förvånande med tanke på att inget av de stora programmeringsspråket haft något inbyggt stöd för detta tidigare, C++17 blev först med detta. Här finns en latent potential på 2-16 gånger högre prestanda inom de områden där SIMD är användbart, det i existerande CPUer!

Fast vad skulle vinsten att starta om från början vara?

Var lite det jag försökte belysa, Zen var till stor del en "clean sheet design". Den matchar Intel i flyttal men faller efter i heltalsberäkningar (vilket är vad spel, webbläsare, de flesta server program, MS Office, kompilering, m.m. nästan uteslutande använder) och är långt efter i SIMD.

Intel hävdar att de övervägt en omstart, men när de tittar närmare på det finns det inget som pekar på att man skulle få en speciellt mycket bättre design av det.

Pekade på ARM då det trots allt finns någon där som passerat Intel i IPC (i heltal, det är överlägset viktigast då det används i alla program, flyttal är en nisch och SIMD är en något mindre nisch än flyttal men ändå en nisch). Helt övertygad att enda anledningen att Apple har ett litet övertag i flera heltalsfall långt mer kommer från att ha en mycket bättre ISA än något annat.

D.v.s Core må vara en gammal design, men den verkar vara väldigt nära perfektion för x86!

@MikaelSwahn
Så mycket text, så många förenklingar, så många fel. Jag vet inte ens vart jag ska börja.. @Yoshman , hjälp mig.

Skickades från m.sweclockers.com

Jag finner det inte omöjligt att Intel med sitt team av ingenjörer kan göra något strået vassare än det de har om de börjar om från början. Om jag får gissa lite så finner jag det inte orimligt att de identifierat en del svagheter som kräver rätt ordentlig omkonstruktion även fast jag kan för lite för att peka ut någon. Med tanke på hur begränsade resurser AMD har och att Intel högst troligen fortfarande har en signifikant fördel på tillverkningsprocessen så lyckades AMD rätt bra med Zen.

Men men, vi får se. Jag tycker bara att det verkar som att Intel tänker ta fram något som är nytt lite mer från grunden än det de brukar ta fram.

Åter igen, titta på Apple! Där har du ett företag med i praktiken obegränsade resurser, de startade från scratch med en CPU-design som på alla sätt är en "big-core" design.

För att förstå hur mycket "big-core" Apples ARM CPU är kan man titta på en av de grundläggande aspekterna: hur många instruktioner är det teoretiskt möjligt att köra per cykel (issue width). Apples CPU är är 6-wide, jämför det med AMD/Intel som "bara" är 4-wide (Intels CPUer kan "issue" 5 instruktioner per cykel om det är "rätt" mix, inte allt för osannolikt i praktiken att det händer).

Att göra en 6-wide x86 är knappast värt det i praktiken. Är få tillfällen där man kan utnyttja det och det kostar massor med transistorer i front-end att göra detta för x86, är däremot rätt enkelt på Aarch64 då alla instruktioner är lika stora (trivialt att hitta instruktionsgränserna) + avkodning av RISC är långt simplare jämfört med avkodning av x86 (finns brutalt med instruktioner och längden varierar från 1 till 15(!) bytes, det är hjärndöd design 2018).

Resultatet är ändå att Apples design är bättre sett till vissa aspekter och sämre i andra jämfört med Intels. Där Apple är snabbare är primärt de områden där man kan förvänta sig att Aarch64 ger en fördel över x86_64. D.v.s. Core-designen är en fantastiskt bra design givet förutsättningarna (hopplös ISA, minneskonsistensmodell som är allt annat än optimalt för multicore etc).

I de diskussioner som förs i forum likt detta så används "IPC" inte i sin tekniskt korrekta definition (antal maskinvaruinstruktioner som i genomsnitt körs per cykel), i stället använda "IPC" att som ett mått på hur snabbt ett givet problem kan lösas av en CPU-tråd vid en specifik CPU-frekvens.

Med den definitionen går det hur bra som helst att göra jämförelser mellan olika ISA. Skulle man verkligen titta på antalet instruktioner tiltar det hela i favör för load/store ISAs (som ARM, MIPS, etc) då det krävs fler instruktioner i genomsnitt för att lösa en viss uppgift.

Grejen är att x86 CPUer sedan många många år tillbaka delar upp x86 instruktionerna som "front-end" tuggar i sig till något som i praktiken är interna RISC (d.v.s. minnesoperationer är separerade från aritmetiska operationer). Tittar man på Zens back-end så ser den faktiskt mer ut som en modern "big-core" ARM/PPC design än en traditionell x86 back-end (gissningsvis delvis en effekt av att initiala idén var att Zen och K12 skulle dela samma back-end men ha olika front-ends, Zen för x86_64 och K12 för Aarch64).

TL;DR går hur bra som helst att jämföra om man jämför det enda som i praktiken spelar roll: hur effektiv är CPUn att lösa ett specifikt problem (är egentligen irrelevant hur många instruktioner det tar).

Och det är det fina i kråksången! Saker blir aldrig riktigt välanvända innan det är så naturligt att använda något att många inte ens inser vad som händer på maskinvarunivå.

C++17 införde std::execution::parallel_unsequenced_policy. Om du garanterar för kompilatorn att din kod uppfyller kraven för detta, vilket innefattar detta

"The execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized, vectorized, or migrated across threads (such as by a parent-stealing scheduler). The invocations of element access functions in parallel algorithms invoked with this policy are permitted to execute in an unordered fashion in unspecified threads, and unsequenced with respect to one another within each thread."

Så är det möjligt för kompilatorn att ta din helt "vanliga" sekventiella kod och köra den parallellt m.h.a. SIMD!

SIMD är mer restriktivt jämfört med MIMD ("vanligt" multicore programmering), men SIMD har den enorma fördelen i att kostnaden för att synkronisera mellan de parallella beräkningarna är i princip noll.

Som nämns i tråden är det väldigt många algoritmer som inte kan spridas över flera kärnor på ett effektivt sätt. Finns en delmängd av dessa algoritmer som ändå innehåller en hel del parallellism, men den kan i praktiken inte utnyttjas via MIMD då kostnaden för synkronisering är allt för nära vinsten med att använda flera kärnor (skalningen blir extremt låg eller till och med negativ i vissa fall). Kan SIMD används i teorin är det däremot nästan alltid möjlig även i praktiken just då kostnad för synkronisering är väldigt nära noll.

Utanför C++17 har det även de senaste åren dykt upp en annan form av "automatisk" användning av SIMD, det under namnet "auto-vectorization". Finns i både GCC, ICC och LLVM men i min mening är det bara senare versioner av LLVM där man ser någon praktiskt nytta.

Edit: kod som är SIMD kompatibel kan i teorin även köras m.h.a. av GPGPU i de flesta fall!