AMD Ryzen 7 1700

Att det skulle finnas ett fel i hur Windows och Linux schemalägger OS-trådar på CPU-trådar är det många som hävdat nu, alla ni har fel. Gissningsvis för att det krävs hyfsad detaljkunskap kring vad ett OS faktiskt kan veta om sina applikationer.

Är ju värt att notera att AMD inte anser att det finns något problem med schemaläggaren i Windows, så där finns det i alla fall några ingenjörer som klarat sin OS-design kurs.

Det är absolut sant att om två OS-trådar kommunicerar ofta så är det bättre att hålla dem inom samma CCX på Ryzen. Men det är också så att två OS-trådar som inte kommunicerar läggs med fördel ut på olika CCX då de kan dra nytta av en större CPU-cache.

Hur vet OSet vilka trådar som kan tänkas kommunicera med varandra? Det kan ett OS omöjligen veta, framförallt när de mest effektiva sätten att kommunicera mellan OS-trådar helt undviker att blanda in OSet.

I spel kommer de flesta, men inte alla, trådar att kommunicera relativt mycket med varandra. I t.ex. Blender är det i praktiken noll kommunikation mellan trådarna. D.v.s de enda som vet vilka OS-trådar som kommunicerar med varandra är de som utvecklar applikationerna, både Windows och Linux har funktioner för att låta applikationen styra vilka CPU-tråd/trådar en viss OS-tråd kan köra på.

Och är precis detta AMD hävdar att man nu gör, man jobbar med spelutvecklarna då de är de enda som kan se till att spel undviker att för mycket kors-CCX kommunikation.

Håller med om att R5 1400, 1500X och R7 1700 kommer presterar i det närmaste identiskt i de flesta applikationer, det då de flesta applikationer inte utnyttjar mer än eller kanske två CPU-kärnor.

Men just spel är ett fall där det kommer vara en skillnad då de flesta moderna spel faktiskt kan dra viss nytta av både sex och åtta kärnor. i7-7700k har både högre IPC och klart högre klockfrekvens jämfört med t.ex. i7-6900K. För de flesta på SweClockers är det nog ändå så att spel är det mest krävande man gör med sin dator, för många är det nog det enda krävande man utsätter datorn för (resten hade lika gärna kunna utföras på en mobil CPU).

Även om i7-7700K är snabbast i de flesta spel är det ändå rätt jämnt. Kikar man på SweClockers test där de kör alla CPU-modeller på 2,8 GHz så ser man att i7-6900K är snabbare än i7-7700K. Är faktiskt så att i7-6950X tar tätpositionen, något som antyder att det till och med finns en liten liten vinst med tio kärnor över åtta kärnor.

Dock skalar spel, likt de flesta skrivbordsapplikationer som ändå kan utnyttja många CPU-kärnor, inte alls linjärt med antalet CPU-kärnor. Det är en rätt stor vinst att gå från två till fyra, men effekten droppar av allt mer ju fler kärnor man har. Detta är helt förväntat beteenden och är precis vad Amdahls lag beskriver. (Och detta är verkligen en lag, är omöjligt att få ett datorprogram att skala bättre än vad Amdahls lag beskriver).

Det som gör i7-7700K speciell är att ingen annan CPU-modell i världen har högre prestanda per CPU-kärna. Det betyder den modellen i praktiken är den snabbaste modell pengar kan köpa för de flesta desktop-användare. Den är absolut overkill för väldigt många och finns absolut de som får en bättre upplevelse med en CPU med fler CPU-kärnor som Ryzen.

Bevis för mitt påstående gällande att trådar allokeras till slumpmässiga kärnor:

https://www.youtube.com/watch?v=JbryPYcnscA

Bevis på prestandaskillnaden när man eliminerar detta:

https://www.youtube.com/watch?v=BORHnYLLgyY

Som jag skrev innan, det är rätt tekniskt och förstår att de flesta inte ser orsaken till varför en generell OS-scheduler inte kan gör det som är globalt optimalt i alla lägen.

I ditt exempel: hur ska Windows veta att just den här applikationen har relativt mycket kommunikation mellan OS-trådarna? Det är omöjligt för Windows-kärnan att veta detta.

Anta då att man alltid håller saker på inom en CCX. Det löser det specifika fall du länkar, men det skulle försämra för andra fall, potentiellt rätt mycket om det är något där båda trådarna har ett relativt stort "working-set" (åter igen något ett OS rent generellt inte kan veta, d.v.s. hur stort "working-set" en OS-tråd har för tillfället).

