Tror ni Amd kan matcha Intel i gaming med zen2?

Kan ju bara bli gissningar än så länge, min gissning är ja.
AMD ligger inte långt efter i dag och nu kommer de in på en ny nod, de verkar också ha förbättrat arkitekturen.

Okej, men jag kokar väl ner texten så att det inte blir för mycket för dig att läsa:

Om två processorer klarar av att göra det datorn är till för så är det bättre att köpa den billigare så att man kan lägga pengar på annat.

På något sätt är jag väl glad över att du är glad över att du känner att jag har rätt och jag har fel, men jag är ändå ledsen över att du på något sätt känner att du måste argumentera i termer av "titta du har fel" istället för att förklara och bemöta. Jag tror det är bra om du inte argumenterar med mig om det här, det verkar bara göra dig arg i onödan, och jag ser inte heller att det kommer leda till något vettigt.

Men jag kan faktiskt ändå säga att jag håller med om att ibland vill man ha mer än minimum som klarar uppgiften. Allt handlar om vad man prioriterar och vad man vill uppnå. Fast det blir svårt att uttrycka detta till fullo utan att det blir en "wall of text".

Hyfsat säker på att det inte är den latensen som är problem. Vore det fallet går det överhuvudtaget inte att förklara varför SKL-S (d.v.s. "vanliga" Skylake) presterar så mycket bättre i spel över SKL-X (HEDT/Xeon) som den ändå gör.

Det handlar i stället primärt om latensen när flera CPU-kärnor måste dela data, något som överhuvudtaget inte händer i program som skalar perfekt med CPU-kärnor medan det är en nödvändighet i t.ex. spel (vilket också gör det helt omöjligt för sådana program att någonsin skala perfekt med kärnor).

Ett litet exempel för att belysa skillnaden. Antag att det finns någon minnescell M som innehåller något flera CPU-kärnor måste läsa/skriva till och från.

Antag följande sekvens av händelser, initialt finns M enbart i RAM (d.v.s. inte i någon cache):

1. CPU#1 läser M

2. CPU#2 läser M

3. CPU#1 skriver M

Sekvensen ovan kommer i olika former hända varje gång något form av lås tas samt på annan delad data.

Hur hanteras detta på SKL-S, SKL-X resp. Zen?

SKL-S

Här är L1$/L2$ lokala per kärna och man använder en "mostly exclusive" policy, d.v.s. finns nästan alltid endera i L1$ eller L2$, men kan i speciella lägen finnas i båda.

L3$ är strikt inkluderade, så allt som finns i någon L1$/L2$ finns garanterat också i L3$.

1. M hämtas in, läggs i L3$ där även en notering görs om att CPU#1 kan ha en lokal kopia i L1/L2$. Data läggs sedan i L1$ och levereras

2. Här kommer man se noteringen i L3$, noteringen uppdateras med att även CPU#2 kan ha en lokal kopia. Data läses från L3$ och läggs i L1$

3. För att skriva data måste systemet säkerställa att eventuellt andra CPUers cachade värde invalideras innan skrivning, är väldigt enkelt här då data måste finnas i L3$ om någon CPU har en kopia i sin lokala L1/L2$, där finns ju även noteringen om att det räcker att invalidera eventuellt kopia hos CPU#2 (ingen annan kan ha en lokal kopia, dock kan CPU#2 redan kastat ut sin -> false positive möjlig, men spelar ingen roll och är osannolikt i praktiken).

SKL-X

Här är L1$/L2$ lokala per kärna och man använder en "mostly exclusive" policy, d.v.s. finns nästan alltid endera i L1$ eller L2$, men kan i speciella lägen finnas i båda.

L3$ är strikt exkluderande, så cachad data finns endera i L1$/L2$ eller I L3$.

1. M hämtas in, läggs direkt i L1$ och levereras

2. Redan här blir det problem, CPU#2 måste ställa en fråga om någon annan kärna har M cachad. Har ingen koll exakt hur det protokollet ser ut för SKL-X, men på något sätt kommer CPU#1 svara. Båda kärnorna kommer nu ha M i delat läge (read-only läge)

3. CPU#1 ser att M är i delat (read-only) läge. Den kan inte dra någon annan säker slutsats än att egentligen vilken kärna som helst kan ha M i sin lokala cache. Däremot vet den att data inte finns i L3$. Ändå en klart dyrare (högre latens) operation jämfört med SKL-S!!

Zen

Dokumentationen pekar på att L2$ är strikt inkluderande av L1$

