Ashes of the Singularity: Escalation uppdateras – får bättre prestanda med Ryzen

Permalänk
99:e percentilen
Skrivet av Stoff3th3m4n:

Mjo men testerna i 720p är ju mindre relevanta eftersom de inte erbjuder ett "real world scenario" då en överväldigande majoritet av alla som spelar på datorer idag spelar på 1080p och uppåt.

Så nog ligger det något i det han säger.

Det enda som ligger i det han säger är att om man spelar dagens spel i 1080p, med det grafikkort och de grafikinställningar som använts i testet, är skillnaden mellan CPU A och CPU B så och så stor.

Ett test där GPU flaskar säger ingenting om faktisk skillnad i spelprestanda mellan A och B, vilket är i högsta grad relevant om man är ute efter högre framerate än i testet och/eller ska spela framtida spel som belastar CPU mer (möjligen även med snabbare grafikkort som då lanserats).

Skrivet av Ratatosk:

Vad skall jag ha som krav, om jag inte utgår från de krav som jag själv har. skall jag bojkotta en produkt som saknar Kinesiskt språkstöd, eftersom detta är en nackdel för en miljard Kineser?
Du kanske spelar i 720p, jag gör det inte, välj produkt efter din användning så gör jag det efter min.

Anser du att det var fel av Sweclockers testare att mäta i 1080p?

Läs vad jag skriver. Du ska inte bojkotta någonting. Köp vad du vill (och rekommendera vad du vill, med vilka argument du vill).

Det enda jag kritiserar är att du, med (åtminstone implicit) anspråk på allmängiltighet, hävdar att skillnaden mellan två CPU:ers spelprestanda är så och så stor baserat på ett test där GPU är en flaskhals – utan att ens hänvisa till det eller de testresultat varifrån du får siffran. (I det inlägg jag kritiserade hänvisade du bara till Ryzen-recensionen i allmänhet, utan antydan om att du utgick från testerna i 1080p.)

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Medlem
Skrivet av Alling:

Det enda som ligger i det han säger är att om man spelar dagens spel i 1080p, med det grafikkort och de grafikinställningar som använts i testet, är skillnaden mellan CPU A och CPU B så och så stor.

Ett test där GPU flaskar säger ingenting om faktisk skillnad i spelprestanda mellan A och B, vilket är i högsta grad relevant om man är ute efter högre framerate än i testet och/eller ska spela framtida spel som belastar CPU mer (möjligen även med snabbare grafikkort som då lanserats).

Läs vad jag skriver. Du ska inte bojkotta någonting. Köp vad du vill (och rekommendera vad du vill, med vilka argument du vill).

Det enda jag kritiserar är att du, med (åtminstone implicit) anspråk på allmängiltighet, hävdar att skillnaden mellan två CPU:ers spelprestanda är så och så stor baserat på ett test där GPU är en flaskhals – utan att ens hänvisa till det eller de testresultat varifrån du får siffran. (I det inlägg jag kritiserade hänvisade du bara till Ryzen-recensionen i allmänhet, utan antydan om att du utgick från testerna i 1080p.)

Ungefär det jag har sagt hela tiden, test i 720p säger enbart något om teoretisk prestanda, inte jättemycket om faktisk. Personligen är jag mer intresserad av real world scenarios än teoretiska. Du får däremot gärna vara mer intresserad av teoretisk, dock behöver inte det ena utesluta det andra när man ska försöka skapa sig en helhetsbild.

Visa signatur

AMD RYZEN 9 5900X - ASUS ROG X470-F STRIX - 32GB DDR4 @ 3200MHz - ASUS RTX 3070 Ti

Permalänk
Hjälpsam
Skrivet av Alling:

---Text--
Det enda jag kritiserar är att du, med (åtminstone implicit) anspråk på allmängiltighet, hävdar att skillnaden mellan två CPU:ers spelprestanda är så och så stor baserat på ett test där GPU är en flaskhals – utan att ens hänvisa till det eller de testresultat varifrån du får siffran. (I det inlägg jag kritiserade hänvisade du bara till Ryzen-recensionen i allmänhet, utan antydan om att du utgick från testerna i 1080p.)

Nej det inlägg som du kritiserade var detta.

Skrivet av Ratatosk:

@Yoshman: Jag tittar inte på testerna i 720p utan de i 1080.
Spelar själv i 1080, så de känns mer relevanta för mig.
Därav 5% vs 20%.