Följaktligen: både Windows (och Linux som gör samma sak) fungerar på ett sätt som i genomsnitt är det optimala. I specifika fall kan applikationer som behöver maximal prestanda själva ta hand om att lägga OS-trådar på CPU-trådar, t.ex. för applikationen vet att det är mycket kommunikation mellan trådar (hålla på samma CCX) eller för att applikationen vet att "working-set" är stort och i stort sett ingen kommunikation sker mellan trådar (lägga på olika CCX).

För du kan göra mer med en dator än att spela spel.

Skickades från m.sweclockers.com

Med andra ord så förstod och instämde du för första gången att det jag försökt visa stämmer. Finns absolut inget omöjligt eller negativt att köra trådar i sekvens från 0-15 såvida dom inte överstiger kapaciteten hos en CCX, dvs 8 trådar. CPUID i Ryzen flaggar också om 2st CCX vilket gör det identifierbart. Vad spelar det för roll vad OS vet och inte vet när det bevisligen är ett problem som kan lösas på en ny arkitektur?

Så vitt jag vet så beter sig Linux annorlunda här, iaf en del tester jag sett som inte kastar runt trådar, och verkar assignera trådar inom en CCX först. Denna summering gjorde PC-per också i sin del.2, att M$ behöver utöka Windows funktionalitet här gällande hur trådar sprider sig. När det kommer till en ny arkitektur så är det Microsoft's jobb att se till att processhanteringen fungerar optimalt på alla arkitekturer som det stödjer. Samma med en del ARM utgåvor där samma problem borde uppstå.

Har själv testat detta och kan inte hitta en enda praktisk applikation som inte gynnas av att isoleras. Vad har en process med större working set att göra i en annan CCX sålänge den inte nyttjar fler trådar än vad en CCX kan tillhandahålla? Visa mig ett praktiskt bevis på detta och inte en potentiell teori. Jag har testat själv och absolut jag kan slänga på får någon degradering i prestanda, utan bara samma eller en förbättring.

Observera att det är en prestandaskillnad här på 20%. Det är extrema mängder i tapp för att vara i närheten av acceptabelt. Knappast något att fnysa åt och låta det vara. Microsoft har gjort mer än pipit på twitter om saken.

Lätta först, Linux. Kolla i källkoden så ser du att det finns överhuvudtaget ingenting där som på något sätt tar hänsyn till att det finns två CCX i Ryzen. Finns inte heller någon kod i Linux som på något sätt bryr sig om cache-topologin när det kommer till hur trådar schemaläggs. Det man tar hänsyn till är NUMA-zoner, d.v.s. om vissa kärnor har olika kostnad att nå olika delar av RAM.

Vad Linux tar hänsyn till är SMT. Specifikt hanteras Ryzen som Intels Core, "gamla" Atom och i princip alla CPUer med SMT. Bulldozer-arkitekturen hanteras däremot separat, där väljer Linux att lasta båda trådarna i en modul innan nästa modul tas i anspråk, med SMT lastar man först en tråd per kärna så länge det finns kärnor som är "idle".

Att OS-trådar hoppar mellan CPU-trådar är dels inte vad som orsakar det du är ute efter, det är heller inte ett problem i praktiken då Windows skyfflar runt saker med en frekvens som inte alls är så hög att den har en relevant påverkan på prestanda.

Att OS-trådar hoppar runt på Windows och inte gör det på Linux beror på att de är optimerade för olika fall, båda designvalen har fördelar och nackdelar. Windows prioriterar svarstid över "throughput", framförallt för interaktiva applikationer (d.v.s. den applikation som har input-fokus). Linux specialbehandlar ingen process och där prioriteras "throughput" mer än svarstid.

Ett praktiskt exempel på ovan är: om tråd A postar en semaphore så tråd B nu bli körklar, ska tråd A eller tråd B fortsätta köra på aktuell CPU-tråd? Det är något som studerats väldigt ingående och finns inget svar som alltid är bäst, beror på en rad faktorer bl.a. om man vill optimera för CPU-throughput, I/O-throughput, svarstid etc.

En applikation som t.ex. jobbar mot en in-memory databas som är relativt stor lär köra snabbare om två samtida trådar ligger på separata CCX. Men det stora problemet är detta: anta att man håller saker inom CCX, hur ska man då schemalägga moderna spel som i princip alltid utnyttjar fler än fyra OS-trådar?

