::: AMD Zen Samlingstråd :::

Beställning gjord.
Gigabyte B350
R7 1700
Noctua DH15

Ska bara välja ramminne med.
Tips? 16gb

https://www.youtube.com/watch?v=40h4skxDkh4

Han i videon pratar väldigt mycket om det vi har diskuterat tidigare här och om hur viktigt det är med optimaliseringar av software/firmware. Dessutom förklarar han designen av Zen som är förståeligt och kommer också in på varför 1600x kan både floppa och bli en succe.

CCX0, CCX1 samt minneskontroller är alla klienter till Infinity Fabric. Så CCX0<->CCX1 går själv inte via RAM utan direkt.

En x86 CPU kör x86 instruktioner enligt x86 minneskonsistensmodell (som är en form som kallas Total Store Order, TSO). Finns överhuvudtaget ingen instruktion som säger "skicka detta till CCX1", det enda man kan göra är x86-operationer där en av operanderna är en minnesadress.

Vad AMD nämnt bl.a. på GDC är att varje minnesaccess som gör av en CCX resulterar i ett anrop både mot minneskontroller och mot den andra CCX:en, bandbredden dikteras då av den med lägst bandbredd (vilket är RAM) och latensen dikteras av det anrop som tar längst tid (vilket i de flesta fall lär vara RAM).

Tyvärr lär man nog göra så här på en ISA som använder TSO, känns som CCX-designen skulle passa bättre på ARM (eller PowerPC) som har en väldigt flexibel minneskonsistensmodell. PowerPC ligger i ena extremfallet med ARM tätt intill, x86 och SPARC ligger i det andra extremfallet med extremt strikta regler kring hur saker blir synliga mellan kärnor.

Som jag förstått det är resultatet för L1$, L2$ och RAM korrekt. Däremot är L3$ mätningarna fel om AIDA64 antar att kretsen har en 16 MB L3$ som täcker alla kärnor.

Varken mer eller mindre logisk än andra interconnects, som t.ex. QPI. Löser ju exakt samma problem.

Genomsnittlig latens ökar något med antal kärnor i Core. Men samma sak gäller L3$ i CCX, är inte samma latens mot de fyra L3$-delarna. Sedan mätte Legit Review latens i nanosekunder och inte det mer normala cykler, i nanosekunder kommer ju högre klockade modeller få lägre latens.

Så kan inte svara på hur latens står sig mellan CCX och en fyrkärnig Intel. S-serien (d.v.s. de "vanliga" desktop CPUer) har något lägre L3$-latens jämfört med E-serien (och vi såg att Zen har lägre latens än E-serien vid icke-slumpmässig läsning).

Men notera att när vi pratar latens i detta fall är det alltid "load-to-use", d.v.s latens för att hämta data som ligger i en viss cache-nivå, detta är latensvärdet som listas i alla tabeller då det är lägsta möjliga latens (mer om det nedan).

Menade faktiskt kärnor i båda fallen. Två kärnor som inte delar CCX har ännu högre latens.

När kärnor kommunicerar så kommer de per definition inte styras av load-to-use latensen, för att överföra någon form av information måste i alla fall ena kärnan skriva till en minnescell den andra läser. Och här divergerar Zen och Core rätt radikalt i vad som kommer hända.

Några exempel:

Skriva till en cell som inte är cachad någonstans i systemet innan

• Zen: en lokala kärnan måste reda ut om någon annan kärna har cellen cachad, så måste snoop:a både lokala kärnor och kärnor i den andra CCX (så är alltså irrelevant om den som sedan läser detta tillhör samma CCX eller ej just nu)

• Core: den lokala kärnan går till L3$, finns inte cellen där vet man ingen kärna har den cachad

Tror det går att gissa vilket som tar kortast tid

Läsa en cell som någon annan kärna skrivit till nyligen (d.v.s. data ligger i lägsta möjliga cache-nivå)

• Zen: den som ska läsa måste snoopa L2$ hos alla andra kärnor i lokal CCX (L2$ inkluderar L1$ så räcker att snoopa L2$), får man en träff är man klar och data kopieras till lokal L1$/L2$. Vid miss blir det en minnestransaktion som då skickas både till RAM och andra CCX

• Core: den lokala kärnan går till L3$, det kan vara fel data i L3$ (L1$ kanske inte propagerat data än) det ser man i så fall då status hos L3$ och står även där vilken kärna som har data (kan bara vara exakt en kärna om data ännu inte propagerat), räcker att snoopa en kärnas L1$/L2$ (man måste kolla båda då Core har "till största del icke-inkluderade" policy mellan L1$ och L2$)

Om data har propagerat till L3$ kommer core var snabbast, om data ligger i lokal CCX borde det vara hyfsat jämnt skägg men Zen kommer skicka sin snoop till alla andra kärnor i CCX, om data ligger i andra CCX blir det en rejäl latens.

Atomär uppdatering av minnescell
Något man gör vid olika former av lås mellan kärnor, ett mörker att implementera i kisel på x86 givet TSO.

TSO kräver att alla kärnor måste se alla modifikationer av minnesceller på ett sätt som är konsekvent med en enda specifik sekvens av minnesoperationer som skett en efter den andra. Detta är extremt strikt och tyvärr alldeles onödigt strikt för vad C++/Java/C# m.fl. kräver i sina modeller.

64-bitars ARM är för detta "perfekt" då de exakt implementerar det C++ kräver, varken mer eller mindre. Skulle vara väldigt intressant att se vad Intel och AMD skulle kunna åstadkomma med deras erfarenhet av högprestanda CPUer om det fick använda Aarch64 i stället för x86-64....

• Zen: startar med att skicka ett meddelande till andra lokala kärnor OCH till alla kärnor i andra CCX om att man tänker läsa en cell och den är nu låst för modifikation, går inte att komma vidare innan man fått ACK på detta p.g.a. kraven från TSO (detta kommer ta LÅNG tid). Sedan är det bara skriva och släppa reservering (det sista borde absolut kunna hända asynkront så lägger inte på mer latens)

• Core: räcker att låsa cellen i L3$, då L3$ inkluderar alla andra kärnor kommer andra kärnor som försöker läsa/skriva till samma cell då blocka på allokering av L3$-line

Borde vara smärtsamt uppenbart vilket fall som tar kortast tid, här ligger absolut en akilleshäl både med valet av icke-inkluderande cache (måste skicka meddelande till alla andra kärnor) och CCX (hälften av kärnor ligger "långt" borta).

Finns säkert något som sagt det i denna tråd. Men informationen om att det är samma latens som mot RAM kommer i praktiken från AMD själva och deras beskrivning man hade på GC kring hur man hanterar minnesoperationer.

Ryzen 7 1700 har gått om 7700k!

@erixon: Droppar denna här, väldigt bra och intressant video;

MVH

Rätta mig om jag har fel nu men det där är väl dock bara popularitet som i hur många som har klickat på R7 1700 på Prisjakt? Alltså inte hur många som faktist har köpt den, för i så fall kan det ju i själva verket se ut hur som helst.

Det är klart att folk åtminstone har kollat på Ryzens priser nu i och med releasen liksom.