L3$ är strikt exkluderande av L2$.

1. M hämtas in, läggs direkt i L2$ samt L1$ och levereras

2. Här skulle man kunna tänka sig att det blir identiskt med SKL-X, vilket är fallet fast med en liten twist. Zen har tydligen reserverat utrymme i L3$ för en lista likt den SKL-S har om vilka kärnor som kan ha en lokal kopia av M. Nackdel i detta läge då övergången från "data är exklusivt för mig" till "delar data med minst en annan kärna" har högre latens.

3. CPU#1 ser att M är i delat (read-only) läge. Här har däremot Zen en klar fördel mot SKL-X, CPU#1 ser direkt i sin CCX lokala L3$ vilken/vilka andra kärnor som kan tänkas ha en lokal kopia. Om den/de andra kärnorna ligger på ett annat CCX tar invalidiseringen lite extra tid, annars är det helt likvärdigt med SKL-S

Läser man ovan kan man ställa sig frågan: varför skulle någon välja exkluderade policy på delad cache? Det har ju högre latens!

Helt sant, inkluderande L3$ är optimalt i fall som t.ex. spel där flera CPU-kärnor kommer dela data.

Den uppenbara fördelen med en exkluderande cache är när förväntat last INTE delar data, t.ex. när man kör virtuella maskiner på en server och många andra server-laster. Här ger exkluderande policy en fördel då effektiv storlek på cachen är summan av L3$ och storleken på de aktiva kärnornas lokala cache.

Så för att svara på trådens fråga: nej tror inte man kommer matcha spelprestanda med Zen2 (förutsatt att det som avses är fall där GPU inte är flaskhals).

Zen är primärt en server-design, men man har ändå gjort en del desktop-specifika optimeringar. Så den är lite mitt emellan SKL-S och SKL-X ur optimeringssynpunkt. SKL-X tycker jag illustrerar rätt bra hur viktig cache-designen är, det är exakt samma mikroarkitektur som SKL-S + dubbelt så många minneskanaler. Ändå är SKL-S klart bättre i spel, även i5-modellerna är normalt snabbare trots lägre frekvenser jämfört med t.ex. i9-7900X.

Håller helt med det som skrivs om ARM här

Vill man se bättre prestanda på desktop framöver ska man överge Intel/AMD frågorna, i alla fall så länge som det betyder x86.

64-bitars ARM är, till skillnad från x86, PPC, MIPS m.fl, inte en utökning av 32-bitars ARM. 32-bitars ARM har på det stora hela lika mycket gammalt skräm i bagaget som x86, det finns många fundamentala problem att designa en 32-bitars ARM CPU med riktig hög IPC.

Så sett till instruktionsuppsättning har egentligen 64-bitars ARM lika mycket gemensamt med 32-bitars ARM som x86 har med, säg, MIPS. Vidare ska man vara införstådd med att specifikationen för 64-bitars ARM lanserades 2011, d.v.s. bara för sju år sedan.

Har pratat med flera forskare inom CPU-design. Är ett par år nu men de var alla rätt samstämmiga kring att vi redan då rätt mycket nått den IPC man rimligen kunde förvänta sig. Simuleringar med x86 visar att IPC, i det generella fall, faktiskt inte kan så mycket högre. Finns helt enkelt inbyggda serialiseringsproblem i en ström av x86 instruktioner!

Av allt att döma gäller liknade begränsningar för 32-bitars ARM, PPC/POWER och SPARC (är väl de man designat riktigt "big-core" varianter av).

Apple har med brutal tydlighet visat att denna gräns inte är en absolut sanning. Vortex, "big-core" CPU i Apples A12 systemkrets, uppvisar ett genomsnittlig IPC övertag på Skylake på ~50 %, det både enligt AnandTechs mätningar och även om man tittar på Geekbench 4 resultaten.

Är extremt imponerad av SpecINT2006 resultatet där IPC för Vortex i kompileringstestet ligger på runt 2x jämfört med Skylake. Kompilering har dels rätt mycket gemensamt med spellogik faktiskt, dels är det ett av de få SpecINT testerna man anser det inte går att "fuska" i genom att skriva kompilatorer som gör optimeringar som bara fungerar i Spec men ingen annanstans.

Tyvärr är x86 rätt hårt rotat i WIndows, det kommer ta rätt lång tid innan Windows för ARM (det lanserades ett "riktigt" Win10 för ARM i våras) blir något att räkna med. Själv hoppas jag på att någon av konsolerna blir utrustad med en high-end ARM64 kommande generation, är det bara en som går den vägen är jag övertygad det kommer bli en klar fördel. Vi skulle då lätt kunna hamna i situationen att den konsolen faktiskt är CPU-starkare än samtida gaming PC!

