::: AMD Zen Samlingstråd :::

Är ganska säker på att om 10 GB används av Windows och program, så används resterande 6 GB som diskcache (Cachelagrat), så jag tror att allt ditt minne används.

Upp till bevis!😁

@yoshman
Jag var också inne på att göra L3/eDRAM till dummies, vilket med FX-processorerna och haswell/broadwell skulle kunna ge en uppfattning om dess betydelse.

En intressant frågeställning är Hur antalet kärnor skulle påverka resultatet för 5 resp. 10 år sedan. Det skulle ge en fingervisning om hur utvecklingen mot multitrådat går.

Magkänslan med bas och turbofrekvenserna säger mig att RyZen inte är någon jätteklockare. Kommer man upp i 4.5GHz ska man vara glad. Hoppas jag har fel...

Svårt att säga.
"1800X" verkar ju köras i 3.6GHz/4.0GHz vilket är mer än Intel 6900K's 3.2/3.7GHz.

Men ja det ser ju lite oroande ut för varianterna med färre kärnor.
Dock så är ju inte basfrekvenser särskilt representativa för hur mycket en processor kan klocka, ta Sandy Bridge som ett exempel med Intel Core i5 2500K som i stock körs i 3.3/3.7GHz men oftast kan nå 5.0GHz med rätt kylning trots det

Jo det är sant att den ändå är snabbare än 6900K

Min 2600K går ju i 4.7GHz svalt och gick att skrämma upp i 5.2GHz på luft. Men efterföljande arkitekturer klockade inget vidare förrän nu. Om AMD och Ryzen vet vi nästan ingenting.

Får avvakta och se vilken modell det blir. Tycker 1700 är rätt imponerande med sina 65W.

Ryktet säger att Ryzen går att köra i 5Ghz med luftkylning. Dock osäkert om det gäller alla 8 kärnor.

@Sisyfos: Jepp. Med tanke på officiell boost lär vara 4Ghz för 1800x så känns inte 4.5-4.7 på alla kärnor vara utom räckhåll. Iallafall om man får ett bra chip.

Frågan är lite hur XFR fungerar. Säger bara >4.0Ghz beroende på kylning och jag hade varit intresserad av att veta hur aggressiv den är. Kanske drar upp den 10% direkt bara man har en bra luftkylare.

Det enda jag egentligen vet om XFR är att den stegvis ökar med 25 MHz, sen antar jag även att det går hyfsat snabbt att stega upp. Men det är ingenting jag egentligen vet något om.

Här är samma två modeller som i mitt tidigare inlägg, med p-värden och sida vid sida tack vare att jag just lärt mig en massa om bbcode av @sAAb (jag trodde jag skulle kunna redigera mitt gamla inlägg, men det gick visst inte längre, så jag upprepar dem här).

I tredje modellen längst till höger testar jag en annan modifikation. Tittar man på fördelningen av FPS så finns en tydlig outlier, A6-7400K med 55FPS. Den är också en outlier i modellen, den får ett modellerat värde på över 100 medan dess verkliga är 55. Regressionsmodeller är känsliga mot sådana outliers, och utan den får vi ganska annorlunda värden.

FPS (Alien Resurrection) ~ GHz + BDCores + Threads + L2 + L3 + Series VS modellen utan L2 VS modellen utan L2 samt utan A6-7400K (dvs 1 processor borttagen)

Nu är Bulldozer referenskategori, så det bör vara mer jämförbart med din tidigare beräkning. Det som också skiljer, som jag glömde skriva, är att variabeln litografi inte är med - jag vet inte vad det är eller hur det ska beräknas. Men det är nog den som gör att de olika arkitekturerna inte jämför likadant mot varandra, i din modell som i min vänstraste ovan. Det som dock är intressant är att nyttan av flera cores (fortfarande räknat som 1BD-modul = 2 cores) halveras då vi tar bort en processor längst ner i spannet som knappast någon som läser detta forum skulle överväga att köra spel på. Jag skulle säga att modell 3 är mycket mer relevant att tolka än modell 2, då den inte påverkas lika mycket av något enskilt värde. (Det visas också av att den har mer normalfördelade residualer, för den tekniskt intresserade). Effekten av antal cores är i den närmare 5 FPS/kärna än 10.

