Varför Ryzen 7 när i7 7700K är bättre? (gaming)

Påverkan från RAM med samma CPU

Vet inte varför du går på så mycket om detta. Har nu skrivit + specifikt påpekat att jag inte på något sätt säger emot dig här. Om CPUn är konstant så påverkar absolut minneshastigheten och timings spelprestanda.

Hur mycket den påverkar finns det olika bud kring. Extremfallet här är ju i7-5775C, även om eDRAM har väldigt hög latens och relativt lång bandbredd för att vara en cache så är latens och bandbredd på en nivå minst motsvarande de absolut snabbaste DDR4 modulerna som existerar. 5775C var i många fall snabbare i spel än 6700K med "normalklockat RAM", trots att den senare är något högre klockad och har lite högre IPC.

PcPerspective har kikat specifikt på timings och spelprestanda för Skylake. Så länge man verkligen är CPU-bunden är det helt klart skillnad. Tankevurpan jag gissar vissa gjorde kring i7-7700K vs resten när det kommer till påverkar i spel är att de missade att i7-7700K är den CPU som oftast kommer vara GPU-bunden -> oftare ett läge där CPU-prestanda inte kan påverka då flaskhalsen är något annat.

Skylake vs Zen och RAM

Säger inte att du har fel kring subtimings. Men tillåt mig att vara väldigt skeptiskt kring ditt påstående "dessa subtimings orsakar inte i närheten likadan prestandapåverkan på Intel processorer men på Ryzen gör det de". Har du verkligen torrt på fötterna här?

Det var samma tongångar kring påverkan från minneshastighet och där visade det sig snarare att det omvända var sant. SweClockers såg större boost på i5-7600K jämfört med R5-1600X, även om ett t-test gissningsvis pekar på att skillnaden knappast är signifikant på någon rimligt konfidensnivå.

Tittar man på detta från ett teoretiskt perspektiv borde eventuell vinst från RAM-timings påverka Intels S-serie i större utsträckning än det påverkar X-serien och Ryzen.

Orsak? I en minnessystem har man ett relativt konstant tillskott av latens från själva CPU-kretsen, som är främst är en funktion av cache-design. Med samma RAM-timings och RAM-hastighet ligger S-serien ~20 ns lägre i latens jämfört med X-serien/Ryzen, d.v.s. eventuell förbättring i timings ger relativt sett ett större utslag för S-serien än för de andra två.

Är inte riktigt det här jag tror du får på Ryzen, eller hur?

Åter igen: säger inte att du har fel, säger att givet historien väntar jag med att hävda något här innan det finns mer data...

Fysisk är inte heltal

Sir, yes sir!

Fast tror inte riktigt det skulle ändra något i den riktning du är ute efter... Det är 2017, fysikmotorer, likt typ allt annat förutom Cinebench har klivit in i 2000-talet och använder vektoriserade flyttal. Det mesta går att beskriva som matriser, så fort du kan beskriva något som en matris finns massor med handoptimerad SIMD-kod som totalt massakrerar en naiv implementation med "vanliga" flyttal i standard C++.

Den källkritiskt lagde kan alltid git-clone:a t.ex. Bullet Physics och verifiera själv att det främst är SSE-optimerat. I praktiken använder man SSE-delmängden av AVX när man kör på 64-bitars x86, d.v.s. VEX-kodade instruktioner, är något mer effektivt jämfört med "klassisk" SSE.

Grejen är att i det läget är inte i7-7700K 50 % snabbare per CPU-kärna jämfört med R5-1600, det är väsentligt mer. Är helt övertygad om att fysisk inte ens är i närheten att vara en primär flaskhals i väldigt nära 100 % av alla spel (undantag finns alltid, sett till forum känns det som vissa bara bryr sig om undantagen...).

TechPowerUp

Vad jag specifikt skrev var att 1920x1080 resultaten var med "ultra" inställningar. Hittar faktiskt inget kring vilka inställningar man använt i 1280x720 så lät bli att hävda något. Jämför man TechPowerUp med SweClockers (som specifikt skriver att 1280x720 är "medium") ser det dock ut som TechPowerUp använt betydligt högre kvalitetsnivå än "medium".