Edit: förtydligande kring relevansen "bara för sju år sedan". Tar tid att utveckla kompilatorer, optimera bibliotek/OS kärnor och liknande för en helt ny CPU-arkitektur. Att det bara sju år efter specifikationen lanserades finns implementationer som utför mer jobb per cykel (Vortex) eller i alla fall matchar de mest putsade x86 designerna (Samsungs M3 och av allt att döma kommande ARM Cortex A76) pekar på att 64-bitars ARM är en "perfekt" design för dagens krav och att denna perfektion har praktiskt relevans.

Att utveckling av kompilatorer gått så här fort får man nog tacka Apples och deras monstruösa kassakista för, Apple satsar enorma resurser i ett projekt som kallas LLVM. Den goda nyheten är att LLVM har varit, är och ser av att all döma ut att fortsätta vara ett öppet projekt som gynnar en väldigt bred skara användare (vi kör LLVM på både x86 och ARM på jobbet, riktigt trevligt projekt som man är glad över att få jobba både med och till och från även i).

Det är bara "totalt ointressant" om man anser att alla förklaringen till frågan TS ställer som kräver mer än ett led i tankeprocessen är värdelösa.

Visst, hade gått att skriva ett kortare inlägg men gissar att de flesta inte har örnkoll på vad som händer utanför x86. Är ju uppenbart när man läser trådarna att de flesta har rätt dålig koll ens på x86 när det kommer till saker som IPC (annars skulle vi inte konstant se "skiljer bara någon procent i IPC mellan Zen och Skylake").

Så hur var ARM inlägget relevant för vad som frågas i tråden?

Enda sättet Zen2 kan matcha Intel i gaming är att de matchar Intels IPC, i alla fall om vi förutsätter att Zen2 knappast lär klocka högre än i7-9700K/i9-9900k.

I det läget är det högst relevant att peka på att Intel står och stampar på rätt mycket samma IPC-fläck år efter år. Är heller ingen slump att Zen ungefär matchar Skylake när det kommer till IPC för traditionella flyttal (vilket vi ser i t.ex. Cinebench) samt ligger i runda slängar runt 20 % efter för heltalsberäkningar (vilket är det som är kritiskt för de flesta applikationer, inklusive spel).

Zen ligger någonstans mellan Ivy Bridge och Haswell när det kommer till IPC i heltalsberäkningar, så man riktigt nära då Intel faktiskt bara fått ut en mikroarkitektur efter Haswell (Broadwell är i praktiken Haswell på 14 nm).

Så varför ser vi detta mönster? Är här ARM-inlägget är relevant. Vi ser detta för simuleringar av fiktiva x86 designer där man i princip tillåter obegränsad mängd dynamisk analys av instruktionerna pekar på att Intels Core-serie är väldigt nära IPC-gränsen för x86.

Både Intel och AMD jobbar mot att asymptotiskt gå mot en hård IPC-gräns (för generellt heltal, för specialfall finns det ännu rejält med IPC, något vi ser i AVX-512 och t.ex. machine-learning).

Nu skrev jag inte det, men tittar man på "back-end" i Zen så delar den väldigt mycket design-element just med Samsungs M3 och ARMs Cortex A76, Apples tidigare ARM-designer ser än mer lik ut.

Gissningsvis inte en total slump då Jim Keller hade jobbat med de tidiga Apple-designade ARM:arna innan han kom till AMD. Vidare var ursprungsplanen att mikroarkitekturen för Zen skulle dels lanseras för x86 (vilket är just Zen) men även för ARM (K12).

tl;dr varianten på detta är: osannolikt att Zen2 går förbi Skylake (och senare på året ska den ju konkurrera med Ice Lake) då x86 börjar gå mot sin IPC gräns för heltalsberäkningar. Kikar man just på 64-bitars ARM ser man att det inte är en absolut gräns, motsvarande mikroarkitektur fast med ARM64 front-end går förbi även Intels IPC.

D.v.s. ARM64 ger en teknisk bakgrund till varför svaret på TS fråga är "nej". Framförallt kombinerat med saker som skillnader i cache-design samt skillnader i policy för instruktions-schemaläggaren (Zen har en distribuerad sådan, Core har en central, den senare är mer komplicerad men ger högre IPC givet motsvarande back-end kapacitet).