::: AMD Zen Samlingstråd :::

...
Angående MT programmering. Alla designer gör avvägningar och kompromisser. Är fortfarande inte helt på det klara vilken marknad AMD primärt tänkt sig med Zen, i Intels fall är det uppenbart att man primärt bygger en CPU-kärna för skrivbordet som man sedan skalat upp till servers och ner till mobila enheter (gick ju sådär på sista delen, ARM är föga oväntat bättre då det är primärt fokus för dem men fungerar för Intel på bärbara datorer och upp).

De kompromisser AMD gjort i Zens cache-system gynnar problem som är "embarrassingly parallel", men hur relevanta är dessa problem på skrivbordet? Kan få spel att fungera lite bättre än idag, med största sannolikhet ja. Men men ännu större sannolikhet kommer det vara en minimal skillnad då problemet inte är något nytt. PS4/XBO har exakt samma design och det ses som ett problem av spelutvecklare, C2Q har samma problem men inget gjordes åt det för det gick inte.

Det fundamentala problemet är att saker som måste synkronisera mellan CPU-kärnor är helt beroende på tiden det tar att koordinera ägande och innehåll i en viss minnescell (den där låset ligger). Men två CCX där RAM är LLC och de sitter ihop via en, från CPU-kärnan sett, extern buss kommer se höga kostnader här.

Vidare pekar ju Hardware.fr att latens mot RAM är högre i Ryzen jämfört med de flesta andra designer vid en given uppsättning minnes-timings. Det stämmer även med de resultat som uppmäts i AIDA64 samt de som mätningar som Legit Reviews gjort.

Valen man gjort i Zen gynnar då saker som behöver mycket L3$ bandbredd. 2x 8 MB cache ger ju dubbel aggregerad bandbredd. Intel har viss skalning av bandbredd i sin ringdesign, teoretiskt ökar den perfekt med antal kärnor men tänker man på hur det rent praktiskt är implementerat så inser man rätt snabbt varför skalningar inte alls är linjär. Det är nog en orsak till varför man har flera ringar över tio kärnor.

Men valen man gjort i Zen missgynnar latens för att hålla saker koherenta. Däremot är cache-latensen för ren läsning riktigt bra (bättre än E-serien, men där är också L3$ latens väsentligt högre än S-serien). Legit Reviews visar det rätt bra, Zen fungerar precis lika bra som Intel när L1$ tar hand om det hela. Vid L2$ och L3$ har Zen faktiskt en fördel i latens om det är ett trivialt accessmönster (prefetch ligger uppenbarligen lite tidigare i pipeline för Zen). Vid slumpmässig läsning hamnar man efter för L2$ men fortfarande före vid L3$ (upp till 8 MB som är storleken för varje CCX).

D.v.s för MT program där kärnor inte kommunicerar med varandra så har Zen en bättre cache-design än Core i de flesta fall. Intel har några fördelar som att om alla kärnor ofta läser samma data måste Zen duplicera informationen per CCX medan Core bara behöver en kopia i L3$ och det är lägre latens mot RAM då det inte finns någon annan CCX som också tas med i ekvationen vid RAM-access.

De flesta på SweClockers är ändå främst intresserad av skrivbordsprogram i allmänhet och spel i synnerhet. I det läget blir kostnaden för att hålla data koherent mellan kärnor det som seglar upp + att fokus flyttas från de ofta flyttalsintensiva program som det ofta handlar om när det är trivialt att parallellisera till heltalsintensiva program.

När det kommer till att hålla data koherent mellan flera kärnor är en icke-inkluderande cache policy ett minus, att ha två CCX som i praktiken kommunicerar med latens av RAM (vilket är vad hardware.fr hävdar blir fallet och man hävdar även att man frågat AMD om man förstått rätt) så har man rejäl uppförsbacke. Framförallt när "den andra sidan" har en design där L3$ täcker alla kärnor och är inkluderande vilket betyder att L3$ även kan utnyttjas som snoop-filter (vilket också görs i praktiken).

Det är en ocean i latensskillnad mellan två Core kärnor och två Zen-kärnor som måste synkronisera något. Det gäller till viss del även två kärnor i samma CCX eftersom man vid miss i lokala cachen inte vet om den andra CCX:en har cellen cachad eller om det ska tas från RAM.