#16751890
Varför är det enbart 720p som är viktigt för dig, jag frågar igen, var det fel av Sweclockers att även testa 1080p?

Tycker för övrigt att du har ett väldigt aggresivt sätt att diskutera.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Datavetare
Skrivet av Ratatosk:

Nej det inlägg som du kritiserade var detta.
#16751890
Varför är det enbart 720p som är viktigt för dig, jag frågar igen, var det fel av Sweclockers att även testa 1080p?

Tycker för övrigt att du har ett väldigt aggresivt sätt att diskutera.

Hur allmängiltigt giltigt är egentligen 1920x1080 resultatet i ett CPU-test? Det är i många fall relativt GPU-bundet och därmed endast relevant för de som sitter med samma GPU som används i testet, i SweClockers fall ett GTX 1080.

Vidare så fick ju faktiskt hardware.fr samma relativa resultat mellan R7-1800X och i7-6900K, det i 1920x1080 fast där använde man Titan X Pascal.

För egen del skulle CPU-testerna faktiskt vara rätt värdelösa utan speltester där man tagit bort GPUn ur ekvationen. Inte för att jag spelar i 1280x720 eller kör i 200 FPS, är faktiskt rätt ointresserad av spelprestanda (har för närvarande ett GTX970 och kör i 1920x1080, skulle få samma FPS med i3-6100 som jag får med en tre gånger dyrare CPU).

Vad jag är ute efter är hur CPUn presterar i fall som främst beror av vanliga heltalsberäkningar, det då detta fall står för en förkrossande majoritet av vad som påverkar prestanda i "vanliga" program och prestanda hos OSet självt (som är kritiskt i bl.a. många I/O-intensiva laster). Tyvärr testar de flesta CPU-benchmarks saker som är helt irrelevant i praktiken utom för vissa väldigt smala nischer.

Allt fler verkar ta med kompilering-test. Det är jättebra för just kompilering har visat sig vara en väldigt bra indikation på generell heltalskapacitet i fall som skalar perfekt med CPU-kärnor.

Tester som Google octane och än mer webXPRT (som till skillnad från JS-benchmarks testar generell prestanda i webbläsaren) är lysande indikationer på heltalskapacitet i fall som är enkeltrådade.

Ett väldigt vanligt fall saknas nu, fallet som har viss skalning med CPU-kärnor men där underliggande problem inte är "embarrassing parallel". För mig och gissningsvis väldigt många andra som multitaskar, kör virtuella OS och liknande är detta den mest intressanta värdet. Av allt som brukas köras i CPU-tester är spel det enda som kan ge en siffra på detta, men det kräver att GPUn helt plockas bort ur ekvationen. Så för mig får de gärna köra spel i 320x200!

Just heltalsprestanda är tyvärr Ryzens svaga punkt. I kompilatorfallet (som alltså skalar perfekt med CPU-trådar) är R7-1700 och i7-7700K helt jämna. Är det jag menar visar: är teoretiskt omöjligt för R7-1700 att någonsin bli snabbare än i7-7700K i spel, best-case är att spel skalar helt perfekt med kärnor (något som är omöjligt i dagen spelmotorer, men är ju teoretiskt möjligt att de helt designas om i framtiden, realistiskt kommer det inte hända de närmsta 10-20 åren).

Än värre är det för enkeltrådfallet. Här presterar faktiskt Ryzen någon under Sandy Bridge vid samma frekvens, det positiva är ändå att Sandy Bridge står sig riktigt bra än idag och de högst klockade Ryzen-modellerna tar igen lite på att de är högre klockade än toppmodellerna av Sandy Bridge. Notera att detta gäller för heltal, tittar man på skalära flyttal (vilket väldigt många benchmark testar) presterar Ryzen i nivå med Broadwell vid samma frekvens (för mig är detta totalt irrelevant då jag inte använder något program där prestanda på något relevant sätt beror av prestanda vid beräkningar med skalära flyttal).

Angående just optimering av AoS. Verka just detta fall till viss del beror på något jag försökt pekat på ett par gånger: att "optimera" för hand är idag nästan dömt att misslyckas. Mer än nio av tio programmerare kommer göra ett sämre jobb än vad en kompilator plus en generellt bra design kommer nå.