Peka gärna var du hittar information om att det skulle vara "medium".

Oavsett inställning missar du huvudpoängen: 720p må vara en usel proxy för framtida spelprestanda (ingen kan säga hur framtida spelmotorer är designade), men det är en väldigt bra indikator på hur mycket dagens spel skulle kunna se i boost om de körs på framtida betydligt snabbare GPUer med dagens CPUer.

D.v.s. 720p är det bästa vi kan tillgå för att visualisera skillnad i dagens CPUers kapacitet att driva spel. 1920x1080 "ultra" resultatet visar med brutal tydlighet hur extremt GPU-bunden man är i praktiken, är rätt liten skillnad mellan t.ex. i3-7100 och i7-7700K och där är det rätt enkelt att räkna ut skillnad i CPU-kapacitet.

DDR4 3200 vs 3466VLL

Finns då överhuvudtaget inget i MindBlanks resultat som ens är i närhet att påvisa någon 20 % skillnad mellan dessa två konfigurationer. Mellan 3600 och 3466VLL är det ~5 % skillnad i både genomsnitt och 1 % low.

Känns det rimligt att man ens teoretiskt skulle kunna få 20 % boost? Bandbredden ökar 8 % och för att den latens CPU "ser" ska minska 20 % lär latensen på RAM minska rätt mycket mer än 20 % (det är minst 20 ns "statiskt" latens hos Zen, det förutsatt att den är noll hos S-serien vilket i sig är totalt orimligt så det är >20 ns "statis" latens).

Det specifikt när TechPowerUp testat med: 2x 8 GB G.SKILL Flare X DDR4 DDR4-3200 14-14-14-34, d.v.s. hyfsat låg latens. MindBlank körde med 3600 CL16 (8,89 ns) mot 3200 CL14 (8,75 ns), så det är lägre latens hos TechPowerUp.

Vidare, min huvudinvändning mot hela inlägget som länkade denna video var: tittar man faktiskt på resultaten så säger ju de exakt tvärtemot vad som texten i posten indikerar. D.v.s. i7-7700K är i genomsnitt snabbare (vare sig man använder aritmetiskt medel eller median). Dock är den fördelen inte på något sätt statistiskt signifikant, så går egentligen inte att säga vilken CPU som är snabbare givet data i videon.

I teorin (och av allt att döma gäller det även i praktiken) så minskar latensen hos Infinity Fabric ju högre frekvens RAM snurrar på.

Lägre timings hos RAM kan rimligen inte alls påverka latensen som Infinity Fabric lägger på.

Fast första egenskapen är inte unikt till Infinity Fabric. Alla CPUer måste ju ha en minneskontroller, det är den som driver minnesklockan så ju högre frekvens minnen snurrar i ju lägre blir latensen som minneskontroller lägger på.

Det är helt analogt med att DDR4-3200 CL16 har högre latens jämfört med DDR4-3600 CL16, det är samma antal cykler men tiden för varje cykel minskar.

@Yoshman: Skulle infiniyt-fabric kunna göra att Ryzen har mer prestanda från hög klock/låga timings på RAM?

Om du läste vad jag faktiskt skrev hade du förstått vad subtimings handlar om på ryzen, med agesa 1.0.0.6 infördes extremt slappa subtimings, vi pratar skillnad i magnituder. Detta sänker FPS i spel som en gråsten, om man då sätter tajtare timings tjänar man väldigt mycke fps, vissa spel upp till 20% skillnad mellan auto timings och snabbast möjliga.