Ett separat problem med L3-storlek är att värdet är 0 för alla Bulldozer med efterföljare. Så ska man räkna på cachestorlek så behöver man nog räkna Bulldozers L2 som L3, och evt dividera med kärnor. Ett annat sätt vore att normalisera chachestorleken genom att dividera varje Intel-processors cache med genomsnittet för alla Intel, och likadant med AMD (här kan vi välja största cachen eller summan L2+L3). Då får vi ett mått på hur prestanda skalar med cachestorlek som inte bär med sig IPC-skillnader mellan AMD och Intel. Jag har dålig koll på eDRAM men jag ser att @Yoshman undersöker det.

Absolut - detta är en mycket viktig poäng. Hälften av processorerna i datasetet har en FPS i spelet mellan 177 och 180. Dessa är sannolikt GPU-bundna och vi skulle nog bara hitta brus, så det är inte direkt meningsfullt att undersöka dem. Några proppar i toppen ligger kring 182, men det känns som att skillnaden mellan 179 och 182FPS är helt en funktion av någon feature som har med minnesaccess att göra (eDRAM?), snarare än antal cores eller klock. Så det är definitivt värt att titta på enbart den lägre halvan, de proppar som ligger under 177 fps (jag visar R-output direkt likt @Yoshman, sista kolumnen är p-värdet för den som är intresserad, "Estimate" är det vi jämför.):

lm(formula = FPS ~ GHz + Threads + S_, data = cpubound)

Residuals:
    Min      1Q  Median      3Q     Max 
-7.6580 -3.7526 -0.2471  1.2206 12.5490 

Coefficients:
               Estimate Std. Error t value Pr(>|t|)    
(Intercept)      16.316     14.029   1.163 0.258507    
GHz              23.402      2.567   9.118 1.46e-08 ***
Threads           4.567      1.046   4.368 0.000298 ***
S_Steamroller    17.440      7.393   2.359 0.028614 *  
S_Haswell        50.506      8.389   6.020 6.93e-06 ***
S_Piledriver     16.265      7.037   2.311 0.031592 *  
S_Sandy Bridge   43.170      8.234   5.243 3.94e-05 ***
S_Skylake        53.583      7.244   7.397 3.83e-07 ***
---
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 5.811 on 20 degrees of freedom
Multiple R-squared:  0.9289,	Adjusted R-squared:  0.904 
F-statistic:  37.3 on 7 and 20 DF,  p-value: 3.989e-10

Jag räknar här på hårdvarutrådar enbart, baserat på att dessa övervägande 4-kärniga proppar nog fort blir mättade på trådar. HT representeras inte alls då endast en processor saknar det (Pentium Gxxx). L3 närmade sig multikollinearitet och bidrog inte heller med förklaringsvärde. Siffrorna är som synes inte helt olika föregående modell - troligen för de processorer som utelämnats diskriminerar dåligt då de de är GPU-bundna. Men detta är som du säger självfallet mer relevanta data att titta på om vi vill veta något alls om CPUers förmåga i spel.

Log2 är nog inte alls dumt, jag tror dock att just för spelfrågan kan det vara ännu mer informativt att titta på hoppet 2-4 cores vs 4-flera, för ett spel där det gör någon form av skillnad. Alltså en dummy för hur mycket 4 cores gör över 2, och en för hur mycket 6-10 gör över 2. Just eftersom det är den gränsen som folks köpbeslut tenderar kretsa kring. Jag var på väg att göra det men just i denna datamängden är det meningslöst, då alla CPUer med mer än 4 cores ligger i taket på FPS.

Kom just på en intressant aspekt.

Är det rätt att Sweclockers testar med XFR aktiverat?

Om XFR sker automatiskt så är det något en icke överklockare också kommer dra nytta av.
Så det är i princip en fancy CPU boost funktion men blir kanske lite skevt när det är kylningsberoende (iofs så är alla OC tester det)

Eller måste Sweclockers ha tre olika staplar?

Exempel:

1800X (Stock, no XFR)
1800X (XFR)
1800X (Manual OC)

vad tror ni?

Kraven om man gör linjärregression är:

Det ska vara linjära samband mellan storheterna. Tror vi kan vara rätt överens om att det är rätt linjär respons på frekvens.

Just detta krav gör att man inte kan använda kärnor direkt, det fungerar bara för saker som skalar perfekt med CPU-kärnor vilket inte är fallet för spel. Amdahls lag sätter en övre gräns för skalningen, tyvärr är "p" värdet rätt svårt att veta men en logaritmering av antal kärnor ger i alla fall en betydligt rakare linje när det plottas mot FPS.

