::: AMD Zen Samlingstråd :::

@tellus82: @yoshman

MS verkar ha bekräftat att schedulern inte riktigt tar hänsyn till Ryzens design.

https://i.redd.it/e9vdxtsb4bky.jpg

Jag är ju väldigt positiv till hur Ryzen blev, spelprestanda kom när nog för mig och jag klockar själv inte, effektförbrukningen är fantastiskt låg.
Men...
Något jag är mindre nöjd med är avsaknaden av meriter för en arbetsstation, virtualisering har varit ett starkt kort i AMD:s produkter för AM3, likaså ECC, jag hade även hoppats på stöd för reg-minnen.
Moderkorten tenderar vara bling bling, rgb i alla regnbågens färger och häftig design, mindre om komponentval, vart tog arvet efter mitt gamla Sabertooth vägen?

5 års garanti och byggt som en stridsvagn.

Lite lustigt att Bulldozer fick kritik för sin dåliga flyttalsprestanda, nu känns det nästan som att Ryzen får kritik för sin fina flytalsprestanda.

Håller med till 100 % om att kör man utanför specifikation så är det överklockning. Däremot drog du det för långt med TDP-exemplet, hela poängen med XFR är ju just att CPUn kommer gå utanför sin specificerade TDP om det är möjligt (R7 1800X drar ju 125 W under maxlast enligt SweClockers mätningar). Intel gör också detta, fast bara på sina laptop CPUer.

Det man kan fråga sig är: exakt vad är "gå utanför specifikation". Skulle säga att funktioner likt de som de flesta moderkort med Z97/Z170/Z270/X99 där man kör alla kärnor på sin Turbo 2.0 frekvens är helt att jämföra med "fabriksöverklockning" på grafikkort. Det är en gråzon då det är utanför specifikation från kretstillverkaren, men å andra sidan är det inom vad tillverkaren av moderkortet faktiskt garanterar. D.v.s. om jag köper ett moderkort från ASUS där funktionen är påslagen från start (väldigt vanligt) så har jag nu en garanti att det kommer fungera, fungerar det inte är det fel på produkten och jag ska ersättas med en ny.

Till och med mitt relativt enkla mini-ITX Z97 moderkort har ju funktion att köra alla kärnor på max turbo, fast här var funktionen inte påslagen som förval. I praktiken kommer det fungera i 100% av fallen förutsatt att man har kylare nog då detta kan få CPUn att behöva en kylare med högre kapacitet än TDP.

SweClockers är faktiskt helt konsekvent här, de kör GPU i den frekvens AMD/Nvidia specificerar och man kör CPUer utan dessa prestandahöjande moderkortsfunktioner. Däremot kan man fråga sig om det var rätt av SweClockers att även köra utan Turbo Boost 3.0 (TomsHardware körde med TB3 på och då presterar 6850K, 6900K och 6950X identiskt i Cinebench ST, vilket inte är fallet för SweC). Då jag inte har mycket till övers för E-serien var det inget jag orkade påpeka.

Och exakt vad är problemet då?

Är det detta? I så fall verkar det problemet vara relaterat till moderkort/mikrokod i CPU, inte Windows då vissa faktiskt får rätt resultat från Coreinfo. Det är inte heller ett problem för SMT då detta inte är något OSet reder ut från cache-topologin utan från en specifik CPU-tråd-till-kärnor topologi som kommer från en annan källa (är den fel går det inte att aktivera alla CPU-trådar).

De problem jag läst faktiskt finns härrör till problem med frekvensskalning och C-states (lägga en kärna i vila). Här finns saker som påverkar prestanda negativt för Ryzen, alla dessa problem går dock att komma ducka för tillfället genom att köra "performance" profilen i Windows. Detta var något som bl.a. Toms Hardware tagit upp i sitt Ryzen-test, man kör normalt alltid med "balanced" profilen. För Ryzen har man testat både "balanced" och "performance", den senare presterar något bättre i spel.

För när det kommer till Unigine Heaven Benchmark så uppvisar den helt förväntat beteende givet hur Windows idag hanterar SMT, har fortfarande inte förstått vad @tellus82 anser problemet vara. Detta program använder inte cache-topologin till låsa program trådar till specifika CPU-trådar (vilket var det enda jag pekade på innan det hela spårade ur).