Som jag sagt innan, subtimings är viktigt på Ryzen pga hur jävla slappt dom sätts till att börja med, Intel har inte alls lika slappa subtimings vid full auto eller XMP, därför har inte Intel något att sänka och därför heller ingenting att tjäna på affären/ inte alls lika mycket. Inte så invecklat eller hur? När man då benchar med tajta subtimings på Ryzen så kommer man få väldigt mycket mer fps.
Swecs test av minnespåverkan har ett par ganska rejäla brister men eftersom du verkar uppvisa total avsaknad av förståelse för subtimings vet jag inte om det är någon större ide att ens ta upp dom...
Intressant att du verkar veta exakt vilken typ av beräkningar som används av fysikmotorer helt plötsligt och att det definitivt inte används i nästan varenda modernt spel, driver du med mig?

Du kan inte jämföra Witcher 3 från olika ställen av en mycket enkel anledning, witcher 3 har inget benchmark verktyg så allt är manuellt inspelat med manuellt input på helt olika ställen i spelen. Det kan skilja rent bisarra nivåer av fps mellan olika test på dessa sätt
Det gäller även Fallout 4 förresten...

https://i.imgur.com/iZkUgY7.png
720p ultra utan AA med 0% gpu flaskhals
Jag sa väl upp till 20% åt fel håll va och dessutom mellan 3200 & 3466vll? Om du tittar på .1% low på 3333H och 3333L så skiljer det mer än 20%, detta med endast timings som skillnad mellan de två Om vi ska prata mer generellt så ligger 3333H ~11,5% under 3333L, detta är alltså XMP profil vs manuella subtimings. Sen har vi 79% bättre 0,1% min FPS på 3466ll än 2666 auto timings, nej minne på ryzen gör ingeting, sheezus..
Att du sedan försöker påtala liten skillnad med timings genom att jämföra 3600 med 3466 blir helt enkelt hål i huvudet, du vet att minnesfrekvens i sig ökar prestanda och du vet att IF frekvens ökar prestanda, som då bägge äter upp förtjänst av timings vid 3466.

Huvudtimings är inte samma som subtimings, försök inte ens blanda ihop detta för du vet bättre...

Sa jag något annat än att processorerna presterade mycket lika varandra?

Detta är extremt fult av dig Yoshman, du vet att IF påverkar mer än bara minne, det påverkar latensen mellan CCX klustren och även l3 cache bandbredd/latens. Detta är du fullt medveten om, det sker däremot inte på Intel då dom inte har ccx kluster till att börja med. Måste du i varenda inlägg visa din bias?

Sen är det ganska talande att du över huvud taget inte tar i uppgifterna från hardwareunboxed med vega64

Svordomar

Trovärdigheten i det man skriver är omvänt proportionellt mot antal mot antal svordomar som behövs för att framföra sitt budskap

1280x720

Sitter du inte rätt mycket och skäller under helt fel träd här? Det var du inte jag som försökte påskina att TechPowerUp körde "medium" i 1280x720. Jag undvek uttala mig just för att informationen saknades.

Pekade sedan på att SweClockers skriver specifikt att man kör "medium", de får väsentligt högre FPS (gäller förövrigt även Warhammer som har en inbyggd benchmark). Vidare är det betydligt mer samstämmiga resultat i 1920x1080 där båda kör "ultra".

D.v.s. du hävdade något du verkar ha haft absolut noll stöd för.

Subtimings

Du verkar sitta på en guldgruva med kunskap och potentiell latent prestanda här. Åter igen, jag säger inte emot dig då jag inte har någon data att backa det med. Om det du skriver ens är nära att stämma så lär andra reproducera resultatet givet magnituden på vinsten du hävdar finns. Jag intar en vänta-och-se på denna.

Det som luktar lite här är att oavsett vilken timing du refererar till så kommer DDR4 aldrig kunna matcha eDRAM i latens. Vinsten i7-5755C ser är helt klart mätbar men den är inte större än att en i7-6700K kommer kliva förbi om man utrustar den med riktigt snabbt RAM med låg latens.

Latens för skrivning är i de flesta fall mer eller mindre irrelevant då det finns en rad sätt att "gömma" latens vid skrivningar (samma sak gäller faktiskt diskar, optimera skrivhastighet/latens är ett "lätt" problem medan optimera läshastighet/latens är ett fundamental "svårt" problem).