Så här ser jag inte alls hur icke-linjär regression skulle hjälpa då det är ett linjärt beroende mellan FPS och frekvens samt FPS och logaritmen av antal CPU-kärnor (stämmer rätt bra om amdahls "p" värde inte är nära 0 eller 1).

Övriga parametrar är dummys, så finns bara två nivåer. Är som sagt riktigt rudis på statistik, men ser inte hur en icke-linjär regression skulle hjälpa då. Rent linjäralgebraiskt betyder "linearitet" här att det alltid är samma boost av att lägga till eDRAM, samma boost av att lägga till SMT, etc. Det antagandet lär vara en rätt bra abstraktion av verkligheten.

Nästa krav är att värdena ska vara normalfördelade. Det är absolut en viss osäkerhet både i FPS och CPU-frekvens, har använt max turbo när alla kärnor är aktiva och den verkliga frekvensen kommer i praktiken pendla både över och under detta värde (fast inom ett väldigt smalt område).

Kan man inte se antal kärnor som ett värde med mätfel noll? I det läge kvittar det ju om det är normalfördelat eller ej då det alltid blir samma värde.

Nästa är att det inte ska finnas multikollinearitet mellan de oberoende variablerna. I de jag valt finns inget sådant, eventuella effekter av L3$, minnesbandbredd etc är inte modellerade specifikt utan de blir del av antal CPU-kärnor och eventuell eDRAM.

Sista antagandet är att de ska vara ungefär samma nivå på variansen hos de oberoende variablerna. Det stämmer inte, men å andra sidan är det rätt litet absolut fel i alla oberoende variabler här.

Förstår inte din kommentar om "dött lopp", det var ju ett räkneexempel. 4,5 GHz är ju 33 % högre än 3,5 GHz men ger en respons på 21 %. 8 kärnor är 100 % fler än 4 kärnor (i logaritmiskt skala skiljer det 50 %) och ger 16 %. Skulle säga att responsen är rätt olika mellan dessa, eller tänker jag fel här?

Ett sätt att testa sin modell är ju att titta på värdet av "R-square", än mer på "adjusted R-square" och kanske mest på "predicted R-square". Dessa är 95 %, 94 % samt 90 % vilket pekar på att modellen beskriver data väldigt väl och de två sista visar att det inte är en effekt av att modellen har allt för många oberoende variabler. Eller det också en tankevurpa?

Alla frågor ovan är verkligen riktigt och ärliga funderingar, är som sagt rejält grön på detta.

Det är absolut ett problem att det är väl få mätvärden, var därför jag tog in flera spel (fler mätvärden per CPU-modell) och tog bort CPU-modeller (mindre risk för överbestämd modell p.g.a. allt för många oberoende variabler).

Om vi nu antar att Ryzen får en IPC motsvarande Haswell/Broadwell är ju de mest intressanta datapunkterna hur steget från Haswell/Broadwell, steget mellan 4,6 och 8 kärnor samt effekt SMT påverkar spel (eDRAM är mest för att i7-5775C inte ska bli en sådan outlier). Men finns självklart massor med osäkerhet ändå, både i modellen och hur bra approximation Haswell/Broadwell IPC är för Zen (tror själv fortfarande Ryzen kommer ligga närmare Ivy vid heltalstunga laster, andra är redan säkra på att det blir Skylake IPC).

Är bara de senaste åren som spelmotorerna börjat använda work-stealing schedulers som grundläggande metod för att sprida last, en metod som teoretisk kan skala till hur många CPU-trådar som helst givet tillräckligt med "work". Tidigare var det väldigt mycket ad-hoc tekniker som sällan skalade förbi två-tre CPU-kärnor och i princip aldrig förbi fyra.

Blir inte problemet med en L3-dummy att den blir allt för svår att skilja från antal CPU-kärnor? Är ett linjärt samband mellan total L3$-storlek och antal kärnor sedan Nehalem. Vidare verkar ju RAM-hastighet spela en hel del roll för spel om man är CPU-bunden, det är ju också lite lurigt att ta hänsyn till.

eDRAM har väldigt hög latens, så är nog mer en booster av genomsnittlig RAM-bandbredd än något annat. Det är hela poängen med eDRAM, ge långt högre bandbredd till iGPU. Är garanterat den höga latensen som gör att nästan inga "vanliga" applikationer ser någon vinst av eDRAM (finns vissa program som har en svag negativ effekt från eDRAM då latens mot RAM ökar när man har eDRAM).