Här verkar Oxide försökt "optimera" för bättre cache-utnyttjande genom att använda en instruktion, movntdq, som skriver data direkt till RAM utan att påverka CPU-cache. Detta verkar av någon anledning ha varit en extremt dåligt idé på Ryzen, gissar att man även tagit bort detta för Core. Skillnaden för Core är minimal, men alla som testat verkar i genomsnitt se en marginell förbättring även för Core.

movntdq kan ge en boost om den används rätt, men man måste förstå väldigt mycket om x86, dess minneskonsistensmodell och om cache-design i allmänhet för att få det rätt (i beyond3d tråden du länkade pratades det om att alla "nt" (non-temporal) instruktioner är "black magic"). I normalfallet: använd memcpy(), i alla fall på Linux använder den movntdq i vissa speciella lägen. Det är en användning som testats på massor med olika CPU-modeller och är som sagt rätt få fall man sett det vara en fördel.

Och detta visar en av de trevligaste egenskaperna med Core: det är en extremt förlåtande mikroarkitektur. Även "korkade" saker tenderar att prestera helt OK, men gör man sådant brukar det slå tillbaka rätt rejält om man måste köra på lite andra CPU-modeller.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
99:e percentilen
Skrivet av Ratatosk:

Nej det inlägg som du kritiserade var detta.

Nej, det var inte det jag kritiserade. Det var det jag citerade (av uppenbara skäl). Det jag kritiserade var klart och tydligt det inlägg där det jag kallade "ett generellt påstående" om 6900K vs 1800X förekom.

Citat:

Varför är det enbart 720p som är viktigt för dig, jag frågar igen, var det fel av Sweclockers att även testa 1080p?

Sorry, missade att svara på den frågan. Nej, det tycker jag inte var fel. Det är däremot fel att med 1080p-testerna som grund hävda en viss prestandaskillnad mellan två CPU:er, åtminstone om man inte specar att det är 1080p-testerna man tar sina siffror från.

Citat:

Tycker för övrigt att du har ett väldigt aggresivt sätt att diskutera.

Det var tråkigt att höra. Jag får försöka bättra mig.

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Medlem
Skrivet av Ratatosk:

@Yoshman: Jag tittar inte på testerna i 720p utan de i 1080.
Spelar själv i 1080, så de känns mer relevanta för mig.
Därav 5% vs 20%.

Men uppgraderar du ditt grafikkort blir ju testerna i 720p relevanta.
Då är ju prestandaskillnaden tillbaka på 20% @ 1080p.

Visa signatur

Hata postsorteringen i Ånge.

Permalänk
Hjälpsam

Att kompilera om men en nyare version av MSVC, var en del av lösningen.

Skrivet av FioraAeterna:

update: one part of the problem was a compiler bug in MSVC2015, where it would emit ST/ST/LD in some cases (which stalls the store queue)
so part of the fix was just to recompile Ashes with MSVC2017, which had a fix.

https://twitter.com/FioraAeterna/status/847478445131014146

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Datavetare
Skrivet av Ratatosk:

Att kompilera om men en nyare version av MSVC, var en del av lösningen.
https://twitter.com/FioraAeterna/status/847478445131014146

Om detta från tråden du länkar stämmer

"update: one part of the problem was a compiler bug in MSVC2015, where it would emit ST/ST/LD in some cases (which stalls the store queue)"

så pekar det på att write-combine (vilket är vad man vill åt med "non-temporal" stores om inte prestanda ska suga totalt) är trasigt eller åtminstone väldigt ineffektivt på Zen. Med write-combine vill man absolut ha ST/ST/... till dessa att man fyllt en hel cache-line.

write-combine: att kunna skriva flera gånger till en lokalt cachad buffert som är 64 bytes stor (en cache-line stor). Man har write-combine då "non-temporal" skrivningarna är specialdesignade att gå förbi CPU-cache. Så skrivningar blir dyrt! Write-combine är en optimering som låter en skriva en hel cache-line innan den skrivs ut till RAM. Detta är också ett sätt att lyfta på x86 extremt strikta minneskonsistensmodell (store fence är i normalfallet onödigt på x86, men behövs ihop med non-temporal stores).

Men vad det än är, detta ser ut att ha varit en "optimering" som fungerade OK på Core enbart för att det är en förlåtande mikroarkitektur. Av allt att döma är det man gör nu mycket bättre för Ryzen och marginellt bättre även på Core.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Om detta från tråden du länkar stämmer