Så i slutändan är det bara en enda egenskap som spelar roll för minnesoperationer: "load-to-use" latens (finns en stor anledning varför det är enda latens man listar i cache-design). D.v.s. tiden det tar från att CPU begär data från en viss cell till dessa att data ligger i ett CPU-register. Det är den latens AIDA64 och många andra försöker mäta.

Nomenklatur timings

Efter som du redan verkar lagt ned så mycket tid, kan du inte göra en kort summering av vad alla de olika subtimings-parametrarna betyder. Är ärligt intresserad och gissar att det även gäller andra. Har bra koll på vad siffrorna för DDR4 represterar, men kan inte påstå att jag greppar vad t.ex. "Trfc_SM" gör.

Advanced Memory Timings

tRRD Timing: (Act to Act Delay) Row to Row Delay or RAS to RAS Delay. The amount of cycles that it takes to activate the next bank of memory. It is the opposite of tRAS. The lower the timing, the better the performance, but it can cause instability.
tWTR Timing: (Rank Write To Read Delay) Write to Read Delay. The amount of cycles required between a valid write command and the next read command. Lower is better performance, but can cause instability.
tWR Timing: (Write To Precharge Delay)Write Recovery Time. The amount of cycles that are required after a valid write operation and precharge. This is to insure that data is written properly.
tRFC Timing: (Refresh To Act Delay) Row Refresh Cycle Timing. This determines the amount of cycles to refresh a row on a memory bank. If this is set too short it can cause corruption of data and if it is too high, it will cause a loss in performance, but increased stability.
tRTP Timing: (Read To Precharge Delay) Number of clocks that are inserted between a read command to a row pre-charge command to the same rank.

Below Values are not in ALL BIOS's (See Below link for a FULL List of Values)

tRTW/tRWT Timing: Read to Write Delay. When a write command is received, this is the amount of cycles for the command to be executed.
tRC Timing: Row Cycle Time. The minimum time in cycles it takes a row to complete a full cycle. This can be determined by; tRC = tRAS + tRP. If this is set too short it can cause corruption of data and if it is to high, it will cause a loss in performance, but increase stability.
tREF Timing: The amount of time it takes before a charge is refreshed so it does not lose its charge and corrupt. Measured in micro-seconds (µsec).
tWCL Timing: Write CAS number. Write to whatever bank is open to be written too. Operates at a rate of 1T, but can be set to others. It does not seem to work with other settings than 1T on DDR. DDR2 is different though.
Command Rate: Also called CPC (Command Per Clock). The amount of time in cycles when the chip select is executed and the commands can be issued. The lower (1T) the faster the performance, but 2T is used to maintain system stability. On Intel based machines, 1T is always used where the number of banks per channel are limited to 4.
Static tREAD Value: (tRD) This setting is most commonly known as Performance Level or tRD this is the most effective chipset performance register available to adjustment. As FSB and memory speed are scaled/increased, tRD and Northbridge voltage will have to be increased to accommodate the additional data throughput. The idea when tweaking your system for the BEST performance is to run the tightest (Lowest) tRD possible at any given FSB or memory speed. See Below Link for more reading on this

Fysikmotorer

Du är medveten om att det inte är raketforskning att reda ut vilken klass av instruktioner som en viss applikation använder? När sedan källkoden till flera av de vanligare fysikramverken finns tillgänglig är det rent trivialt att verifiera en sådan som om SIMD används eller ej.

Åter igen, det vad du som drog in fysikberäkningar i det hela, försökte hålla sådant utanför då det dels komplicerar frågan, dels flyttar fördelen åt "fel håll" (efter som de flesta är överens om att allt som gynnar Intels CPUer är "fel") och dels varierar mängden fysik som används rätt ordentligt. Realistiska bilspel har t.ex. väsentligt mer av den varan jämfört med typiska first-person-shooters eller RTS.

