::: AMD Zen Samlingstråd :::

Såg denna på ett annat forum. Summerar Ryzen hype train och alla läckta tester ganska bra

EDIT: Eventuellt är sista bilden regelbrott §1.4 och isf ber jag om ursäkt. Men tycker själv den inte faller under den regeln så låter bilden vara kvar.

Tror på det senare.

Vilken turnaround av AMD. Good read för 5 år sedan då dom var nere i källaren.

http://www.alphr.com/features/372859/amd-what-went-wrong

Om utsagan att testet hade ett working-set på 4 MB hade det jag skrev varit rätt + det faktiskt hade varit ett test som kunna ge lite vettig information då primtal med Sieve of Atkin innehåller massor med villkorade hopp som i praktiken kommer vara omöjliga att förutse för branch-predictorn.

Så hade working-set varit litet nog att få plats i cache hade resultatet bl.a. varit en indikator på kostnaden för felspekulering av hopp, en egenskap som är relevant då det inte är helt ovanligt med felspekulering (bl.a. vissa spel hamnar här, finns konsol-CPUer där man specifikt optimerat för låg kostnad vid felspekulering, ett exempel är CPU i Wii U).

Men uppenbarligen är så inte fallet, har nu laddat ner, kört CPU Mark samt mätt antal minnesreferenser och hur stor del av dessa som träffar cache. Är extremt låg cache-hit rate.

Vad man gör är inte att använda många trådar för att räkna ut alla primtal upp till 32 M (tar 4 MB att hålla reda på så många tal i Sieve of Atkin), vad man i stället gör är att köra den enkeltrådade algoritmen parallella på alla trådar. Så working-set är 4 MB * antal CPU-trådar, vilket inte får plats i någon CPU-cache förutom hos L4 i 5775C (och 5775C presterar brutalt högt i Core Mark givet dess CPU-frekvens).

Det förklarar också det andra jag inte kunde begripa: hur fick man Sieve of Atkin att skala i det närmaste linjärt från 4-kärnors modeller till 6- och 8-kärnor. Svaret är att man bara kör den enkeltrådade algoritmen över allt fler CPU-trådar, vilket ger totalt värdelös information.

Fysiktestet tittade jag inte mer på än att konstaterade att 3D Mark och CPU Mark bygger på samma programvara. I 3D Mark presterar saker ju som man kan förvänta sig, inte helt oväntat då gänget där är gamla demo-programmerare.

I 3DMarks fysiktest är cache-hit-rate väldigt hög, vilket är dels väntat för den här typen av program samt ett krav för att testet faktiskt testar CPUs kapacitet att göra den typ av beräkningar som är relevant för fysiksimuleringar.

CPU Mark not so much... Även här verkar man gjort samma sak som för primtal, man har en enkeltrådad algoritm, man duplicerar sedan det enkeltrådade fallet över alla kärnor så även här lyckas man få ett totalt "working-set" som inte alls får plats i CPU-cachen.

Så i Core Mark testar fysiktestet och primtalstestet i princip samma sak: latens mot RAM... Ju fler CPU-trådar man slänger på ett sådant problem ju högre blir resultatet då latensen är rätt konstant oavsett hur många CPU-trådar som jobbar. Varje CPU-tråd har sin IPC begränsad av tiden det tar att få in data, så skalar därför rätt linjärt.

Ah, så missförstod denna. Felet som kan göras just kring frekvens är eventuellt lite skevt då turbo-frekvenser är maxvärden. Om verklig frekvens avviker så kan den då nästan bara avvika nedåt. Vilket inte helt sant då det också finns möjligheten att färre än alla kärnor används i något läge vilket då ger högre max turbo än mitt antagande.

Oavsett, mätfelen är generellt sett väldigt låga rakt igenom, så om modellen är relevant är nog även det uträknade resultatet hyfsat nära.

Amdahl är som sagt en övre gräns, tillika en överskattning av den gränsen då antagandet är att p värdet är oberoende av antal kärnor (när det i praktiken kan påverkas svagt nedåt av ökande antal kärnor) samt man antar att den parallella delen alltid kan skalas till oändligt antal CPU-kärnor.

Om vi antar ett p värdet på 80 % så blir steget

• från 1 till 2 kärnor ger max en speedup på x1,7

• från 2 till 4 kärnor ger max en speedup på x1,5

• från 4 till 6 kärnor ger max en speedup på x1,2

• från 6 till 8 kärnor ger max en speedup på x1,1