Den verkliga formeln här är ju

S(c,p) = 1 / (1 - p + p / c)

Där p är andelen av programmet som kan köras parallellt (antagandet är att de är oändligt parallellt, vilket gör formeln till en övre gräns) medan c är antal CPU-kärnor. S är då maximal "speed-up" man kan få över ett system med en CPU-kärna.

Inom ett rimligt intervall är log(c) en bra approximation. Responsen blir då 100 % om man går från två kärnor till fyra (log(4)/log(2) = 2), fyra till åtta blir 50 % (log(8)/log(4) = 1.5). Detta matchar ungefär ett p värde på 0.88 vilket kanske är lite optimistiskt idag...

Det stora problemet, förutom att vi har få mätpunkter, är just det sista du skriver här: GPU är en flaskhals även vid de lägsta upplösningarna och den totalt dominerade flaskhalsen vid normala upplösningar. Så dessa modeller vi tar fram blir i praktiken ändå rätt meningslösa. Men ett kul sätt att slå ihjäl tid

SweClockers testade, precis som de flesta andra, Broadwell-E med Turbo boost 3.0 avslaget. Tror inte SweClockers skrev varför men andra skrev att det blev större varians i resultaten med det påslaget. Tror det bara var TomsHardware som hade TB3.0 på, det gör en hyfsad skillnad i testerna som är enkeltrådade.

Möjligen kan XFR ge samma varians.

Personligen vill jag se testerna gjorda med TB3.0 påslaget och XFR påslaget, varför skulle man inte köra så om man har möjligheten?

De borde enligt mig testa CPUn som det levereras. Alltså om XFR finns så ska det vara igång. Det innebär dock att skillnaden mellan XFR och överklock kanske inte är så stor som tidigare, vilket förmodas vara poängen.

Det vore dock trevligt att se stock i något test, framförallt om alla Ryzen jämförs mot varandra, eller när just featuren XFR testas.

På en server håller jag med, där är oftare Gustafsons lag mer relevant. Nyckelfaktor är att du som operatör är i kontroll av storleken på problemet som ska hanteras.

På skrivbordet och specifik för spel: Gustafsons lag är irrelevant då du som användare har noll kontroll över storleken på "working-set", det dikteras helt av den applikation du kör vilket gör Amdahls lag till det din skalning dikteras av.

Gustafsons lag: så här stor måste den parallella delen av din uppgift vara för att nå en viss speed-up på ett system med C kärnor (man antar att den parallella delen skalar med storlek på problemet medan den seriella delen är konstant)

Amdahls lag: givet ett visst problem, det här är den högsta speed-up du kan få från ett system med C kärnor.

Jag som sagt ligger på 4,3 GB använt ram med Windows och antal program igång.

Var uppe i 7,5Gb och sen kracha spelet (hann köra 10min innan det slog i taket). Kunde öka virtuella minnet som tillfällig lösning. Var evolv, inte det mest buggfria spel. Men nu har man så det räcker ett tag i alla fall , kan ju inte få för mycket ram:p

Skickades från m.sweclockers.com

lm(formula = FPS ~ GHz + Threads + S_, data = cpubound)

Residuals:
    Min      1Q  Median      3Q     Max 
-7.6580 -3.7526 -0.2471  1.2206 12.5490 

Coefficients:
               Estimate Std. Error t value Pr(>|t|)    
(Intercept)      16.316     14.029   1.163 0.258507    
GHz              23.402      2.567   9.118 1.46e-08 ***
Threads           4.567      1.046   4.368 0.000298 ***
S_Steamroller    17.440      7.393   2.359 0.028614 *  
S_Haswell        50.506      8.389   6.020 6.93e-06 ***
S_Piledriver     16.265      7.037   2.311 0.031592 *  
S_Sandy Bridge   43.170      8.234   5.243 3.94e-05 ***
S_Skylake        53.583      7.244   7.397 3.83e-07 ***
---
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 5.811 on 20 degrees of freedom
Multiple R-squared:  0.9289,	Adjusted R-squared:  0.904 
F-statistic:  37.3 on 7 and 20 DF,  p-value: 3.989e-10

"Regressionsmodeller är känsliga mot sådana outliers, och utan den får vi ganska annorlunda värden."

Därför är de femtielva varianterna av robust regression i (gratis) R (eller svindyra moduler i SPSS eller S á 30 000 Kr eller något i den stilen) ett överlägset verktyg i många sammanhang. Robusta metoder ger tusan i "outliers". Medelvärdet är sjukt känsligt. Medianen är så robust att man kan ha upp till 49,99 % felaktiga data utan påverkas.

