::: AMD Zen Samlingstråd :::

Grejen är ju bara den att visa inställningar i spel också kan påverka CPU-prestandan.
Att sänka upplösningen så lågt som möjligt och helst med övriga inställningar på max är optimalt, synd bara att inga recensenter verkar göra det.

Skickades från m.sweclockers.com

Jag trodde att jag redan påvisat våndan av att testa i 720p/low settings... När man kommer upp i mycket hög fps (som man gör i 720p/low med 1080/ti/titan) så kommer andra faktorer i systemet bli limiterande, cpu användning/belastning kan faktiskt sjunka i dessa scenarion mot att köra en vettig upplösning/inställning där du inte är gpu limiterad (1080p/high/very high). Observera att nedanstående tester gjorts på min egen burk, inte på ett ryzen system. Principen är dock exakt den samma på ett Ryzen system.

Här ser du något så enkelt som hur minnesbandbredd påverkar FPS i spel, titta framförallt på max fps mellan 1600MHz och 2133MHz, här skiljer det mer än 50fps på en bandbreddsskillnad av ~9-10GB/s. Inget annat är ändrat mellan testerna förutom minnesfrekvens. Och innan nån säger att det gäller bara detta systemet och inget annat så ta på er tänkarmössan... Observera att varken CPU eller GPU är ens lite i närheten av att agera en flaskhals i dessa tester.

PCI-E 2.0 motsvarar lite mer än halva 3.0 så 8x@2.0 är ~4x@3.0, 16x@2.0 motsvarar ~8x@3.0

Här ser man effekten av PCI-E bandbredd på hög FPS, i normal FPS (144-165) så finns det praktiskt ingen mätbar skillnad/ytterst liten skillnad, kliv över 200FPS och du ser direkt en skillnad som bara växer med antal FPS. Här så är FPS helt lössläppt vilket borde ge en GPU flaskhals eller CPU flaskhals men ingendera kommer i närheten av 99-100% belastning under detta test heller.

Igen försök komma ihåg att fantasi FPS egentligen inte säger någonting om man inte samtidigt har data på gpu och cpu belastning, annars kan det vara att man sitter och benchar skillnad på PCI-E throughput eller latency för den samma istället för CPU styrka eller minnesbandbredd/latency på internminnet.

Här ser man istället skillnad på cpu belastning per frame mellan högsta och lägsta ingame inställningarna, på det värsta stället (Geothermal Valley) skiljer det mer än 40% vilket motsvarar mer än tre logiska kärnor på aktuellt system.

Här ser ni skillnad på cpu belastning per frame vid ändrad upplösning, medelvärde skiljer som mest 1% totalt

Ytterligare en på samma fast mellan 1080p ultra wide och 4k ultra wide.

Detta spelet kan under geothermal valley och Syria testet använda precis 100% av din cpu men det kräver rätt inställningar och upplösning som inte begränsas av GPU, vilken upplösning det i slutändan blir bero på din GPU. Men att kategoriskt säga att man alltid ska testa i 720p low eller high är inget annat än hål i huvudet. Man måste såklart titta på hur systemet faktiskt belastas av varje test.

Visst kompis, fattade absolut att det kommer från din burk. Och eftersom du postade det som ett bevis för att något inte fungerar som det ska på Ryzen ligger det VÄLDIGT nära tillhands att anta att din burk har en Ryzen CPU i sig.

För om det är en Intel, vad försökte du då visa? CPU-lasten är precis vad man förväntar sig från en CPU med SMT där alla CPU-tråd schemaläggning sköts till 100 % av Windows, d.v.s. cache-topologin är helt irrelevant då applikationen inte använder den till att själv styra mappning av OS-trådar till CPU-trådar.

Verkar också som felet med cache-topologin varken låg i Windows, i CPUn eller moderkortet. Problemet verkar vara att äldre versioner av programmet Coreinfo visar information fel, uppdaterar man till senaste Coreinfo blir det rätt (står om det i "Ryzen: strictly technical" Ryzen: Strictly technical).