Så visst går det att vinna 20 % i ett leksaksexempel som ovan, men det skulle ändå inte lösa "riktiga" applikationer. Än mindre lösa fall när flera multitrådade applikationer kör samtidigt.

Och om det nu är ett problem, för AMDs del skulle det vara överlägset enklast att peka på att problemet ligger i Windows. Det skulle betyda att man kan fixa ett ställa och problemet är över. Nu erkänner man i stället att designen man valt är lurig att hantera generellt, lösningen blir att till viss del specialhantera designen i varje applikation. Det är ett budskap jag tvivlar någon vill ge innan det är absolut klarlagt att det är enda vägen framåt.

*** tråd något modererad ***

Jag har raderat och redigerat några inlägg, främst för personangrepp (§ 1.2) och något för misstänkt trollning (§ 1.5).

Det finns så pass mycket intressanta tekniska saker att diskutera, så håll er till det, tack.

/KimTjik

Från anandtech

Det verkar som att R3/Raven Ridge blir spelprocessorerna vi väntat på.

För upp till 8 trådar på en CCX så är AMDs svarstid i kärnorna lägre än Intels med SMT i tankarna, så visst tusan finns där prestanda att hämta. Mao, Intel vinner 1Tråd, men AMD vinner 2Tråd-8Tråd prestanda i latency.
Med 2 CCX dock måste de kunna användas på rätt sätt pga bryggan mellan dem. Fixar de detta på hyfsat sätt så kommer spelprestandan att bli bättre.

Och när det gäller 5Ghz... välkommen till 2011, när SB gjorde det redan då, så Intel har kommit i kapp sin 5 år gamla nivå igen. Så att hurra över det är lite... gammalt.

AMD har släppt en helt ny arkitektur från scratch, och ingenstans, som inte bara konkurrerar bra för sin tidiga generation, och med IPC typ vid Haswell... utan även når 4Ghz, något Intels Nehalem inte ens klarade. Inte så mycket som krävs för att de också ska börja nå 4,5-5Ghz och förbättra IPC igen med nästa generation... de behöver bara göra en Intel Sandy bridge.

Det är inte Sweclockers jag skrattar åt det jag menar är alla blev helt plötsligt 3D artister över natten.

Kan tänka mig att majoriteten här är gamers och är ute efter spelprestanda och inte arbetsprestanda. Nu är jag programmerare själv och de flesta andra är säkert det med men inte riktigt samma sak

Mjaa. Alltså nästan alla bygger sina spelburkar så att det är grafikkortet och inte processorn som sätter begränsningarna. Eller ska man köra i 720p så ser vi en hel del skillnader. 1080 med hög uppdateringsfrekvens där drar intel också ett längre strå i vissa scenarion redan nu kanske.
Men många spelar med högre upplösningar än så eller 60fps och där blir det ingen skillnad i processorval utan grafikkorten tar stopp långt tidigare.
Det visas väl rätt bra i detta inlägg:
#16722627
Man klarar sig med rätt billiga processorer till och med. Så det ligger något i det du säger att nuvarande 8kärninga ryzen 7 inte är prisvärd om man bara vill spela vilket väven gäller för intels i7or. Där är väl i3orna kung i nuläget antar jag...
Det kommer lite breddning av ryzenutbudet inom någon månad. Får väl se vad det innebär.

Jaa förstår syftet och det är grymt för de som använder det. Det jag ifrågasätter är om det faktiskt är så många här som använder blender.

Argumentet har blivit lite som, "Ja Ryzen är inte bäst i spelprestanda men kolla på Blender hur bra det är!!" Även om man inte använder det.

Kul att ingen läser på utan bara slänger gammal information hela tiden. suck!!

Windows har inte rätt kö system för Ryzen cachen.. Den är på väg.

https://www.techpowerup.com/231268/amds-ryzen-cache-analyzed-...

https://www.youtube.com/watch?v=ylvdSnEbL50

*** trams och trollande raderat ***

Jag blev tyvärr tvungen att radera ytterligare några inlägg...

/KimTjik

Håller inte med.

Här har du benchmarks med 2500k och 8370 som svar på den videon.

Angående det där med problem i Windows, är det inte det AMD dementerar här?
http://www.sweclockers.com/nyhet/23510-amd-schemalaggaren-i-w...