Programmet är multitrådat, en tråd är klart hårdare lastad än övriga och Windows verkar av någon anledning ha en förkärlek att lägga den på CPU-tråd #0 oavsett om det är en Ryzen eller en Core. Det finns jobb nog att fullt ut lasta ungefär två kärnor, fast det på betydligt fler trådar än två. Windows försöker hålla dessa trådar på en av det två CPU-trådarna i varje kärna när det finns mer CPU-kraft än nödvändigt (vilket är en fullt rimlig policy för SMT, Linux gör på samma sätt).

Om man specifikt låser ner Unigine Heaven Benchmark till en CPU-kärna och två trådar används båda trådarna till 100 %, i det läget blir CPU-delen flaskhals i mitt system. Detta skulle vara intressant att se även på Ryzen, om det inte blir på detta sett finns det ett problem.

Om man specifikt låser ner Unigine Heaven Benchmark till två CPU-kärna och fyra trådar används två CPU-trådar till nära 100 % (en per fysisk kärna) och två används mindre men är ändå lastade. I detta läge är GPU åter igen flaskhals i mitt system, vilket visar att det programmet är inte speciellt CPU-krävande. Åter igen, skulle vilja se motsvarande köras på Ryzen för det är beteendet som är förväntat.

Fast det var väl ändå aldrig kritiken mot Bulldozer? Kritiken var väl ändå att den presterade dåligt rakt över i saker som inte jobbade med alla trådar, vissa försökte förklara detta med en delad flyttalsdelen men den förklaringen höll inte riktigt vatten då problemet även gällde program som jobbar med heltal.

Edit: går man ner för "memory lane" och tittar på hur FX-8350 presterade i t.ex. Cinebench tror jag få klagade på flyttalsprestanda när de faktiskt såg resultaten. Precis ovanför i7-2600K. Det var mer att när folk fick höra om att FPUn delades trodde man att de fått en insikt ingen annan fått: problemet måste ju vara att två trådar delar FPU!

Visa innehåll

Dold text

Vissa saker kan absolut förbättras om schedulern designas för att vara medveten om att det finns två CCX som inte delar L3$. Däremot tror jag folk har orealistiska förväntningar på hur mycket detta kan ge och verkar som väldigt få inser vilka fall som detta hjälper.

Ta fallet där man kör något som är "embarrassingly parallel" och "working-set" är så pass stort att det ofta spiller över i L3$. Kan t.ex. tänka mig att t.ex. 7-zip är ett exempel. Om Windows får för sig att flytta en tråd mellan CCX så är detta klart dåligt då de två CCX:erna har nödvändigtvis inte samma information i sin L2$/L3$, en trådflytt mellan CCX är här helt klart något man vill undvika.

Så i den här typen av applikation kan man absolut få se en viss boost om Windows scheduler patchas.

Men det kommer inte hjälpa spel eller något annat där kärnor måste kommunicera sinsemellan. Här är "problemet" (fel att kalla det problem, precis som allt annat är designen av cache en avvägning där en visst val är bättre i vissa lägen och sämre i andra) att ha en icke-inkluderande cache på en nivå (L3 i detta fall) där nivån under täcker färre kärnor (L2 är privat i Zen) gör det mer kostsamt att hålla synen av RAM koherent över alla kärnor.

Fördelen med en icke-inkluderande cache är att den effektiva storleken på cachen blir summan av L2$ och L3$, vilket är en fördel i fall som är "embarrassingly parallel" då dessa typiskt inte har någon core-to-core kommunikation att tala om (om de har det blir det i praktiken aldrig perfekt skalning och är således inte längre "embarrassingly parallel"). Finns inte heller någon nackdel i latens med icke-inkluderande policy i fall där data är relativt statiskt och läses ofta (read-mostly, rätt vanligt att en delmängd av data är väldigt mycket "read-mostly").

Så här är problemet inte direkt relaterat till att det finns två CCX, det är i grunden relaterat till valet av cache-design. Det valet gör core-to-core kommunikation, vare sig det är inom eller mellan CCX, dyrare än vad det blir med motsvarande design som har en L3$ som inkluderar alla nivåer under och täcker alla kärnor.