• från 4 till 8 kärnor ger max en speedup på x1,3

Med 90 % får man

• från 1 till 2 kärnor ger max en speedup på x1,8

• från 2 till 4 kärnor ger max en speedup på x1,7

• från 4 till 6 kärnor ger max en speedup på x1,3

• från 6 till 8 kärnor ger max en speedup på x1,2

• från 4 till 8 kärnor ger max en speedup på x1,5

Detta är en rätt bra illustration varför vi stannat på två kärnor för bärbara och fyra kärnor på skrivbordet. Blir sedan snabbt väldigt mycket dimishing returns, ett p värde på 90 % eller högre existerar nästan bara för problem som är triviala att köra på massor med kärnor (typ ~90 % av alla benchmarks och ~10 % av alla desktop-program).

Logaritmen av kärnor mot speedup är betydligt mycket mer än rät linje än kärnor mot speedup, men blir allt mer fel ju närmare p kommer 1,0. Vid p=1,0 är det ju en rät linje när man plottar kärnor mot speedup, vid 0,9 är det inte i närheten att vara en rät linje.

Tar man ett problem som är trivialt att köra på många kärnor har dessa program kunnat utnyttja tusentals CPU-kärnor under väldigt lång tid.

Tar man däremot ett problem som inte är trivialt att köra på många kärnor men som har inneboende parallellism så finns en del hinder. Dels är det i alla fall dubbelt så dyrt att utveckla den typen av program så de kan dra nytta av många kärnor, många hävdar att dubbelt så dyrt är en grov underskattning.

Problemet att skala blir också exponentiellt svårare ju närmare man kommer vad som är teoretiskt möjligt. Spel verkar idag ligga på 80 % eller lägre, finns några enstaka exempel (Ashes of the Singularity) som ligger mellan 80-90 % Man lär nog lura sig själv om man tror att spel inom överskådlig tid kommer nå över 90 %, kanske inte ens är praktiskt möjligt att nå det om man så hade obegränsad FoU-budget.

Har skrivet var mitt antagande brast och har nu mätt cache-hit-rate och minnesreferenser per tidsenhet i just den benchmarken. Men Jesus, det är ett diskussionsforum och tror det finns en hel del andra inlägg här som inte mäter och testar var enda gissning de gör innan de postar.

Detta gång hade jag totalt fel. Har absolut inga problem att erkänna det, framförallt inte när orsaken är att min gissning råkar bli totalt fel då de som skrivit CoreMark överhuvudtaget inte verkar veta vad de håller på med. I princip noll "riktiga" program uppför sig på det sättet, gäller även andra benchmarks (i 3D Mark och CPU-Z testet är RAM timings helt irrelevant). Här har du ett test som tittar just på effekten av RAM-timings, ett axplock

Varför nagelfar du inte de som jämför IPC mellan Ryzen 1700X och andra modeller, då den modellen har det smått magiska XFR så vet vi faktiskt inte alls vilken frekvens den kör på. Tänk om man kyler med LN2, kanske den går på 6,0 GHz

De skattningar jag gjorde på IPC-ökning i spel var lite bättre uppbackade, de verkar också stämma på andra håll. T.ex. så får man 14 % IPC ökning mellan HSW till SLK i Eurogamers 7700K test (där man var snälla nog att köra en rad CPUer klockade till 4,5 GHz). Notera 21 % ökning från IPC i AoS. Tyvärr har vi fortfarande noll läckta resultat som säger något om hur det kommer se ut där skalära heltal är det kritiska (vilket i praktiken är det klart viktigaste, är därför CPU-tillverkare historiskt lagt enorma resurser på att "knäcka" SPECInt).

Och om du är så har så ömmande tår kring spekulation... Det sista du skriver om att det är allvarliga fel/buggar/bios? Råkar ha en laptop där latens mot räknat i nanosekunder är nästan exakt samma som DDR4 2400 CL17 (vilket Ryzen ska ha använt), min dator har DDR3 1600 CL11. Detta är resultaten från den datorn i Core Mark, notera latensmätningen!

CL11 med 1600 MT (800 MHz) ger en teoretisk latens på 11/800 = 13.8 ns
CL17 med 2400 MT (1200 MHz) ger en teoretisk latens på 17/1200 = 14.2 ns