Så cache-topologi lär aldrig ha varit ett problem då felet låg i att Coreinfo visade information fel.

PCPerspective nämner också här (kolla 42:30-44:00 minuter in i videon) att Windows schemalägger OS-trådar precis som förväntat på Ryzen. Man lastar först varannan CPU-tråd, d.v.s. lägger jobb på ena CPU-tråden i varje fysisk kärna. Först när det inte längre finns några CPU-kärnor om är "idle" börjar man också lasta den andra CPU-tråden.

De spekulerar en del mellan 40:00-50:00 om vad som kan vara orsaken till spel-prestanda. De pekar på något i Infinity-fabric.

Jag tror det är mycket enklare: benchmarks tenderar pushar skalära flyttal som Zen är lysande på, spel (och de flesta "vanliga" program) pushar skalära heltal och dessa är är inte heller "embarrassing parallel". Zen har Haswell/Broadwell IPC för skalära flyttal, men har Sandy/Ivy Bridge IPC för skalära heltal + synkronisering mellan kärnor är dyrare i Zen än Core. Det förklara i princip alla resultat vi ser.

Så SMT-schemaläggning fungerar precis som jag hävdat är fallet hela tiden och detta är det mest optimala en OS-kärnan kan göra. Det är inte nödvändigtvis det optimala för en viss applikation, men utan att ha detaljkännedom om vad de olika OS-trådarna gör (något som en OS-kärnan inte kan veta) är detta optimalt. Linux och OSX fungerar på samma sätt.

Tänkte just på hur mycket saker hoppar runt i Windows när jag kopierade en stort git-repo mellan två maskiner. Brukar göra detta genom att köra detta

$ ssh IPADDR_OF_SRC tar czf SRC_DIR - | tar xzf -

D.v.s. via SSH kör jag tar som komprimerar innehållet och skickar ut resultatet på stdout (som då i detta fall tunnlas genom SSH) för att packas upp lokalt. På båda sidor körs i praktiken två processer, programmet som packar (vilket är flaskhals givet tillräckligt snabbt nätverk) och ssh (som kanske tar 10-15 %CPU).

Sändaren var i detta fall Ubuntu, under hela tiden låg gzip fast på CPU-tråd #1, SSH på CPU-tråd #2 och tar tog 0-1 % på CPU-tråd #0. Windows hade jämn last över alla CPU-trådar trots att det var samma konstellation av processer.

Så är detta ett problem? Svaret är med stor sannolikhet att det ändå inte är ett prestandaproblem, orsaken ligger i tidsskalan för det som kan påverkas.

Windows verkar av någon anledning göra något med fördelning av mappning av OS-trådar till CPU-trådar varje OS-tick, mitt Windows 10 har 16 ms mellan tick (Windows har tydligen normalt mellan 10-16 ms mellan OS-tick).

Tidsskalan för cache-miss vs cache-hit ligger på tiotals till i värsta fall långa hundratals nanosekunder, det är fem-sex tiopotenser ifrån!!! Så att trådar i värsta fall flyttas var 16:e millisekund är på det stora hela irrelevant för prestanda då det i värsta fall lägger på 100-tals nanosekunder på de första minnesaccesserna efter bytet.

Ett långt större problem är då att en CPU-kärna som inte är så hårt lastad lägger sig att sova, fast att komma ur C1 (billigaste sovlägen som används när CPUn relativt ofta används) tar ~1 mikrosekund. Fortfarande tre-fyra tiopotenser från tiden Windows skyfflar runt OS-trådar mellan CPU-trådar.