Sedan låter det lite skumt att nivån fysikmotorn jobbar på är relaterad till grafiknivån. Självklart finns vissa partikeleffekter som kan hänga ihop med grafiknivå, men rimligen görs den typen av beräkningar som shaders idag (framförallt givet hur CPU/GPU-balansen ser ut på dagens spelkonsoler och då resultatet ändå måste in i GPU för att renderas).

Det finns absolut en koppling mellan CPU-last och grafiknivå, men den handlar främst om att det är väldigt CPU-intensivt att sammanställa all information som ska skickas till GPU och den informationen är ju självklart beroende av grafiknivå (men i princip helt frikopplad från upplösning).

Men anta att TechPowerUp nu kör "medium" och anta vidare att nivån på fysik är hårt kopplat till grafikinställning (det är då ovanpå den last GPUn lägger på CPU). Givet Gustafsons lag borde skalbarheten med CPU-kärnor minska i 1280x720, fast vi ser ju att gapet mellan i3 och i7 är väsentligt större i 1280x720 än i 1920x1080 (vare sig man tittar på genomsnittlig eller lägsta FPS).

Infinity Fabric latens

I en diskussion kring core-to-RAM latens är saker som CCX-to-CCX latens rätt irrelevant. Ja, är fullt medveten om att CCX-to-CCX latens minskar med ökad RAM frekvens, men även där gäller att RAM-timings (utöver frekvensen) påverkar inte CCX-to-CCX latens.

Andra irrelevanta fakta (för det som faktiskt diskuteras) kring detta är att ring-bussen i S-serien ligger på en egen klockdomän, vill man riktigt pilla på latens kan man testa att dra upp den frekvensen då den har inverkan på core-to-RAM latens (och andra saker som L3$ bandbredd/latens).

Low 1 %

Glömde fråga detta i sista, vad du gör är alltså detta: tar alla scener, sorterar dem efter fallande FPS-värde och plockar ut scen 0.9*N som "1 % low" där N är totala antalet scener?

Vet att bl.a. Gamer Nexus gjorde fel på detta tidigare, de räknade ut ett geometrisk medelvärde på den procent scener med lägsta FPS. Det är fel. Gör man på rätt sätt får man den stora fördelen att enstaka avvikande värden har noll påverkan på 1 % low.

MindBlanks siffror

Exakt den här typen av diskussionen föregick även på 1800-talet. Till slut (1908) var det någon som lessnade tillräckligt mycket för att lura ut ett sätt att objektivt kunna uttala sig huruvida en uppsättning mätvärden faktiskt kan stödja en viss tes eller ej med någon rimlig säkerhet.

Vad jag i huvudsak hävdar här är: givet antalet mätvärden, deras inbördes spridning och magnituden på resp. mätvärdet så går det inte att dra en slutsats kring vilken av CPUer som presterar bättre. Det behövs mer data för detta.

Och i kategorin "märka ord", du har helt rätt i att Doom har en FPS cap på 200 FPS och Resident Evil 7 kan vara begränsad av både det enda och det andra. Men det enda som är relevant för diskussionen är: ingen av dessa är i det aktuella mätutfallet begränsade av CPU, något som manifesterar sig extremt tydligt i närmaste identisk prestanda oavsett CPU-modell (och det är rätt många med rejält varierande kapacitet som testades).

Och vilken "sida" tillhör man om man har flera ARM CPUer än x86, två AMD (varav en Ryzen) och fyra Intel? Det exkluderar allt jag har tillgång till på jobbet.

Haha, jag orkar inte ens längre Yoshman, du börjar babla om primärtimings igen trots att jag oavbrutet bankat in att det handlar om subtimings, hur svårt ska det vara att förstå skillnaden? Handlar det om någon slags oförmåga att begripa eller är det ren ovilja? Ändra subtimings själv och ut och bencha med din ryzen burk, det är inte svårare än så. Slår det slint i skallen eller vad är det frågan om? Prova att sätta tRDRDSCL & tWRWRSCL till 6 vilket är ett helt normalt värde för XMP profil, sätt det sedan till 2 och se vad som händer med FPS, denna inställning allena gör mer än primärtimings i fråga om FPS och tror du inte på detta är det bara & prova, inte svårare än så, kul va?
https://youtu.be/W2KhRPVGQYc