"update: one part of the problem was a compiler bug in MSVC2015, where it would emit ST/ST/LD in some cases (which stalls the store queue)"

så pekar det på att write-combine (vilket är vad man vill åt med "non-temporal" stores om inte prestanda ska suga totalt) är trasigt eller åtminstone väldigt ineffektivt på Zen. Med write-combine vill man absolut ha ST/ST/... till dessa att man fyllt en hel cache-line.

write-combine: att kunna skriva flera gånger till en lokalt cachad buffert som är 64 bytes stor (en cache-line stor). Man har write-combine då "non-temporal" skrivningarna är specialdesignade att gå förbi CPU-cache. Så skrivningar blir dyrt! Write-combine är en optimering som låter en skriva en hel cache-line innan den skrivs ut till RAM. Detta är också ett sätt att lyfta på x86 extremt strikta minneskonsistensmodell (store fence är i normalfallet onödigt på x86, men behövs ihop med non-temporal stores).

Men vad det än är, detta ser ut att ha varit en "optimering" som fungerade OK på Core enbart för att det är en förlåtande mikroarkitektur. Av allt att döma är det man gör nu mycket bättre för Ryzen och marginellt bättre även på Core.

Är detta nått som även andra spel kan lida av eller är det en ovanlig compiler. Snabb googling säger att blizzards starcraft och diablo serie då även borde lida av samma bugg då man gått ut med att man slutar stödja xp och vista för att kunna använda en modern form av msvc2015

Skickades från m.sweclockers.com

Permalänk
Datavetare
Skrivet av HenrikM:

Är detta nått som även andra spel kan lida av eller är det en ovanlig compiler. Snabb googling säger att blizzards starcraft och diablo serie då även borde lida av samma bugg då man gått ut med att man slutar stödja xp och vista för att kunna använda en modern form av msvc2015

Skickades från m.sweclockers.com

Skulle säga att väldigt nära 100 % av alla aktuella spel som körs på Windows använder någon version av MSVC++. Det konstiga med att det skulle finnas en bug specifikt relaterad till _mm_stream_ps() är att detta inte är en funktion i traditionell bemärkelse utan en s.k. compiler intrinsic function.

Kortfattat: _mm_stream_ps() är ett sätt för C++ programmerare att använda C++-syntax för att lägga in en specifik assemblerinstruktion (movntps i detta fall). Fördelen med att använda _mm_stream_ps() i stället för att direkt skriva assembler är att kompilatorn fortfarande har rätt att ändra på platsen där den faktiskt lägger ut movntps instruktionen så länge den förändringen inte bryter mot hur ett korrekt C++ program ska uppföra sig.

En typisk optimering man vill göra är att flytta alla läsningar från minne (loads, eller LD förkortat) så instruktionen ligger så tidigt som möjligt medan man normalt vill flytta alla skrivningar (stores, eller ST förkortat) så de händer så sent som möjligt. I normalfallet är det en generellt bra optimering, kan vara så att det inte är en bra idé att göra så med "non-temporal" stores när man kör på Ryzen.

Rent tekniskt är detta ändå inte en bug, koden är logiskt sett korrekt. Däremot är det fullt möjligt att VS2017 (och medföljande versioner av MSVC++) har en annan policy för hur "non-temporal" stores hanteras.

Att sitta att handoptimera (även om det i detta fall blev handförsämra) på den här nivån är väldigt dyrt, så tvivlar att speciellt många spel har motsvarande "optimeringar". Också väldigt lätt att någon som ger några procent boost på just den CPU-modell man optimerat för resultera i rejäl försämring på modeller man inte testat. I normalfallet ska man alltid låta bli sådana lågnivåoptimeringar, fokusera i stället på att optimera den "normala" C++ koden och framförallt se till att optimera systemdesignen. Sådana optimeringar fungerar garanterat på alla CPU-modeller och brukar också åldras bättre när nya CPU-designer kommer ut.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Hjälpsam

@Yoshman: Absolut optimering via bra systemdesign, då får man också andra bra saker på köpet, lättare att underhålla ändra och utveckla.

Ett till stort problem med handoptimering är underhållningsbarheten, vem optimerade, varför, hur påverkar detta annan kod?
Handförsämring, bra ord, skall läggas på minnet.

Funderar på om det var Ryzens delade L3 cache som förvirrade kompilatorn.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |