::: AMD Zen Samlingstråd :::

En sak som Ryzen ägare skulle kunna prova för att se hur det påverkar prestanda är att justera context switching clock ticks, normalt ligger denna på 2 i klient OS, på server ligger den normalt på 12 men det är inte jättelätt att få fram exakta siffror från MS på detta. Dock kan man ändra från lägst klock ticks till högst tillåtna genom att ändra:
"schemaläggning av processor" under Prestandaalternativ som finns under systemegenskaper. Normalt står denna på Program i win10 klient & på server står den på bakgrundstjänster, skillnaden ligger främst här i hur många klock ticks en tråd hålls kvar innan nästa släpps fram (förutsatt att bägge har samma prio), detta är inte bara bra åt ena eller andra hållet men det skulle vara lite intressant att se om det har någon inverkan på just ryzen när trådar hålls kvar längre vid liv innan nästa väntande tråd får tillträde, detta i sin tur skulle rent teoretiskt kunna sänka trådhoppandet en smula. Av naturliga skäl har det såklart en del negativa effekter också men det vore intressant ur ett rent teoretiskt perspektiv.

Edit: Man kan relativt enkelt prova genom att köra wPrime & en arbetstråd, ett scenario där du får konstant trådhoppande, på min intel burk gav det en negativ prestandaskalning med -0,3% att köra bakgrundstjänster på just wPrime med 1 tråd jämfört med "program". Det borde vara något liknande på de flesta burkar & skulle vara skoj ifall någon kunde prova på en Ryzen setup. Bara och köra ett par rundor & slå ut ett medel, ändra schemaläggarn & köra ett par igen & ta medel.

Intressant, de utvecklar lite:

Här verkar Anandtech ge Ryan Shrout (PCPer) rätt, det är inte ett problem med schemaläggaren. Jag har inte koll på exakt vad de menar med "static partitioning". Jag antar att en del resurser inte delas, och att det får effekt när SMT slås av? Som sagt, inte koll.

Ja, är man inte "inne" i tråden så ser man lätt att användare med obekväma åsikter inte är välkomna.

Min maskin måste sakna en hel del MS-saker som du har på din. Vad har du för miljö för att få den att fungera på Ubuntu; jag kör standard Debian 64-bit.

Huvudsakliga problemet med just CCX och dess påverkan på latens uppenbarar sig oftast vid lätt flertrådade applikationer, alltså fall där windows gärna sprider ut arbetet över fler logiska kärnor än vad som egentligen behövs (bekräftat av praktiskt taget alla inblandade parter inklusive pcper i videon) och vid extremt tungt flertrådade applikationer så är trådhoppandet näst intill obefintligt då alla kärnor redan har jobb och då blir effekten av just CCX latensen nästan obefintlig (förutom fall där det krävs konstant och överdriven kommunikation mellan trådar). Ett spel som exempelvis använder fyra arbetstrådar har inte mycket anledning att spridas ut över 16 logiska processorer annat än ett försök till energibesparing eller värmespridning. Om man då kan ändra hur detta hanteras dels i schemaläggaren men också av programmen som gör undantag från de normala spelreglerna som schemaläggarn har så är det väl höga odds att det skulle förbättra prestandan på Ryzen, just exakt hur mycket blir extremt applikationsspecifikt.
Battlefield 1 som exempel är väldigt flertrådat i sitt arbete jämfört med andra spel, ett som däremot inte är det vid låga inställningar är Tomb Raider, det är istället väldigt lätt flertrådat. Som av en ren händelse råkar detta stämma rätt bra överens med de prestandaskillnader som visas upp.

För att bygga på Ubuntu: tillräckligt ny C++ (använder C++11) samt GNU-make
Sedan ska detta räcka, antag att filen heter th_ping.cpp

make CXXFLAGS="-std=c++11 -O2 -pthread" th_ping

Behövs inga makefiler, GNU-make har implicita regler och dessa är fullt tillräckliga för detta program.

Detta är vad som borde hända på ubuntu 16.04

kenneth@skylake:~/th_ping$ make CXXFLAGS="-std=c++11 -O2 -pthread" th_ping
g++ -std=c++11 -O2 -pthread    th_ping.cpp   -o th_ping

Nu ska det finnas en körbar fil med namnet "th_ping"

Edit: verkar även fungera på RPi3.

kenneth@rpi3:~/programming/c++/th_ping $ make CXXFLAGS="-std=c++11 -O2 -pthread" th_ping
g++ -std=c++11 -O2 -pthread    th_ping.cpp   -o th_ping
kenneth@rpi3:~/programming/c++/th_ping $ ./th_ping
This system got 4 CPU-threads
 0 <-> 1  :  40 ns
 0 <-> 2  :  38 ns
 0 <-> 3  :  39 ns
 1 <-> 2  :  38 ns
 1 <-> 3  :  38 ns
 2 <-> 3  :  38 ns