Det största problemet, sett till tidsskalan, är trots allt frekvensskalning: P-states. Tar tiotals till i värsta fall långa hundratals mikrosekunder att hoppa mellan olika frekvenser. Ovanpå det kan det ta minst ett tick (16 ms) innan Windows-kärnan anser att en viss CPU-kärna är tillräckligt lastad för att man ska kliva in i P0 (högsta frekvens). Just att det tar så pass lång tid för ett OS att hinna sampla den informationen är orsaken till att färre CPU-kärnor faktiskt kan ge bättre upplevelse i interaktiva program om man kör på laptops/pekplattor som är väldigt aggressiv att skala ner frekvens av strömförbrukningshänsyn.

Tanken med "Speed shift" är att flytta samplingen av CPU-last från OS till CPU, vilket då leder till att man kan reagera på millisekundnivå i stället för som bäst 10-16 ms (OS-tick upplösning).

Det som idag verkar ställa till det för Ryzen är just C-states och P-states (frekvensskalning), AMD rekommenderar att man kör med "high performance" profilen fram till att detta rättats i UEFI/Windows. Kör man i "high performance" används bara P0 så den delen av ekvationen försvinner, tror också att endast C0/C1 används (C3 och C6 spar betydligt mer ström, men i C6 tappar CPU-cachen ström så allt måste läsas från L3$/RAM vid uppvaknande).

För någon som håller på att undersöka saker kring just hur program uppför sig över kärnor och över SMT förvånar det mig inte det minsta så länge inte antal CPU-trådar är fler än vad som är möjligt.

Eller var hittar jag denna i7-4702MQ som tydligen har 2 kärnor och totalt 3 CPU-trådar (är normalt 4C/8T)?

Visa innehåll

Dold text

Det är en laptop så är inte möjligt att ändra antalet CPU-kärnor i BIOS, fast behövs inte då det är en standardfunktion i Windows att ta upp en delmängd av alla CPU-trådar. Ännu coolare är det i Linux, där kan man ta upp/ner CPU-trådar dynamiskt!

Nej.

$ ssh IPADDR_OF_SRC tar czf SRC_DIR - | tar xzf -

Men snälla du, hårdvaran jag använder står ganska tydligt i min signatur, tycker du inte det? Dessutom framgick det att jag gjort testandet på min burk. Och vad jag försöker påvisa har jag redan talat om, igen och igen och igen. Det är vid det här laget bara du som inte förstår eller rättare sagt inte vill förstå.

Helt ärligt talat, men absolut noll ironi och sarkasm. Om du postade resultat från ett Intelsystem så var det något som överhuvudtaget inte hade något med vad du faktiskt protesterade emot.

Jag skrev att det inte spelar någon roll om cache-topologin är fel, för OS-kärnan bryr sig inte om den (bryr sig bara om storleken på cache-lines). Sedan skrev jag att 99,99 % av alla applikationer bryr sig inte heller om cache-topologin.

Du postade då lite bilder på lasten över CPU-trådar när man kör Unigine Heaven Benchmark, en bild som visar att allt fungerar PRECIS som man förväntar sig.

Var i hela det om står ovan finns det någon form av logik i ditt resonemang överhuvudtaget? Åter igen, varken sarkastisk eller retorisk fråga. Det är verkligen en ärlig fråga då inget av vad du postade eller det faktum att du i slutändan verkar fått damp på mig är på något sätt rationellt sett från mitt lilla hörn av världen. Brukar inte ha svårt att förstå folk när de försöker förklara tekniska saker, inte ens när de sker på hopplös kina-engelska. Men här har det uppenbarligen blivit ett totalt missförstånd och är uppriktigt ledsen om du uppfattat det som att jag ville dryga mig, har aldrig varit mitt uppsåt.

Om du överklockar bussen på Ryzen, vilket du gör vid 3000+MHz på internminnet så kommer PCI-E falla tillbaka på 2.0 eller till och med 1.0. Då kan det vara bra att föstå att vid tillräckligt hög FPS så kommer bandbredden av just PCI-E bussen bli den limiterande faktorn, inte varken GPU, CPU eller minnesbandbredd. Att skyffla FPS kräver i alla led tillräcklig bandbredd, vid tillräckligt hög FPS så kommer även latency spela mer och mer roll i hur något presterar.