Informationen om att det faktiskt är så att båda anropen måste komma tillbaka verkar ju komma från AMD, så borde vara rätt. Och förklaringen i så fall tror jag åter igen ligger i x86 minneskonsistensmodell, om NÅGON kärna ser att minnescell A, B, C, D uppdateras i just den ordningen säger Total Store Order att ALLA kärnor måste se just den ordningen. Det är extremt strikt, onödigt strikt givet hur i princip alla programspråk i slutändan valde att definiera sina minnesmodeller (tänk på att C++ faktiskt inte hade en specifikation för detta innan 2011, att multicore program skrivna i C/C++ fungerade innan var egentligen utanför standarden).

Men det du inte verkar vilja ta in är detta: att undvika att lägga last på båda CPU-trådarna i en fysisk kärna är RÄTT beteende, så den graf du postade visar ju att Windows uppför sig på FÖRVÄNTAT sätt även på Ryzen.

Och ovan har överhuvudtaget inget med att cache-topologin visas på fel sätt. Faktum är att om det hade påverkat hade Windows behandlat alla CPU-trådar som fysiska kärnor. DET hade varit ett stort problem, men åter igen, grafen över CPU-last du postade visar med otrolig tydlighet att Windows föredrar att lägga jobb på var annan CPU-kärna. CPU-trådar ligger ju som AaBbCcDd|EeFfGgHh hos Ryzen så alla udda CPU-trådar ligger på samma fysiska kärna som den CPU-tråd precis innan, man räknar alltid från #0 så första CPU-tråden (A) är ett jämnt nummer och den delar fysiska kärna med nummer #1 (a).

en liten lustig klipp jag hittade på reddit.

orealistisk men lite skoj att se.

Det är inte jätte orealistiskt direkt, känner ett tjugotal folk på nätet som multiboxar MMO's på ett eller annat sätt, där kan man ha ända upp till 12 eller fler klienter igång samtidigt av ett spel som sedan kopplas ihop genom mjukvara som tar över directinput för varje & sen kör du via macron. I sådana situationer kan jag garantera att ryzen kommer prestera långt bättre än en 7700k. Nu är detta en rätt hårt nischad marknad men den finns fortfarande. Andra alternativ är såklart VM's där man kanske avdelar två kärnor till en server och på så vis slipper en extra burk för ändamålet. Det finns många användningar för extra kärnor.

Just termisk lastbalansering är ett besvärligt kapitel, kikar man på trådhoppandet så ser man efter ett tag ett mönster, kika på Prime prestanda hos Ryzen och den är apkass, mer så än den realistiskt borde vara, tittar man sedan på hur prime95 får sitt arbete utspridet så förstår man ganska snabbt att det inte är till gagn för ryzen.

En screenshot från min burk under Prime95 belastning av en tråd, första två tredjedelar i grafen är idle tillstånd, spiken anger start av prime95, kärna 1 har redan en viss belastning utöver Prime95

Här har vi typexempel på en entrådig belastning som sprids ut över alla åtta logiska kärnorna pga termisk lastbalansering, något som Ryzen absolut inte tjänar på med tanke på CCX, sen kan man fundera på varför vissa program lastbalanseras medans andra inte gör det, kika bara på min tidigare bild av Heaven benchmark där det mycket uppenbart lastas på fysiska kärnor men också primärt på kärna 1. Även på Prime95 lastas det lite mer på fysisk kärna kontra HT/SMT (0,5-1%) dito men det finns ingen fokus på en kärna, trots att det handlar om en ensam arbetstråd.

Exakt hur windows scheduler funkar vet jag inte och jag vet inte om MS själva gör det xD

@Yoshman Som jag läser dina inlägg om saken så tror du inget på att Ryzen's SMT skall kunna optimeras genom en windowsuppdatering, har jag förstått det korrekt då? (Du behöver inte skriva en lång tirad, bara ja eller nej)

Han menar att det inte kommer bli en sådan enorm förbättring som många verkar tro.

Skickades från m.sweclockers.com