kenneth@rpi3:~/programming/c++/th_ping $ file th_ping
th_ping: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=38f7f12ef80f578a744062839f47fd4eea2f76a4, not stripped

@C64C: 1.475 är lite svettigt i spänning, 1.375 eller 1.365 var max rekommenderat av AMD själva för 24/7 körning, som det resonerats om att 1.4 är nog det högsta man bör köra om man vill hålla livslängden på processorn uppe i rimliga nivåer. Kortare benchining är nog ok så länge temp hålls under 75, tror temp throttling sker vid just 75.

Nu sitter jag i en övernattningslägenhet, utan min älskade Ryzen , men påverkar inte denna sak endast prioriteten på det program som ligger i förgrunden?
Prion petas alltså upp ett snäpp för detta.

@Ratatosk: Nej det påverkar vad som kallas quantum värdet, hur många klock ticks som tråden får stanna aktiv innan något annat får hoppa in (grovt förenklat). Det finns en del info om hur detta sker men det refereras hela tiden till olika värden. En del säger att saker i bakgrundsläge har 2 ticks och förgrunden 6 ticks på klient och 12 rakt av på server, detta ändrar du med bakgrundstjänster/program. Nackdelen blir då såklart att saker i bakgrundsläge också får 12 ticks vilket i sig har en negativ inverkan på prestanda. Detta skulle dock kunna vara värt det då även förgrund får 12 ticks. en tick brukar enligt en källa vara runt 10-15ms i windows så det är relativt stora värdeförändringar som sker. att då dubblera tiden som en tråd kan leva innan trådhopp sker torde ge förbättring på Ryzen (enligt min högst egna logik)

Edit, ett sätt att mitigera bakgrundstjänster från att ta upp för många ticks är att köra högre prio på applikationen, på så vis så avbryts det inte av saker i bakgrund med normal prio.

Detta tror jag är anledningen till att folk misstar det som att ge bakgrunstjänster högre prio, de har egentligen samma prio i schemaläggarn som tidigare, skillnaden ligger i hur länge dom får stanna aktiva jämfört med program i förgrund. Kanske lite av en tolkningsfråga.

Edit 2. Provade nyss själv att sätta bakgrundstjänster läget igen & manuellt ändrade prio till hög på wPrime med 1 tråd och denna gång gav det mig en prestandaförbättring på 0,2% jämfört med "program" läget. Alltså till och med på en i7 tjänade man prestanda på att använda högre quantum värde.

Jag har kört igenom testerna flera gånger för att vara säker och varenda gång är det samma sak.
Med prio normal på wPrime förlorar jag 0,3% prestanda att aktivera "bakgrunstjänster" läget (ökat quantum värde)
Med prio hög tjänar jag 0,2% på högt quantum värde.
obs. genom att enbart ändra prio på wprime med 1 tråd förändras inte min prestanda alls, det sker bara förändring vi/tillsammans med ändrad quantum ticks
Med andra ord borde det kunna gå att använda detta på Ryzen som ett sätt att minska antalet trådhopp per sekund och därigenom antalet kommunikationer mellan CCX kluster per sekund. Om jag nu inte tänkt helt åt helvete...

Superduper obs Detta skulle såklart vara till fördel på Ryzen just vid lätt flertrådade applikationer som dessutom sprids ut på alla logiska processorer som exempelvis lätt flertrådade spel, fall där komunikation mellan CCX kluster tvingas fram.

Tyvärr framgick det inte riktigt vad man syftade till, om det var allt prat om SMT problemen som pågått eller om det refererar till hur CCX klustren nyttjas, jag misstänker att AMD menar det tidigare. Skulle såklart kunna vara bägge fallen men jag tror inte det. Speciellt inte eftersom man specifikt nämner den felaktiga sysinternals dumpen orsakat av gammal mjukvara

@SeF.Typh00n: Och Jeremy Hellstrom på PCPer borde få veckans pris för best nyhetstitel:

https://www.pcper.com/news/General-Tech/AMD-Running-out-Intel...

Jisses, lol

Jag har tänkt en del på schemaläggningsintervallet också. @Yoshman gav tidigare en beräkning som går ut på att overhead av trådflytt i sammanhanget är liten vid 16ms OS-ticks, men sen noterade jag detta:

Ryzen: Strictly technical #458

Slide 6 i listan, handlar om saker som påverkar powermanagement, dvs mest kända saker som redan diskuterats i tråden. Men jag noterar raden:

”Timeout intervals” är väl samma sak som OS ticks? Så Win10 game mode ökar eventklockans upplösning, jag antar för att ge högre responsivitet vilket kan gynna tex FPS-spel online. Jag vet inte hur universellt detta är eller när och hur läget aktiveras. Jag kan ha fel om hur ofta det sparkar in. Men om vi tittar på Yoshmans beräkning igen:

200 ms/ns är 20% overhead i extremfallet. Då är det fortfarande ett extremfall, men lägg en okänd faktor på det iom Ryzens speciella cachestruktur och inter-CCX-kommunikation. Nu tror jag ändå inte att denna aspekt av trådflytt kan ansvara för hela skillnaden mellan Win10 och Win7, men om trådflytt kan ske varje millisekund så är det en magnitudskillnad med en faktor 16 mot ”vanliga” OS-ticks.

Det finns också en del som tyder på att strömsparfunktionerna, som är vad AMDs slide ovan egentligen handlar om (och som är anledningen till att AMD rekommenderar test under High Performance powerscheme), interagerar med schemaläggningen. En skribent från strictly technical-tråden argumenterar för att det inte är schemaläggningsalgoritmen utan Win10s system för core parking som ställer till det, vilken i sin tur förser schemaläggaren med invärden (vilka cores som är tillåtna att schemalägga). Sammanfattat här: https://www.reddit.com/r/Amd/comments/5yonzw/core_parking_and...

Strömsparfunktionerna interagerar alltså med eventtimern, och en högfrekvent sådan kan skapa prestandatapp i anslutning till powermanagement enligt AMDs egna tester (vilka jag antar utförts med 2 CCX aktiva).

Jag undrar därför om någon testat om prestandatappet i Win10 jämfört med Win7 (i förekommande fall) kvarstår vid likvärdig eventtimerupplösning? Har man kontrollerat för detta i de speltester som specifikt jämför Win10 och Win7?

Om eventtimern är boven så skulle det kunna innebära två saker:

• Att schemaläggarna såväl som strömsparfunktionerna i Win10 och Win7 är precis lika dåliga för Ryzen, men Win10 råkar vara effektivare på att göra sin dåliga grej, då OSet har möjlighet att lägga sig i oftare (varje ms jämfört med var 16e ms).

• Den lilla men stabila absoluta skillnaden mellan Win7 och Win10 vid 1st CCX kan bero på ett generellt OS overhead till följd av den högfrekventa eventtimern, som kan interagera med processorarkitekturen och därför vara mer utpräglat på vissa processorer (tex Ryzen). Ett generellt prestandafall är att vänta med snabbare OS-events, något vi också ser med lowlatency-kernelinställningar i Linux.

Som vanligt kan min hypotes redan ha uteslutits, då jag inte i primärt följer testerna för spelprestanda i detalj. Jag vet att HPET = off är ett förslag på prestandaoptimering för Ryzen som kom tidigt, och kanske något alla testare redan kör med, så min hypotes kanske redan är falsifierad. Men det är en kandidat på något som skiljer sig systematiskt mellan Win10 och Win7, inte huruvida HPET är aktiverat utan huruvida den ges inflytande över OS (jag förutsätter alltså att HPET=off omöjliggör 1ms upplösning, så körs de relevanta testerna med HPET avstängt så faller min hypotes).

@Oegat: Som jag förstår det hela så ju kortare intervall på schemaläggaren desto fler gånger per sekund kommer trådar troligen spridas vidare till nästa "lediga" kärna, Detta borde i mitt huvud öka antalet kommunikationer mellan CCX per sekund och därigenom öka latensoverhead lavinartat vid så lågt intervall som 1ms, även om det är då best case 6 ticks så skulle det vara 6ms kontra 12 ms vid 12 i quantum ticks om nu detta fortfarande stämmer i win10, skulle det vara ännu lägre ticks så blir bara problematiken än värre, alltså ännu fler kommunikationer per sekund mellan CCX kluster. Räknar man på 15,6ms så skulle det bli 93,6ms med 6 ticks och 187,2ms med 12 ticks (högsta tid/best case), med andra ord rätt stor skillnad mot 1ms scenariot.

Undrar om det går att få tag i information om hur det är i win10 med just quantum värdet och intervallfrekvensen. Om det är 16ms i win7 och 1ms i win10 så skulle det kanske kunna förklara en hel del av den prestandaskillnad som finns mellan dom på Ryzen, alltså att trådförflyttning sker 16 gånger oftare per sekund på win10 än win7, detta borde inte synas vid flera parallella stora uträkningar men som sagt vid mindre mer seriella uträkningar lär det ge en rätt otrevlig effekt.

Absolut är det stor skillnad! Dock räknade Yoshman på det hypotetiska scenariot 1 trådflytt / 16ms tick (inte 16*6), och argumenterade för att bara latenser + fylla L3 från RAM inte ens i det fallet bör innebära signifikant overhead (för en generisk processor). Men nu finns det ju många obekanta variabler när det gäller Ryzen som gör att total overhead vid trådflytt kan bli svår att uppskatta. Oavsett vad som exakt händer så är en faktor 16 i skillnad en siffra att misstänka, när det gäller att förklara prestandaskillnader mellan Win7 och Win10.