Om resultatet i Mem Mark är en effekt av allvariga fel/buggar/bios så borde min dator uppvisa väsenligt mycket bättre resultat i latens testet hos Memory Mark, eller hur? Tja, fick 57 där vilket är rätt nära Ryzen. Får däremot rätt bra resultat i Core Mark givet att det handlar om en laptop med max turbo på 2,8 GHz när alla kärnor jobbar och 3,1 GHz single core (borde vara 3,2 men Windows visar aldrig högre än 3,1).

Visa innehåll

Dold text

Edit: resultatet ovan är alltså från en laptop med i7-4702MQ, d.v.s. fyrkärnig Haswell med 37 W TDP, specifikt en Dell XPS15.

Det är ett diskussionsforum, vissa har jobb att sköta så allt kan inte valideras till 100 % innan det postas. Att hamna totalt "in the weeds" för ett fall som totalt avviker från andra och för vad man rimligen kan förvänta sig skulle jag säga är ett rätt bra facit givet vad som generellt sett postas i en spekulationstråd.

Men peka gärna ut vilka andra teorier som varit fel. Lagarna antar jag är Amdahl, om du har bevis för att den på något sätt är fel tror jag det är en hel datorvärld som vill höra dina upptäckter!

Det är högt, men vet inte det är extremt högt då min dator får 57 ns med något bättre teoretisk latens. Som med mycket annat verkar Passmark ha problem i hur den får fram sitt resultat. I fallet minneslatens verkar resultatet man uppmäter vara väldigt icke-linjärt då folk som har CL8/9 DDR3 1600MT får uppmätt resultat som är mindre än hälften vad min laptop får, det borde vara 65-70 % av min latens.

Bandbredden ser ut att vara rätt vettig, ungefär så mycket bättre man kan förvänta sig av en CPU med dubbelt så många kärnor och DDR4 2400MT i stället för DDR3 1600MT.

Det är knappast en felaktig generalisering, de som har problem som drar nytta av så många kärnor tenderar att vara väldigt medveten om hur deras arbetslast är befattat.

Och här har jag åtskilliga gånger påpekat att antal kärnor är för majoriteten helt irrelevant efter två stycken, efter fyra stycken för gamers. Prio#1 är att ha så hög prestanda per kärna som möjligt, vid samma prestanda per kärna (inom 10-15 %) så är det absolut ingen nackdel att ha så många kärnor som möjligt.

Har specifikt pekat på att för Ryzen är ju 1800X den högst klockade så den kommer vara den bästa Ryzen CPUn för desktop. För Intel så är 7700K snabbare än hela E-serien för väldigt nära 100 % av användarna, den har helt enkelt allt för stort försprång i enkeltrådprestanda för att de andra ska komma ikapp.

Eller hävdar folk i denna tråd att de verkligen sitter och renderar (som går betydligt snabbare med en GPU) samt kodar film (som kan göras med QuickSync med utvalda modeller) hela dagarna? Vad ska man annars använda så mycket kärnor till?

Största missuppfattningen här är att "multi-tasking" skulle behöva speciellt många kärnor. OK, anta att så är fallet. Hur kommer det sig då att i3-4130 är snabbare än FX-8350 när man kör 4 st CPU-slukande applikationer samtidigt? Tänk sedan att det mer normala är att i alla fall några applikationer istället är I/O-bundna och inte CPU-bundna, i det läget är högre enkeltrådprestanda en än större fördel.

Här får nog folk bestämma sig. Å ena sidan hävdar vissa att i3 är allt för klen, trots att i3-6100 enligt Digital Foundrys klarar att driva moderna spel en bra bit över 60 FPS (många titlar når över 100 FPS).

Å andra sidan hävdar man att boosten man får med Skylake är irrelevant (vissa hävdar ju att det inte ens finns någon boost från IPC här), det är sant för oss som fortfarande sitter med 60 Hz skärmar (där duger rent krasst fortfarande Skylake i3) men sitter man på 144 Hz skärm och faktiskt kör GTX 1080 / Titan X i 1920x1080 så pekar alla resultat att 7700K > hela E-serien, även när man överklockar och kör SLI.

D.v.s. även med 10 kärnor kan inte Intels modeller kompensera för den fördel deras snabbaste 4-kärninga har i prestanda per kärna. Vad är sannolikheten att Ryzen helt magiskt skulle skala mycket bättre med antal CPU-kärnor?

Lyssna vad David Kanter i en PcPerspective video, som länkas någonstans i denna tråd, säger om för/nackdelar om de olika valen.

Intels har en fördel (hur stor den är vet vi inte än då det inte finns några vettiga läckta tester för detta) i applikationer där flera trådar måste läsa/skriva till cache-lines som även andra CPU-kärnor petat på. Det av flera skäl