Traditionell regression är lika känsligt som medelvärdet; två diagram från http://fedc.wiwi.hu-berlin.de/xplore/tutorials/xaghtmlnode11....

[EDIT 2017-05-12 Hänvisning till archive.org

https://web.archive.org/web/20100316070901/http://fedc.wiwi.h...

END EDIT]

Först, minsta kvadratmetoden.

Kör man en av de icke-parametriska metoderna så blir det mer rimligt.

Hur tydligt kan det bli?!

Problemet är att om man har tröskelvärden ... så kan dessa ignoreras. Men, är man medveten om det så går det "säkert att fixa".

Fick öka virtuellt minne, så fungerade spelet. Men är ju uppe i 8/9GB max i ett spel, så ja man kan inte få för mycket ram:) 16GB kommer troligen i framtiden inte räcka alla gånger.

Skickades från m.sweclockers.com

Nä, vem kan hålla sig? Precis, att lösa ut koefficienterna (det vi är intresserade av här) är exakt och bara det du beskriver, resten av regressionsanalys är statistiskt lull-lull som mest intresserar oss samhällsvetare

Call:
lm(formula = FPS ~ Frequency + log(Cores) + eDRAM + Skylake + 
    HT + BF1 + TWW + FO4, data = cpus)

Residuals:
     Min       1Q   Median       3Q      Max 
-21.5523  -5.7320  -0.4611   7.1173  17.3971 

Coefficients:

Ser tolkbart ut av din diskussion att döma, och residualerna ser fina ut, men jag förstår inte riktigt hur du bygger modellen. Förekommer varje CPU flera gånger i datamängden, med en rad för varje CPU och spel? Dvs spelen är kovariat för att ta bort inomindividvariansen? Jag kan se hur det skulle kunna fungera, men känns inte helt kosher från hur statistik lärs ut i samhällsvetenskaperna, som jag är van vid. Men för den skull behöver det inte vara fel.

Snackar vi log2(cores) här, dvs steget från 2 kärnor till 4 gör lika stor skillnad enligt modellen? I så fall läser jag det som att för denna workload så är att lägga en andra tråd på en redan belastad kärna bara en %-enhet sämre än att starta en ny kärna, dvs nästan försumbart.

Tack för BBcode-skolan! Hittade också ett onlineprogram som genererar tabeller utifrån .csv mm: http://theenemy.dk/table/

Ok, var väl vt-d som saknades på q6600. Min Xen-rigg kör numera KVM och vfio, med det blir GPU-dedikering mycket smidigt. Men 16 kärnor (Opteron Magny-cours x2) var overkill 2012 och är delvis idag, jag kommer aldrig till scenarier där jag nyttjar alla trådar. Jag var lite tidig med min prediktion att revolutionen mot trådbredd snarare än mer singeltrådprestanda skulle komma. Processorerna kom från Ebay, planen var att byta mina 6134 på 2.3GHz/tråd när Bulldozer kom, men när den inte riktigt uppfyllde förväntningarna så iddes jag inte. Det blev ett par beggade 6140 (också pre-BD, 45nm) på 2.6GHz/tråd senare, de kör jag på nu, med 32Gb ram. Sett till mina workloads hittils har 16 hårvarutrådar inte varit ett signifikant lyft över 8, även med en spelrigg körandes på halva burken. Men jag tror att det kan ändras framöver när 6+kärniga processorer blir billigare på desktop, och mjukvaruvärlden anpassar sig. Dessutom finns väl ett fysiskt GHz-tak någonstans. Så Ryzen är väldigt lockande då man ju inte vill gå ner i antal hårdvarutrådar vid en uppgradering

Men den stora begränsningen jag har nu är såklart singeltrådprestanda, då 2.6GHz generation 2009 inte räcker särskilt långt. Jag har dock klarat mig rätt bra rätt länge ändå, och 5 års livslängd är helt ok för en arbetsstation. Punktgissningen nu är väl att nästa steg blir en 1700X, om inte 1800X får fler PCI-e, men det är ett fönster på några veckor som det ännu kan ändras (vill gärna hinna se någon verifiera att IOMMU fungerar, tex).

Sen har jag en del att säga om antaganden och parametrisk vs icke-parametrisk statistik, men jag tar det senare

Nya benchmarks