Jag har lite svårt att se fördelen med konstant trådflyttande på moderna processorer faktiskt, speciellt med alla boost lägen och bös borde det väl nästan vara bättre rent generellt att behålla tyngre trådar på samma ställe och kanske sprida ut lättare bakgrundsgrejer på nästa lediga kärna.
En del applikationer gör detta redan genom att kringgå schemaläggarn & sätter egen affinity mask och slipper således trådförflyttning, och naturligtvis är det extremt applikationsberoende/vad som beräknas. Möjligt att en del beräkningar tjänar på trådförflyttning (vet för lite om det)

Skulle vara intressant att förstå just varför man envisas med trådförflyttning som det sker nu. I rent energibesparande syfte kan jag nästan förstå det pga olika power states om man kan behålla alla kärnor i low power läge och ändå nyttja en tråd till 100%, problemet där är väl bara att processorn får konstant ping ponga vilken kärna som behöver snabbaste p state, vilket igen känns lite underligt tillvägagångssätt och jag vet inte om det i slutändan kan spara energi alls, rent teoretiskt borde konstant ändrande av p state suga mer energi än att hålla samma kärna kvar vid högsta p state. Det som i slutända känns mer logiskt är då termisk lastbalansering och att det skulle vara något slags motiv eller att man kanske kan nyttja cache på ett bättre sätt i uträkningar som är väldigt cache beroende (ingen aning hur). Frågan kvarstår dock i alla fall hur mycket man i slutändan tjänar på det hela. Jag tycker att det blir lite som att gå över ån efter vatten, även om man skulle tjäna på det genom cache nyttjande så tycker jag att man borde förlora på det i och med flyttandet av datan som ändå måste ske och de fördröjningar som läggs till genom detta, för en ensam arbetartråd så väntar den förmodligen ändå på sig själv i slutändan.

Jaja, late night ramblings

Här är prestandatest med visual studio
http://www.hardware.fr/articles/956-13/compilation-visual-stu...

@Oegat: Hittade just info om att i moderna windows så som win10 så kan varje applikation begära en förändrad resolution timer ända ner till 0,5ms, den är med andra ord flytande/justerbar on the fly. Detta skulle då ge ett möjligt scenario med 0,5ms upplösning, alltså ~32 gånger värre än tidigare trott. Om jag nu inte fattat fel det vill säga. Finns mer att läsa här och här
Windows 8-10 är alltså tick-less/dynamisk tick rate jämfört med win7 där värdet är statiskt.

Här finns ett program att justera timern med manuellt och avläsa aktuell timer tick tid, justering funkar inte på win10 men avläsning funkar.
https://vvvv.org/contribution/windows-system-timer-tool

Dock är vad jag förstår quantum värdet kvar och det är fortfarande en slags multipel på tick rate så vitt jag begriper det hela så tidigare nämnda tweaks borde fortfarande vara aktuella för Ryzen

Edit: provade nyss själv, om jag drar igång spotify & spelar upp musik hamnar jag direkt på 0,5ms på timern med automatik, idlar jag på skrivbordet utan något igång slår det över till 15,625ms. Kör jag igång chrome så landar det på 1ms vid aktivitet i chrome. Lite småkul och se skillnader mellan program, Edge verkar hålla timern mycket mer till 15,625 än något annat men kan dippa till 0,5ms, chrome verkar nästan sätta till 1ms oavsett vad som görs i chrome. Vid spelande ser den ut att hamna på 0,5ms. Med best case skulle det bli 3ms vid 6 q värde och 6ms vid 12. Känns som att detta skulle kunna ha en rätt bra inverkan på prestanda.

Intressant! Om det är timern borde vi alltså se samma prestandaprofil för Ryzen i win8 som i win10, och det räcker med att ett program som körs tycker att det ska ha hög timer för att hela systemet ska få det. Men är denna siffra relaterad till HPET-inställningen i bios alls? Jag trodde HPET var fix på 1000Hz men här går det uppenbarligen att ha en eventfrekvens på 2000Hz (0.5ms). Det skulle kunna betyda att det är någon annan klocka som används och att HPET är oskyldig, men det verkar också lite underligt. Det låter i vilket fall som att ett tredjepartsprogram som forcerar timern globalt likt det du länkar hade varit användbart i win10, åtminstone för de spel som inte har stor nytta av hög inputprecision.

Då låter det som att nästa test som det vore intressant att se är om skillnaden mellan win10 och win7 vid 2CCX försvinner då core parking specifikt stängs av i 10. För att svara på frågan om detta är samma problem eller ett annat.