• vid en L2$ miss måste en victim-cache göra mer jobb än en inkluderande cache, så latens för en miss är högre (enda latensen som listas är lägsta möjliga load-to-use vid träff)

• Zen har i tekniskt bemärkelse inte en L3$, den har en per CCX så det tillkommer latens för att hålla minnet koherent mellan CCX. Vi vet inte hur mycket detta kommer påverka, men det kommer vara högre latens än Intels L3$ då den är strikt inkluderande för alla kärnor och kan därför till 100 % användas som snoop-filter (noll snoop-trafik mot L1/L2)

• Intel har dubbelt så hög bandbredd mot varje cache-nivå, i praktiken nog mest bara relevant för nischer som HPC och vetenskapliga beräkningar

Ingenstans påstår jag mig veta magnituden av Intels fördel här, den kan absolut visa sig vara tillräckligt liten så den inte spelar någon roll i praktiken. Men vi vet inte detta idag och inget av de läckta resultaten ger oss en hint.

Och vad alla var överens om var: för normal svensson-användning i 1 Gbit/s kvittar det vilken NIC man kör. Men precis som det finns folk som har nytta av CPUer med massor med CPU-kärnor så finns det även folk som lastar sitt nätverk lite mer än normalanvändaren.

Intels 21x-serie har bättre HW-stöd för att effektivt sprida över många CPU-kärnor än någon av de andra NIC:arna som diskuterades. Enklare modeller som Realtek kan överhuvudtaget inte sprida lasten utan allt hamnar på en enda CPU-kärna. För att surfa, spela och liknande är det totalt irrelevant men även i så långsamma länkar som 1 Gbit/s kan man nå 1,4 miljoner paket per sekund och då kommer det bli svettigt även för de starkaste CPUer om inte NIC sprider lasten på ett vettigt sätt.

I 10 Gbit/s är det extremt få tillverkare som har HW-stödet för att alltid kunna maxa länken, det är här upp till 14 miljoner paket per sekund som ska hanteras.

Nu råkar jag ha jobbat väldigt mycket med detta för ett par år sedan, vi hade något form av "världsrekord" på den tiden: Vårt system klarade 5 M HTTP-trasaktioner per Xeon E5 2690 kärna med i teorin perfekt skalning per CPU-kärna (vilket inte är allt för ovanligt på servers). Vi lånande in den värsta testutrustning som gick att köpa, den kostade ett gäng hundratusentals dollar men tyvärr maxade den vid 10 M HTTP-transaktioner per sekund, fanns ju 14 kärnor till att slänga på... Ett sådant resultat var en ren effekt av att helt utnyttja precis alla funktioner i Intels NIC, det hade inte varit möjligt med något annat då existerande NIC (i alla fall inget jag känner till, idag finns andra som skulle klarar det).

För att sätta det i relation, Microsoft var förra året lyriska över att nå 1,15 M HTTP-transaktioner med .NET! Vad MS gjort är ändå rejält imponerande, vi hade något som var rätt specifik, skrivit helt i C/C++ och i princip satte hela OS:et på läktaren.

Poängen med vårt proof-of-concept var främst: visa att man kan bygga utrustning för back-bone med standard PC-komponenter + Linux, det var ett par år sedan idag gör man precis det (bygger back-bone med standard Xeons som kör Linux). Microsoft har ju lyckats ta standard .NET till en helt ny nivå, så är absolut imponerande i den kontexten (även om deras jämförelsesiffror mot NodeJS är b-ll sh-t).

Så här får får man acceptera: pratar man om ~99 % av användarbasen så är både 8 kärnor och Intel NIC totalt egalt. Men givet vilket forum vi befinner oss i gissar jag att vi diskuterar datorer ungefär som bilentusiaster diskuterar supersportbilar, d.v.s. vi diskuterar ungefär som alla behöver det absolut värsta och om vi inte har den utgångspunkten blir det hela diskussion rätt beige då vilken CPU, vilket NIC, etc som helst är fullt tillräckligt.

http://wccftech.com/amd-ryzen-5-1600x-processor-benchmark-cin...

http://wccftech.com/amd-ryzen-7-1800x-1700x-ship-march-2nd/

För att det är enkelttrådat, processorn har 12 trådar. Bara drygt 8% av processorns kraft går till att köra renderingen.

Enkeltrådat gör att i3 är ungefär jämnsnabb med i5 och i7 inom samma generation och frekvens.