Buildzoid går igenom några subtimings så som tFAW och dess inverkan, även han säger med bara ett fåtal ändrade subtimings ser han 10% skilnad utan problem. Men det är klart, det är säkert hittepå.....
Här har du en bra genomgång av timings på Ryzen

Nej jag hävdar inte att techpowerups värden är oanvändbara, man ska bara förstå hur dom får fram dom och du kan fortfarande inte jämföra värden mellan olika testsajter i spel där man inte kör scriptade benchmarks, det funkar inte, inte på något plan, oavsett hur mycket du vill det. manuellt spelade och inspelade testrundor kan aldrig jämföras om dom inte utförs på exakt samma sätt. Sen ska man förstå vad som händer med spel när man ändrar ingame inställningar, 720p low är en ren dödssynd och det är även medium om jag ska vara helt ärlig, du påverkar saker som antal draw calls, geometri, texturhantering, asset streaming, fysik, draw distance osv osv. Alla dessa saker har enorm inverkan på cpu belastning och jag hoppas innerligt att du förstår det annars är nog hoppet ute...

Varför jag går i spinn, erm, det var du som försökte påvisa att timings inte alls gjorde så stor skillnad genom att jämföra 3600 med 3466vll, du förstår säkert mycket väl varför detta blir extremt missvisande i fråga om latensens påverkan i spelprestanda med frekvens & IF frekvens skillnad, eller vill du inte begripa det?

Sen har du grovt missuppfattat vad 0.1% low är, det är inte varje sekund det handlar om utan av totalt renderade frames, om du vill ha 0.1% frame variance så är det en annan femma och har i sig inte med FPS att göra men även det är inte varje sekund utan bara de största skillnaderna mellan olika frametimes under ett test, FPS som värde är i sig alltid ett genomsnitt för angiven tidsenhet, det är därför frametime kan plocka fram saker som göms av FPS som värde, att man sedan översätter frametime värdena till FPS värden för att folk lättare ska förstå är kanske inte helt konstigt.

Du bör dock veta att jag har kört varje testrunda 3 gånger med frametime inspelning och sedan använt medelvärde för alla tre rundor för varje värde, maximal variation mellan testrundor för samma inställning har legat <+-1% för alla värden, alltså rätt svårt att hävda någon enorm slags variation.

Jag undrar varför du vill leta fel i mitt testande, vad kan det bero på? Har du något behov av att hitta något fel? Har jag visat något du inte tycker om?

Som jag skrivit tidigare på mer än ett ställe så är 2666 på helt automatiska timings, 3333H är XMP profil med auto timings, 3333L är manuella timings/subtimings (med mer än en halvering av de flesta subtimings), 3466LL är i stort som 3333L vad det gäller timings.
Och nej TechPowerup kör primärtimings som är nära, subtimings däremot är milsvid skillnad. Kör man XMP profil ,vilket alla test ställen gör så kommer subtimings vara apdåliga, det är inte svårare än så. Sätter man manuella subtimings kan man tjäna runda slängar 10% prestanda i spel vid samma frekvens om man har b-die minnen.
Vad det gäller AGESA versioner så började slappa timings införas redan på 1.0.0.4, för att sedan ökas än mer på 1.0.0.6.

#17041465
Är korrekt, förutom att du medvetet utelämnar inverkan av minnesfrekvens på CCX latens trots att frågan var om både frekvens och latens, sen försöker du insinuera att Intel cpu reagerar likadant vid höjning av minnesfrekvens och du vet mycket väl att du lämnat ute CCX latens & L3 cache bandbredd från svaret. Är ditt svar fortfarande korrekt, nja inte direkt va?

Men gud va bra, du kan verifiera ditt uttalande om att spel är skalära heltal, då tycker jag att du ska göra det.

PS, du vill fortfarande inte ta i siffrorna från HW unboxed med Vega64? Vad beror detta på?