Att då många ställen testat i "i shit you not" 500fps på intel system för att testa cpu prestanda säger mer om intelligensen hos testaren än prestandan hårdvaran som testas.

Jag har på inget sätt undvikit eller varit otydlig, svamlat, haft damp eller varit irrationell , gå tillbaka och läs om, om du fortfarande inte förstår så finns det ingenting jag kan säga som kommer få dig att förstå.

OK, vi tar det ännu en gång.

Vid varje enskilt producerad frame i ett spel så kräver det av systemet en viss cpu prestanda, gpu prestanda, minnesbandbredd, throughput på olika bussar osv.

Om man då justerar ingame upplösning och inställningar till absolut minimum så kommer man sänka cpu och gpu belastning per frame radikalt, det som däremot inte sänks per frame när man gör detta är belastning på bussar, minnesbandbredds belastning kan förändras något men inte lika kraftigt som den för cpu/gpu.

Det som då händer när du ber systemet spotta ur sig fullständigt orealistiska FPS så kommer man tilta/vrida belastningen på systemet att nyttja absolut maximal tillgänglig busskapacitet/minnesbandbredd medans cpu och gpu stallar pga att det inte finns tillräcklig bussbandbredd med lägre FPS som följd jämfört med ett system som har bättre throughput. Även Latency på bussar och minne kommer bli mer och mer viktigt ju högre FPS man försöker få ur systemet

Detta test har i slutända sagt precis 0 om varken cpu eller gpu prestanda, kan det vara intressant ur perspektivet system mot system, japp men då måste man också påtala detta i sitt testande, förutom den lilla detaljen att dessa surrealistiska sceanrier inte påvisar prestanda vid normala förhållanden, alla system är noga avvägda med vad kunden i slutändan kommer ha det till. Man måste också vara oerhört noga med hur man då gjort förutsättningarna för respektive plattform, alltså minneshastighet/latency och vilka inställningar man använder. Känner du någon som aktivt sitter och game'ar vid 500 fps? Att istället kanske ha ett tak på 240fps under sitt testande kommer ge en betydligt bätre bild över hur varje system kommer prestera för normala användare, även om framtida gpu'er kommer öka prestanda så kommer dom inte kräva lika hög total throughput av systemet vid 60-240fps som dagens gpu'er gör vid 500fps, alltså vid normala förhållanden (<240fps) så har inte buss prestanda någon direkt inverkan på spelprestanda på ett modernt system, testar man däremot >240fps så kommer bussprestanda/latency få en proportionellt på tok för hög inverkan på slutlig fps.

Att man som 99% av testarna där ute gör och inte nämner ett ord om systemets prestanda utan enbart fokuserar på ren cpu prestanda trots att man de fakto inte testar cpu prestanda i slutändan blir bara fel och det hjälper absolut inte en tilltänkt köpare att ta ett informerat beslut

Edit: Jag anser att skribenter och videorecensenter har en skyldighet att peka ut mer information om just hur systemen belastas under de tester som körs, om man som testare ser att CPU och GPU belastning sjunker/ stallas av något annat i systemet så ska man tala om just detta och kanske undersöka än mer noggrant vad som orsakar flaskhalsen i detta specifika fallet, gör man detta så kommer potentiella kunder se exakt vad som skulle kunna vara en begränsande faktor i ett visst system.
Trots att Ryzen har varit ute så länge som det ändå har har vi inte den blekaste hur den presterar när det kommer till throughput/latency på PCI-E vilket är ganska förbryllande då det är en mycket viktig del av den i slutändan totala prestandan. Men då alla testare har så förbannat bråttom att få ut sina alster så fokuserar man enbart på ett par träd i skogen och ingen förstår i slutändan hur hela skogen ser ut.

