Här kommer två långa mestadels (men inte bara) OT-inlägg om statistik, som kopplar tillbaka till diskussionen vi haft tidigare i tråden om att modellera Ryzens prestanda statistiskt. Jag gör två inlägg för att dela upp resonemanget i subtopics. Det finns två take-home messages:
1.
Det är visserligen ett problem när vi inte kan uppskatta hur tillförlitliga våra resultat är mha p-värden (som är ett uttryck för sannolikheten att få ett resultat även om det i verkligheten inte finns något att upptäcka, dvs att vårt fynd är en "falsk positiv"). Men jag tycker inte att det är ett stort problem i detta fall, och jag tycker att de metoder som är mindre känsliga för detta ofta har andra nackdelar. Mer om det i nästa inlägg. Grundproblemet är att de mest utvecklade statistiska testerna antar att data är normalfördelat, något som är vanligt i naturen men ovanligt i tekniska system som processorer. Detta gör att de p-värden vi får av regressionsmodeller inte är så pålitliga. Å andra sidan så är tekniska system rätt så förutsägbara när det gäller dos-respons, alltså hur mycket tex clock och beräkningsprestanda samvarierar. Ofta kan sambanden beskrivas med rätt så enkla matematiska uttryck inom rimliga intervall. Koefficienterna för de olika prediktorerna är därför väldigt tolkbara. En annan viktig notering är att vi jobbar med a) parametrar som är ingenjörsmässigt bestämda, tex frekvens som styrs av en klocka, b) utfallsmått som redan är resultatet av tester designade för att minska osäkerhet, prestandatester. Det är lätt att glömma när man tittar på en vektor med siffror, men de FPS-resultat vi har är ju medelvärden av ganska långa förutsägbara körningar av specifika spel under specifika förutsättningar, designade för att ge just tillförlitliga resultat. Det finns alltså redan en robust brusreduktion inbyggd i testerna, oavsett om vi tittar på medel-FPS eller lägsta 5%en FPS. Därför har vi samtidigt en lyx vad gäller förutsägbarhet som en naturvetare knappast kan drömma om. Det stora problemet är istället ett annat:
2.
Det vi normalt frågar när vi gör en hypotesprövning är om det resultat vi har kan generaliseras till andra jämförbara fall. Det är hypotesprövningens koppling till modelleringen - om vi klarar hypotesprövningen (modellen och våra prediktorer är signifikanta) så vågar vi generalisera vårt resultat till en ny processor. Men vi kan strikt sett bara generalisera till processorer som inte är mer annorlunda från de processorer vi byggt modellen på, än dessa är från varandra, på alla tänkbara parametrar (tyvärr inte bara de vi lyckats mäta). På statistikspråk: vi kan bara generalisera till den population som vårt sampel (de processorer vi faktiskt valt ut) kommer från. Där har vi ett problem om vi ska modellera Ryzen, då denna som bekant är en helt ny arkitektur, och alltså kan sägas tillhöra en ny population. Detta är egentligen okontroversiellt och välkänt - men det jag vill lyfta fram är att när vi diskuterar signifikanta och icke-signifikanta prediktorer så diskuterar vi möjligheten att generalisera, och den möjligheten har redan stora begränsningar i att vi inte vet vad vi generaliserar till. Att blanda in Bulldozer tror jag inte heller hjälper här, då den arkitekturen är ännu mer annorlunda. Detta är alltså ett problem som inte kan avhjälpas med tex icke-parametriska metoder, då dessa bara handlar om att reducera risken att enstaka cases (processorer) gör modellen instabil.
Dessa är antaganden som föregår mycket av diskussionen om linjära vs icke-linjära, parametriska vs icke-parametriska, metoder. Vad gäller hypotestester så tror jag att vi är lost oavsett väg - jag tror att vi har mycket mer ut av att titta på faktiska bidraget av olika prediktorer (tex GHz och antal hårdvarutrådar) och försöka uppskatta hur mycket den motsvarande bidrag kan avvika i Ryzens fall, baserat på vad vi vet om arkitekturen och common sense. Ovanstående är dock mindre kritik mot @Yoshman s modell än mot min tidigare. Yoshman utgår enbart från intelprocessorer, även om processorbasen är smal så tror jag att det är bättre än att bjuda in ännu fler obekanta mha andra arkitekturer. Sedan beskriver han syftet som att modellera skalning mellan olika Ryzen baserat på hur (så långt vi kan gissa) liknande intelprocessorer skalar gentemot varandra. Det är en enklare och mer lovande frågeställning, som tar bort en hel del av den bias som kan introduceras bara utifrån att Ryzen är något annat än Core. Först några kommentarer och svar på Yoshmans frågor:
Skrivet av Yoshman:
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.
Om en enkel transformation, typ logaritm eller 1/x, får sambandet att bli linjärt så är det överlägset ickelinjära metoder, törs jag nästan påstå utan att vara bevandrad i så många av dem. Det är naturligtvis också en fråga vad man är ute efter, men vi är här ute efter att modellera just linjära eller i varje fall tolkbara samband, och då är minsta kvadratanpassning att föredra. Dummyvariabler är som du skriver alltid linjärt relaterade till Y då de bara har två värden, men inte sällan kommer de till som en lösning på icke-linearitet. Att välja en cutoff och dela upp en variabel i hög och låg kan vara ett sätt att göra hopplösa variabler användbara.
Citat:
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.
Det allra viktigaste antagandet för en linjär regression är att residualerna, dvs skillnaden mellan de predicerade värdena och de verkliga, blir normalfördelade. Normalt är det inga problem med kontinuerliga prediktorer eller utfallsmått som inte är normalfördelade, så länge residualerna är det. I din beräkning i inlägg #16661090 kan man se under "residuals" att Min - Max och 1Q - 3Q båda ligger hyfsat nära noll. Ser residualerna ok ut så är oftast modellen ok, både ur ett modelleringsperspektiv och ett statistiskt perspektiv. Det är det bästa quick-and-dirty sättet att kolla, sen kan man vara ganska lugn med övriga antaganden.
Mätfel är inte jätterelevant här, det fel som spelar roll statistiskt är okända tredjevariabler som stör sambanden. Modellen skiljer inte på mätfel i en prediktor och felvarians i hur just denna prediktor relaterar till utfallet givet interaktion med en massa andra parametrar (egenskaper hos just den processorn eller speltestet) som vi kanske inte har mätt. Det finns säkerligen modeller som tar hänsyn till enskilda variablers mätfel givet att mätfelets fördelning är känd, men det är inget som jag känner till konkreta exempel på. Du har en poäng i att just sådant som turbolägen för in ett delvis känt mätfel, vars storlek dessutom interagerar med antal belastade kärnor. Så det går kanske att justera GHz-värdet för detta mha någon smart algoritm, det hade varit lite intressant att titta på just i detta fallet.
Citat:
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.
Nja, det du beskriver känner jag inte till, tänker du på det som kallas "homogenity of variances"? Det har att göra med variansen i en prediktor ska vara ungefär densamma oberoende av nivå på utfallsmåttet, alltså att molnet i en scatterplot mellan en prediktor och Y inte ska vara skevt. Detta krav bryter man ganska ofta mot, jag tror att det bara stör hypotestesterna, inte modellprediktionen. Jag tror inte att det finns något problem relaterat till att olika prediktorer har olika varians, så länge de har varians tillräckligt mycket större än 0. Nu pratar vi alltså om mellanindividvarians (variansen av de olika klockfrekvenserna för de olika processorerna) snarare än mätfelsvarians. Det senare är inget som modelleras specifikt som sagt, all felvarians klumpas ihop i modellen. Men mätfelen i dessa fall är som du skriver antagligen försumbara.
Citat:
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?
Dessa är ju mått på hur långt ifrån en perfekt modell (där prediktionen alltid stämmer dvs residualerna är 0) vi befinner oss. Adj-R2 justerar för det faktum att även om vi lägger till en prediktor som bara är brus så kommer R2 att gå upp i alla fall, då det alltid finns någon del av bruset som hjälper prediktionen. Adj-R2 går upp bara om prediktorn faktiskt tillför något (prediktorn behöver inte bli signifikant i t-testet för detta). Predicted R2 är nytt för mig men verkar ha ett annat syfte, att upptäcka overfitting. Det är när modellen generaliserar dåligt till nya fall, pga att den plockar upp även irrelevanta egenskaper som kanske just i dessa processorer bara korrelerar med relevanta egenskaper, men inte i de processorer vi vill generalisera till. Den risken är självfallet högre i små dataset, och här har vi bara ett ändligt antal processorer som är jämförbara. Få cases är, som @sAAb skriver, ett problem. Det kopplar till det andra problemet jag tog upp, att vi just nu använder modellerna för att generalisera till en helt ny typ av processor, nämligen Ryzen.
Citat:
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).
Jag tror att detta är rimligaste approachen att förutsäga Ryzens prestanda, att modellera utifrån de processorer vi känner till som är liknande på flest parametrar. Därför håller jag med om att enbart intelprocessorer är en bättre bas än att blanda in Bulldozer et al. Men här är overfitting också ett problem, eftersom Ryzen strikt sett inte kommer från samma population som de processorer vi utgår från. Det kommer att finnas systematiska skillnader mellan Ryzen och dessa Intelproppar, och ju fler parametrar i modellen som på ett ännu okänt sätt skiljer sig mellan intel och Ryzen, desto fler parametrar kan göra att vår prediktion slår fel för Ryzen. Så det kan visa sig att den bästa modellen kanske snarare är en minimal modell som bara har med log(cores) och clock.
Skrivet av Yoshman:
Du får tänka på att jag ser detta från perspektivet av vad mina antaganden betyder ur ett linjäralgebra-perspektiv, kan mycket väl göra vurpor i statistikdomänen.
Min modell ser ju ut så här
FPS = a * FREQ + b * log(CORES) + f1 * HAS_EDRAM + f2 * IS_SKYLAKE + f3 * HAS_SMT + g1 * IS_BF1 + g2 * IS_TOTAL_WAR_WARHAMMER + g3 * IS_FALLOUT_4
a är responsen mot frekvens och frekvens är en variabel som har flera värden, b är respons mot antal kärnor (logaritmen av antal kärnor).
Övriga ser jag så här: de är egenskaper som endera är falsk (bidraget noll) eller sant. För fN är responsen hur mycket det påverkar FPS i genomsnitt.
För gN ser jag det i stället så här: jag antar att responsen från övriga relativt sett är ungefär densamma oavsett speltitel. Till skillnad från fN där alla N kan vara sann/falsk för en viss mätpunkt kan bara exakt en eller noll (för Witcher 3) av gN vara sann.
Värdet på gN blir då rent matematiskt antal FPS som detta spel i genomsnitt ligger över (värdet positivt) eller under (värdet negativt) Witcher 3 (d.v.s. parallellförskjutning av den linje som beskrivs av övriga variabler). Vinsten är då att jag får fyra mätpunkter för varje CPU-modell (en per speltitel) i stället för en enda -> förhoppningsvis en mer stabil modell.
Mätvärden kommer från 1280x720 testerna här.
Har med 7700K, 6700K, 6900K, 6950X, 5775C, 4790K, 7600K och 6600K.
Ok, då gör du som jag trodde! Jag vet inte, detta kan vara rimligt även statistiskt. Vad som är best practices är ganska fältspecifikt. Problemet som uppstår när man har flera mätvärden från samma analysenhet (i detta fall CPUmodell) är att hantera det faktum att varje CPUs värden på ett test sannolikt korrelerar med samma CPUs värden på ett annat test. Men som du beskriver det, och jag håller med matematiskt, så låter det som att din modell hanterar detta. Senaste trenden i natur- och samhällsvetenskaper angående detta är det som kallas mixed-effects-modeller (paketen nlme eller lme4 i R). Men jag är inte säker på att dessa tillför något mer i detta fallet jämfört med din metod.
Citat:
Steget från två till fyra kärnor är i min modell större än steget från fyra till åtta, detta då log(4)/log(2) = 2,0 medan log(8)/log(4) = 1,5. D.v.s. steget från två till fyra är 2,0 / 1,5 ger 33 % högre boost än steget från fyra till åtta. Det är också vad som är fallet i praktiken (d.v.s. det är avtagande effekt av att dubbla antal kärnor ju fler man går från). Det stämmer också med vad Amdahls lag säger.
Men stämmer detta verkligen, skulle inte en linjär modell (utan log) göra så att steget från 2 till 4 är lika stort som steget från 4 till 6? Jag trodde det var poängen, att logaritmeringen gör att vi får veta responsen i FPS på varje fördubbling av prediktorn snarare än vid varje konstant ökning. Det kan dock vara jag som är för trött eller för matematiskt okunnig här.