Kommer naturligtvis ner till vilket användarfall som är viktigast. Finns VÄLDIGT många fler program i det senare fallet där kärnor måste synkronisera data. Ovanpå det så är det just fallen som är triviala att parallellisera som är toppkandidater för att köras med GPGPU. @sAAb postade t.ex. detta, ingen som reagerar på de två överlägset snabbaste fallen? CUDA kanske ringer en klocka och kommentaren i artikeln som länkas är rätt talande

"Otherwise, for the most part, Blender and Premiere are happening on the GPU – though other workloads like compiles, should you work with them, would benefit from CPU acceleration."

D.v.s. har man en GPU kvittar ju CPU-delen för just det som testas här då allt går betydligt snabbare GPU-accelererat (d.v.s. lika snabbat på i7-7700K som Ryzen/E-serien till lägre pris och högre prestanda i de 99 % man INTE spenderar i final-render). Vidare är inte ens hans kommentera kring kompilering korrekt, det stämmer för "rebuilt all" men normalt gör man tiotals, kanske hundratals, inkrementella byggen per totalt ombygge. De inkrementella byggena beror till 100 % av enkeltrådprestanda.

Här tänkte lite på de kommenterar i denna tråd som hävdar hur irrelevant enkeltrådprestanda är idag under två senaste veckorna, sitter och putsar på andra personers kod och unit-tester vilket betyder massor med koda-kompilera-köra_tester. Då det är C++ med en hyfsad andel templates tar en inkrementell kompilering ~10 sekunder, otroligt irriterande tidsspann då det är för kort för att göra något annat men ändå långt nog att absolut märkas. Enda som sänker denna tid är högre enkeltrådprestanda för heltal!

Har aldrig sagt att Naples är inte bra på något. Den kommer vara ruggigt vass på saker som är rent CPU-bundna, främst skalära flyttal, där problemet behöver LÄSA väldigt stora mängder data och det hela är "embarrassingly parallel". Vi vet ännu inte om det finns något likt DDIO (en teknik som minskar trycket på RAM och minskar latens enormt på access till data som kommer via DMA, detta nästan dubblade prestanda för I/O-bundna laster när det introducerades), vi vet inte var nivån för RAS ligger (d.v.s går man upp mot E5 eller E7).

Däremot vet vi redan att Naples kommer ligga efter på de flesta HPC-laster (de är storkonsumenter av SIMD) och då ingen tråd någonsin kan se mer än 8 MB + 512 kB cache kommer den hamna på efterkälken i laster där "working-set" är större än så. Finns 4/6-kärniga Xeon E5 med 10/15 MB L3$ just för att det finns problem som aktivt jobbar på relativt stora "working-sets", i extremfallet kan ju en kärna använda hela 50 MB L3$ i en E5 2699.

Men lär ändå bli en succé för AMD och ett problem för Intel. Intel sitter i detta fall på 99 % av marknaden, så oavsett hur liten del av marknaden AMD är bästa val för betyder det en minskning för Intel.

Döp om tråden till "AMD Zens gloriferingstråd", då kommer antagligen aldrig posta mer. Nu är det trots allt så att det finns intressanta saker som diskuteras här och hoppas det finns intresse av att både se uppsidor OCH nedsidor av saker.
Tänker för övrigt inte heller skriva ett enda inlägg i en eventuell "Intel Broadwell-E är bäst" tråd heller, för borde framgå att jag må anse att 8-kärnors Ryzen är en nischprodukt men Broadwell-E är en nischprodukt av en nisch p.g.a. av sin prislapp (och när jag ändå är på basha-intel stråk, ser minimal poäng med Optane-diskarna då fördelen är latens men PCIe pajar ju alla latensfördelar, ser en poäng med 3DXpoint när den används som RAM).

Ett svar som i alla fall har med er fråga att göra är att det är svårt att pressa upp Ryzen till mer än 4.0 GHz.
Räkna med mer 100mV-150m bara för att går från 3.9 till 4.0 MHz, därefter sticker kraven på spänning exponentiellt.
Upp till 3,9 GHz är det lättare, tänker inte klocka själv, men jag skulle stanna vid 3.9.
#16703352