Edit 2: Här har man ett praktexempel på fps vid 720p/low, när man kommer upp så här högt så kommer det garanterat finnas andra begränsningar än ren cpu prestanda. Men killen som gjort videon gör det enbart för att poängtera att inge GPU flaskhals finns och samtidigt missar att andra faktorer spelar roll.
https://youtu.be/nsDjx-tW_WQ?t=2m45s

Visst.

Har haft rätt om det mesta så här långt, men då mycket är mer eller mindre kvalificerade gissningar måste det blir fel ibland, vilket också har hänt. Hade kunna motivera svaret, men du ville ha ett ja/nej svar.

Är däremot långt mer positivt till att man kan göra saker i schedulern för att ta hänsyn till att det är två CCX som inte delar cache, något som i vissa fall spelar roll. Men det kommer handla om några procent skillnad.

Att dela upp CCX som två NUMA-noder, något som kan göras med standardfunktioner i Windows, har man ju redan testat i "Ryzen: strictly techical" tråden. Det var en dålig idé då Windows (och Linux) normalt vägrar köra en enskild process över NUMA-gräns. Så i det läget har man verkligen två fyrkärniga CPUer och inte en åttakärnig. De två CCXerna delar ju faktiskt minnesbuss så de är ju inte NUMA, i NUMA är ju även RAM separerat i flera zoner där latens och bandbredd är sämre om man går mot "fel" NUMA-zon.

Så ska man ta hänsyn till CCX måste det göras på något annat sätt, inte självklart hur det kan göras givet den information OS har om vad som faktiskt händer i processerna.

Latens mot RAM brukar ligga på ~200-300 klockcykler. Så det är på höga tiotals eller låga hundratals nanosekunder.

AIDA64 säger 59 ns här, men undrar om det inte är lite för lågt då det är svårt att få bort effekten från prefetchers. D.v.s. effektiva genomsnittslatensen kanske är ~60 ns på denna plattform, men "worst-case" som är faktiskt latens helt utan cache och prefetch hjälp lär ligga klart högre.

Latens mot L1$: 3-4 cykler (4 på högfrekvensdesigner som Zen och Core)
Latens mot L2$: 10-25 cykler (Zen och Core ligger i det nedre spannet)
Latens mot L3$: 20-50 cykler (skippar att säga något här då det tydligen inget program som korrekt kan mäta Zens latens än)

Vid en IPC på 1,5-2,5 (vilket få anses som riktvärde för "normala" desktop program med hög cache-hit rate) betyder det ändå att en total cache-miss betyder 300-700 instruktioner som skulle kunna körts. Out-of-order fönstret är "bara" ~200 instruktioner på dagens high-end x86 så inte ens teoretiskt möjligt att helt kompensera för en minnesaccess som måste gå hela vägen mot RAM, i praktiken kan det finnas andra begränsningar som gör att man inte fullt ut kan utnyttja hela out-of-order fönstret.

Grattis du lyckades missa poängen totalt, det finns inga garantier att MCE skulle vara stabilt från någon tillverkare, att det sedan är stabilt för merparten förändrar inte faktumet att ingen validerat frekvenserna/multiplarna som används av MCE. Anledningen till att just X99 skulle vara mer känsligt för instabilitet med MCE jämfört med mainstream plattformarna lär vara rätt uppenbar, 7700k skiljer det 100MHz på 4 kärnor, på 6900k skiljer det 2-300MHz på 8 kärnor, om man inte ändrar vcore vilken tror du är mest trolig att bli ostabil?

MCE är inte framtaget av intel, inte heller validerat eller testat av intel, och framförallt inte utprovat på varje enskild processor som standard specifikation/multiplar är. Detta är en överklockningsfunktion framtagen av tredje part som inte är eller följer någon standard satt av intel. Vad är det i detta som är så svårt att förstå?