Statistik för tester av grafikkort och processorer är vilseledande

Permalänk
Medlem

Statistik för tester av grafikkort och processorer är vilseledande

Under det senaste halvåret har jag medverkat i flera diskussioner i Sweclockers forum om olika jämförelser av prestanda mellan olika komponenter i datorer. Nu senast gällde det IPC och hur den varierar mellan olika processorer, minnen, mm.

I den senaste diskussionen med främst @Yoshman lyfte jag att när man jämför relativa data så måste man använda ett geometriskt medelvärde

Jag har insett att det här inte har varit självklart, t.ex. när man gör jämförelser av grafikkort, processorer eller minnen, men det är en viktig och relevant skillnad mellan den "vanliga" (dvs. det aritmetiska) medelvärdet och det geometriska medelvärdet. Det aritmetiska medelvärdet visar inte vad folk tror att det visar; det saknar validitet i vissa sammanhang.

Orsaken att jag ställer det här till redaktionen är att mitt intryck är att Sweclockers prestandaindex för processorer eller grafikkort bygger på aritmetiska medelvärden och har flera artiklar som bygger på det, när det borde ha byggts på det geometriska medelvärdet. På http://www.sweclockers.com/artikel/18402-sweclockers-prestand... kan man läsa

Citat:

Observera att SweClockers prestandaindex är ett "medelvärde av medelvärden", alltså en mycket förenklad bild av verkligheten. Även om tabellen är bra för att snabba jämförelser är resultatet beroende av bland annat drivrutiner och vilka speltitlar som används. Läs hela artiklarna för att få den kompletta bilden.

Den stämmer alltså inte utan Sweclockers ger en felaktig och missvisande bild, trots ordet "förenklad", om den inte omarbetas med det geometriska medelvärdet.

Den skillnad som finns mellan olika medelvärden beskrivs i:

Smith, James E. "Characterizing computer performance with a single number." Communications of the ACM 31.10 (1988): 1202-1206.

Den finns att läsa på https://www.cs.auckland.ac.nz/courses/compsci703s1c/resources...

Skillnaden mellan dessa är principellt stor, men ibland liten i magnitud. Ett exempel som kanske är tydligt är vad är medelvärdena för de två olika metoderna i två olika fall, - (A) 1, 2, 4 samt (B) 1, 10, 100. I båda fallen har vi en tänkbar serie av formen x^y, vilket är i princip hur datorers prestanda förändras. Men, enbart geometriska medelvärdet kan fånga det.

Aritmetiskt medelvärde
A: (1+2+4)/3 = 7/3 = 2,333...
B: (1+10+100)/3 = 111/3 = 37

Geometriskt medelvärde
A: (1*2*4)^(1/3) = 2
B: (1*10*100)^(1/3) = 10

Det är kanske inte självklart, men alla jämförelser mellan grafikkort, processorer eller minnen där man presenterar resultat i procentform eller med ett annat relativt måste använda ett geometriskt medelvärde. Annars ljuger man, medvetet eller omedvetet. Hittills har det ju varit omedvetet.

Jag inser att det finns en utmaning i att förklara för flera hur man räknar ut det. Det kräver ju trots allt gymnasiematte, på minst andra årskursen vad jag kommer ihåg. Men, även det felaktiga aritmetiska medelvärdet kräver en hel del av de som inte vet hur man räknar ut det. Så, kravet på "förståelse" faller anser jag, eftersom språket inte behöver göra skillnad.

Spelar det här någon roll?

Ja, det gör det. Skillnaden mellan olika hårdvara/statistik gör att de kan byta plats i en rankning ganska rejält beroende på hur man mäter. Det betyder att den som lägger upp dessa data, i det här fallet Sweclockers, bör se till att man har en trovärdig metod för att göra det.

@Yoshman har sammanställt data från några sajter. vilket visar skillnaden mellan geometriska medelvärden och "vanliga" (aritmetiska) medelvärden.

Det @Yoshman sammanställning visar är att

Intel Core i7 7700K är 100 % i prestanda av AMD Ryzen 7 1800X i heltal vid samma klockfrekvens.
Intel Core i7 7700K är 69 % i prestanda av AMD Ryzen 7 1800X i flyttal vid samma klockfrekvens.

Det skiljer radikalt mot vad flera bedömare har trott tidigare.

Huvudsaken för mig och säkert det flesta läsare är att rätt statistik används vid rätt tillfällen. Det här är i princip gemensamt för samtliga hårdvarusajter som finns. Sweclocker råkar finnas där jag bor. Men, åter läs artiken:

Smith, James E. "Characterizing computer performance with a single number." Communications of the ACM 31.10 (1988): 1202-1206.

Den finns att läsa på https://www.cs.auckland.ac.nz/courses/compsci703s1c/resources...

Jag ser fram emot konstruktiv kritik samt ett besked hur Sweclockers kommer att agera med sammanställningar, prestandaindex och andra jämförelser framöver.

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Permalänk
Datavetare

Har du verkligen läst den text du baserar detta inlägg på?

Frågar då slutsatsen i den artikeln säger följande:

"In this article we have reached the following conclusions:
(1) Arithmetic mean can be used as an accurate measure of performance expressed as time. On the other hand, it should not be used for summarizing performance expressed as a rate such as mflops.
(2) Geometric mean should not be used for summarizing performance expressed as a rate or as a time. "

Både det resultat jag postade igår och prestandaindex är normaliserade värden mot en referens CPU/GPU, detta är absolut ett mått på tid när den underliggande storheten är FPS.

Antag att FPS för CPU A normaliserat mot FPS för CPU B, den senare ges värdet 1,0. Om CPU A då har ett värde på 1,2 tar det CPU B 1,2 gånger så lång tid att rendera en viss scen.

Problemet med aritmetiskt medelvärde uppstår när man applicerar det på saker som har olika vikt. Inte heller det är fallet för det jag postade igår eller prestandaindex. Dels är alla värden normaliserade mot en specifik modell, så absolutvärdet har samma vikt. Dels så finns det normalt ingen anledning att vikta vissa resultat hårdare än andra.

Möjligen kan jag se en poäng med att också göra ett prestandaindex med harmoniskt medelvärde, detta för att ett sådant skulle lägga tyngdpunkten på de olika produkternas lägstanivå.

Edit:
Och din tolkning av vad jag postade igår är fel: över de program jag mätte är i7-7700K 20 % gånger snabbare än R7-1800X i heltal (17 % med geometriskt medelvärde), det över alla CPU-kärnor.

För flyttal är i stället R7-1800X 20 % snabbare, något som beror både på att CineBench och Blender skalar perfekt med CPU-kärnor (vilket ytterst få "normala" program gör) samt att Zen är generellt sett väldigt stark på flyttal.

För att jämföra saker som IPC och prestanda vid en viss frekvens bör man hålla antalet CPU-trådar konstant för de modeller man jämför, blir annars rätt hopplöst att dra några användbara slutsatser.

Skulle säga att resultat jag fick fram inte på något sätt var förvånande, överraskande eller avviker från vad experter på CPU-design gissat/hävdat tidigare.

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:

Har du verkligen läst den text du baserar detta inlägg på?

Frågar då slutsatsen i den artikeln säger följande:

"In this article we have reached the following conclusions:
(1) Arithmetic mean can be used as an accurate measure of performance expressed as time. On the other hand, it should not be used for summarizing performance expressed as a rate such as mflops.
(2) Geometric mean should not be used for summarizing performance expressed as a rate or as a time. "

Både det resultat jag postade igår och prestandaindex är normaliserade värden mot en referens CPU/GPU, detta är absolut ett mått på tid när den underliggande storheten är FPS.

Antag att FPS för CPU A normaliserat mot FPS för CPU B, den senare ges värdet 1,0. Om CPU A då har ett värde på 1,2 tar det CPU B 1,2 gånger så lång tid att rendera en viss scen.

Problemet med aritmetiskt medelvärde uppstår när man applicerar det på saker som har olika vikt. Inte heller det är fallet för det jag postade igår eller prestandaindex. Dels är alla värden normaliserade mot en specifik modell, så absolutvärdet har samma vikt. Dels så finns det normalt ingen anledning att vikta vissa resultat hårdare än andra.

Möjligen kan jag se en poäng med att också göra ett prestandaindex med harmoniskt medelvärde, detta för att ett sådant skulle lägga tyngdpunkten på de olika produkternas lägstanivå.

Edit:
Och din tolkning av vad jag postade igår är fel: över de program jag mätte är i7-7700K 20 % gånger snabbare än R7-1800X i heltal (17 % med geometriskt medelvärde), det över alla CPU-kärnor.

För flyttal är i stället R7-1800X 20 % snabbare, något som beror både på att CineBench och Blender skalar perfekt med CPU-kärnor (vilket ytterst få "normala" program gör) samt att Zen är generellt sett väldigt stark på flyttal.

För att jämföra saker som IPC och prestanda vid en viss frekvens bör man hålla antalet CPU-trådar konstant för de modeller man jämför, blir annars rätt hopplöst att dra några användbara slutsatser.

Skulle säga att resultat jag fick fram inte på något sätt var förvånande, överraskande eller avviker från vad experter på CPU-design gissat/hävdat tidigare.

Ja, jag har läst den, fick konstruktiv kritik, men, är en förhastad klant som blandat ihop orden geometriskt med harmoniskt, vilket inte var korrekt.

1) Jag förstår inte riktigt hur du menar när du skriver "är absolut ett mått på tid när den underliggande storheten är FPS". FPS är per tid, dvs. det är en rate och då skall harmoniskt medelvärde användas. Ditt exempel är nog inte helt korrekt. Jämför FPS med km/h; om min hastighet är 1,2 km/h så säger det inget om tiden om jag inte vet sträckan.

2) Jag förstår inte heller vad du menar att man viktar här. Spelar det roll om A eller B är nämnare eller täljare?

3) Dessutom förstår jag inte "över de program jag mätte är i7-7700K 20 % gånger snabbare än R7-1800X i heltal (17 % med geometriskt medelvärde), det över alla CPU-kärnor". (Ja, om man bortser från att jag menade harmoniskt medelvärde...) Du skriver ju i tabellen:

> cmp('i7-7700K', 'R7-1800X', 'Float') ModelA ModelB Result GmResult IsoFreq GmIsoFreq 1 i7-7700K R7-1800X 0.83 0.79 0.73 0.69 > cmp('i7-7700K', 'R7-1800X', 'Int') ModelA ModelB Result GmResult IsoFreq GmIsoFreq 1 i7-7700K R7-1800X 1.2 1.17 1.04 1

GmIsoFreq för 7700K mot 1800X är ju "1" (1.00?). Det borde bli samma för harmoniskt medelvärde. Varför 20 %?

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Permalänk
Datavetare
Skrivet av sAAb:

Ja, jag har läst den, fick konstruktiv kritik, men, är en förhastad klant som blandat ihop orden geometriskt med harmoniskt, vilket inte var korrekt.

1) Jag förstår inte riktigt hur du menar när du skriver "är absolut ett mått på tid när den underliggande storheten är FPS". FPS är per tid, dvs. det är en rate och då skall harmoniskt medelvärde användas. Ditt exempel är nog inte helt korrekt. Jämför FPS med km/h; om min hastighet är 1,2 km/h så säger det inget om tiden om jag inte vet sträckan.

2) Jag förstår inte heller vad du menar att man viktar här. Spelar det roll om A eller B är nämnare eller täljare?

3) Dessutom förstår jag inte "över de program jag mätte är i7-7700K 20 % gånger snabbare än R7-1800X i heltal (17 % med geometriskt medelvärde), det över alla CPU-kärnor". (Ja, om man bortser från att jag menade harmoniskt medelvärde...) Du skriver ju i tabellen:

> cmp('i7-7700K', 'R7-1800X', 'Float') ModelA ModelB Result GmResult IsoFreq GmIsoFreq 1 i7-7700K R7-1800X 0.83 0.79 0.73 0.69 > cmp('i7-7700K', 'R7-1800X', 'Int') ModelA ModelB Result GmResult IsoFreq GmIsoFreq 1 i7-7700K R7-1800X 1.2 1.17 1.04 1

GmIsoFreq för 7700K mot 1800X är ju "1" (1.00?). Det borde bli samma för harmoniskt medelvärde. Varför 20 %?

Sista är enklast: Result = 1,2

Det är skillnaden i faktisk prestanda, d.v.s. 20 % högre. Att börja frekvenskompensera när man har flera CPU-kärnor ger bara någorlunda användbara resultat om man endera program som är enkeltrådat (i det läget är det effektivt lika många kärnor) eller att det skalar perfekt med CPU-kärnor (så man vet hur mycket jobbet varje kärna utför).

Majoriteten av alla program som skalar med kärnor skalar absolut inte linjärt, så helt hopplöst att veta hur man ska destillera det hela till någon form av "IPC". Enda vettiga man kan göra här är att mäta faktiskt prestanda.

Även när man jämför modeller med samma antal kärnor och CPU-trådar blir det fel att frekvenskompensera för att räkna ut "IPC", men i det läget är felet normalt sett inte gigantiskt så man kan få en hyfsat "mellan-tummen-och-pekfingret" känsla. Var därför jag främst jämförde 4C/8T modeller.

Angående typ av medelvärde. Grejen med både jämförelsen jag gör och den i prestandaindex är att de är medelvärden över redan normaliserade värden. Alla resultat är modell A, B, C... i relation till någon referensmodell. Alla värden har därför samma skala.

Vill man ha ett mått på hur A presterar relativt B i genomsnitt finns det ingen anledning att använda något annat än aritmetiskt medel då alla värden man gör ett medelvärde har samma skala. Den absolut största orsaken artikeln nämner till att aritmetiskt medel kan bli rejält missvisande är om det appliceras på saker som har olika skala. Så det stora problemet är främst när aritmetisk medelvärde appliceras på saker som är skalade olika, det blir då som att vikta vissa resultat hårdare och andra svagare.

Angående FPS, vilket känns som den bästa beskrivningen om tre spel ger 100 FPS och ett ger 10 FPS:

  • genomsnittlig FPS är 78 FPS

  • genomsnittlig FPS är 30

Skulle säga att den senare är definitivt fel (harmoniskt medelvärde), men det första har inte heller jättemycket relevans. Om det finns fluktuationer på den här nivån går det inte att att beskriva prestanda på ett vettigt sätt med en siffra då det finns ett rejält avvikande värde.

Den typen av avvikande värden finns inte i de värden jag hade och gissar att SweC skulle ta bort ett spel som ger ett brutalt avvikande värde för mer än ett enstaka kort.

Har man normaliserade värden finns det då ingen direkt anledning att använda något annat än aritmetiskt medelvärde. Dels är det något som folk begriper sig på, dels kommer effekten i fallet utan avvikande värden endast vara att ett harmoniskt medelvärde kraftigt viktar resultatet mot de tester med minst skillnad och vad är värdet i det?

Att göra ett medelvärde direkt av FPS skulle bli rejält fel oavsett vilken typ av medelvärde man använder sig av. Det då 60 FPS kan vara väldigt bra i ett spel medan 200 FPS kan vara dåligt (relativt vad andra modeller klarar av) i ett annat spel. Därför man måste räkna om varje spel/program till ett relativt värde så skalan blir densamma.

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:

Sista är enklast: Result = 1,2

Det är skillnaden i faktisk prestanda, d.v.s. 20 % högre. Att börja frekvenskompensera när man har flera CPU-kärnor ger bara någorlunda användbara resultat om man endera program som är enkeltrådat (i det läget är det effektivt lika många kärnor) eller att det skalar perfekt med CPU-kärnor (så man vet hur mycket jobbet varje kärna utför).

Majoriteten av alla program som skalar med kärnor skalar absolut inte linjärt, så helt hopplöst att veta hur man ska destillera det hela till någon form av "IPC". Enda vettiga man kan göra här är att mäta faktiskt prestanda.

Även när man jämför modeller med samma antal kärnor och CPU-trådar blir det fel att frekvenskompensera för att räkna ut "IPC", men i det läget är felet normalt sett inte gigantiskt så man kan få en hyfsat "mellan-tummen-och-pekfingret" känsla. Var därför jag främst jämförde 4C/8T modeller.

Angående typ av medelvärde. Grejen med både jämförelsen jag gör och den i prestandaindex är att de är medelvärden över redan normaliserade värden. Alla resultat är modell A, B, C... i relation till någon referensmodell. Alla värden har därför samma skala.

Vill man ha ett mått på hur A presterar relativt B i genomsnitt finns det ingen anledning att använda något annat än aritmetiskt medel då alla värden man gör ett medelvärde har samma skala. Den absolut största orsaken artikeln nämner till att aritmetiskt medel kan bli rejält missvisande är om det appliceras på saker som har olika skala. Så det stora problemet är främst när aritmetisk medelvärde appliceras på saker som är skalade olika, det blir då som att vikta vissa resultat hårdare och andra svagare.

Angående FPS, vilket känns som den bästa beskrivningen om tre spel ger 100 FPS och ett ger 10 FPS:

  • genomsnittlig FPS är 78 FPS

  • genomsnittlig FPS är 30

Skulle säga att den senare är definitivt fel (harmoniskt medelvärde), men det första har inte heller jättemycket relevans. Om det finns fluktuationer på den här nivån går det inte att att beskriva prestanda på ett vettigt sätt med en siffra då det finns ett rejält avvikande värde.

Den typen av avvikande värden finns inte i de värden jag hade och gissar att SweC skulle ta bort ett spel som ger ett brutalt avvikande värde för mer än ett enstaka kort.

Har man normaliserade värden finns det då ingen direkt anledning att använda något annat än aritmetiskt medelvärde. Dels är det något som folk begriper sig på, dels kommer effekten i fallet utan avvikande värden endast vara att ett harmoniskt medelvärde kraftigt viktar resultatet mot de tester med minst skillnad och vad är värdet i det?

Att göra ett medelvärde direkt av FPS skulle bli rejält fel oavsett vilken typ av medelvärde man använder sig av. Det då 60 FPS kan vara väldigt bra i ett spel medan 200 FPS kan vara dåligt (relativt vad andra modeller klarar av) i ett annat spel. Därför man måste räkna om varje spel/program till ett relativt värde så skalan blir densamma.

Nu är jag rejält trött, och det beror inte på den här diskussionen. Den brukar kunna hålla mig vaken. Det får bli lite kortare.

Inte frekvenskompensera? Det var du som införde det och du har det senaste halvåret halvt-om-halvt insisterat på att man skall beakta båda värdena (ipc*frekvens=faktisk prestanda), för att få ett relevant mått. Varför skall vi inte frekvenskompensera längre? Jag inser att halvt-om-halvt själv att Amdahls lag är med men jag är för trött...

"Majoriteten av alla program som skalar med kärnor skalar absolut inte linjärt, så helt hopplöst att veta hur man ska destillera det hela till någon form av "IPC". Enda vettiga man kan göra här är att mäta faktiskt prestanda."

Man kanske skulle kunna använda en baklängesmetod där man kör med en exponentiell ekvation. För trött... Har varit uppe för länge, sedan förra veckan. Men kanske. Återkommer.

Angående typ av medelvärde.

Du skriver

"Den typen av avvikande värden finns inte i de värden jag hade och gissar att SweC skulle ta bort ett spel som ger ett brutalt avvikande värde för mer än ett enstaka kort",

Den typen av tankar är farliga, "subjective pruning", ibland... Jo, om en av fyra är skev, hur utför man "pruning" utan subjektivitet. Jo, gott omdöme... Men, nej, mycket bättre än så blir det inte, om man inte ...

power analysis

men det orkar jag inte ikväll.

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Permalänk
Medlem
Skrivet av Yoshman:

Sista är enklast: Result = 1,2

Det är skillnaden i faktisk prestanda, d.v.s. 20 % högre. Att börja frekvenskompensera när man har flera CPU-kärnor ger bara någorlunda användbara resultat om man endera program som är enkeltrådat (i det läget är det effektivt lika många kärnor) eller att det skalar perfekt med CPU-kärnor (så man vet hur mycket jobbet varje kärna utför).

Majoriteten av alla program som skalar med kärnor skalar absolut inte linjärt, så helt hopplöst att veta hur man ska destillera det hela till någon form av "IPC". Enda vettiga man kan göra här är att mäta faktiskt prestanda.

Även när man jämför modeller med samma antal kärnor och CPU-trådar blir det fel att frekvenskompensera för att räkna ut "IPC", men i det läget är felet normalt sett inte gigantiskt så man kan få en hyfsat "mellan-tummen-och-pekfingret" känsla. Var därför jag främst jämförde 4C/8T modeller.

Angående typ av medelvärde. Grejen med både jämförelsen jag gör och den i prestandaindex är att de är medelvärden över redan normaliserade värden. Alla resultat är modell A, B, C... i relation till någon referensmodell. Alla värden har därför samma skala.

Vill man ha ett mått på hur A presterar relativt B i genomsnitt finns det ingen anledning att använda något annat än aritmetiskt medel då alla värden man gör ett medelvärde har samma skala. Den absolut största orsaken artikeln nämner till att aritmetiskt medel kan bli rejält missvisande är om det appliceras på saker som har olika skala. Så det stora problemet är främst när aritmetisk medelvärde appliceras på saker som är skalade olika, det blir då som att vikta vissa resultat hårdare och andra svagare.

Angående FPS, vilket känns som den bästa beskrivningen om tre spel ger 100 FPS och ett ger 10 FPS:

  • genomsnittlig FPS är 78 FPS

  • genomsnittlig FPS är 30

Skulle säga att den senare är definitivt fel (harmoniskt medelvärde), men det första har inte heller jättemycket relevans. Om det finns fluktuationer på den här nivån går det inte att att beskriva prestanda på ett vettigt sätt med en siffra då det finns ett rejält avvikande värde.

Den typen av avvikande värden finns inte i de värden jag hade och gissar att SweC skulle ta bort ett spel som ger ett brutalt avvikande värde för mer än ett enstaka kort.

Har man normaliserade värden finns det då ingen direkt anledning att använda något annat än aritmetiskt medelvärde. Dels är det något som folk begriper sig på, dels kommer effekten i fallet utan avvikande värden endast vara att ett harmoniskt medelvärde kraftigt viktar resultatet mot de tester med minst skillnad och vad är värdet i det?

Att göra ett medelvärde direkt av FPS skulle bli rejält fel oavsett vilken typ av medelvärde man använder sig av. Det då 60 FPS kan vara väldigt bra i ett spel medan 200 FPS kan vara dåligt (relativt vad andra modeller klarar av) i ett annat spel. Därför man måste räkna om varje spel/program till ett relativt värde så skalan blir densamma.

Skrivet av sAAb:

Nu är jag rejält trött, och det beror inte på den här diskussionen. Den brukar kunna hålla mig vaken. Det får bli lite kortare.

Inte frekvenskompensera? Det var du som införde det och du har det senaste halvåret halvt-om-halvt insisterat på att man skall beakta båda värdena (ipc*frekvens=faktisk prestanda), för att få ett relevant mått. Varför skall vi inte frekvenskompensera längre? Jag inser att halvt-om-halvt själv att Amdahls lag är med men jag är för trött...

"Majoriteten av alla program som skalar med kärnor skalar absolut inte linjärt, så helt hopplöst att veta hur man ska destillera det hela till någon form av "IPC". Enda vettiga man kan göra här är att mäta faktiskt prestanda."

Man kanske skulle kunna använda en baklängesmetod där man kör med en exponentiell ekvation. För trött... Har varit uppe för länge, sedan förra veckan. Men kanske. Återkommer.

Angående typ av medelvärde.

Du skriver

"Den typen av avvikande värden finns inte i de värden jag hade och gissar att SweC skulle ta bort ett spel som ger ett brutalt avvikande värde för mer än ett enstaka kort",

Den typen av tankar är farliga, "subjective pruning", ibland... Jo, om en av fyra är skev, hur utför man "pruning" utan subjektivitet. Jo, gott omdöme... Men, nej, mycket bättre än så blir det inte, om man inte ...

power analysis

men det orkar jag inte ikväll.

Lite piggare...

Ditt exempel

Citat:

Angående FPS, vilket känns som den bästa beskrivningen om tre spel ger 100 FPS och ett ger 10 FPS:

  • genomsnittlig FPS är 78 FPS

  • genomsnittlig FPS är 30

Skulle säga att den senare är definitivt fel (harmoniskt medelvärde), men det första har inte heller jättemycket relevans. Om det finns fluktuationer på den här nivån går det inte att att beskriva prestanda på ett vettigt sätt med en siffra då det finns ett rejält avvikande värde.

är bra!

Även om jag läser exemplet ("Medelhastigheten för en bil") från Wikipedia, https://sv.wikipedia.org/wiki/Harmoniskt_medelvärde, så kan jag inte enkelt få till det i fallet med FPS, som helt tydligt dessutom är en rate.

Någonstans haltar någon av metoderna, men jag kan inte sätta fingret på var, än...

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Permalänk
Datavetare
Skrivet av sAAb:

Även om jag läser exemplet ("Medelhastigheten för en bil") från Wikipedia, https://sv.wikipedia.org/wiki/Harmoniskt_medelvärde, så kan jag inte enkelt få till det i fallet med FPS, som helt tydligt dessutom är en rate.

Någonstans haltar någon av metoderna, men jag kan inte sätta fingret på var, än...

Det som haltar är att FPS inte har någon koppling till tiden man kommer spendera i fall A resp. B.

Jämför med bilen: om jag åker lika långt i två olika hastigheter så kommer jag spendera mer tid i den lägre hastigheten. Det harmoniska medelvärdet kompenserar för skillnaden i spenderad tid så resultatet blir medelhastighet.

Nu ska jag inte dra detta allt för långt, men är ju snarare så att man kommer spendera mer tid i ett spel med 120 FPS än om det stapplar runt i 10 FPS

Nä, seriöst. Där hjulen trillar av här är just att förlupen tid över alla titlar man medelvärdesbildar inte har någon relevans. I det läget handlar det främst om att säkerställa att det man medelvärdesbildar har samma skala, vilket är fallet för prestandaindex. Därför inte fel att använda aritmetiskt medelvärde.

Harmoniskt medelvärde skulle ändå kunna vara intressant, det skulle i så fall tolkas som ett mått på lägstanivå då en modell med hög lägstanivå kommer få ett högre harmoniskt medelvärde än en modell med rejäla dippar och väldigt högt normalläge.

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:

Det som haltar är att FPS inte har någon koppling till tiden man kommer spendera i fall A resp. B.

Jämför med bilen: om jag åker lika långt i två olika hastigheter så kommer jag spendera mer tid i den lägre hastigheten. Det harmoniska medelvärdet kompenserar för skillnaden i spenderad tid så resultatet blir medelhastighet.

Nu ska jag inte dra detta allt för långt, men är ju snarare så att man kommer spendera mer tid i ett spel med 120 FPS än om det stapplar runt i 10 FPS

Nä, seriöst. Där hjulen trillar av här är just att förlupen tid över alla titlar man medelvärdesbildar inte har någon relevans. I det läget handlar det främst om att säkerställa att det man medelvärdesbildar har samma skala, vilket är fallet för prestandaindex. Därför inte fel att använda aritmetiskt medelvärde.

Harmoniskt medelvärde skulle ändå kunna vara intressant, det skulle i så fall tolkas som ett mått på lägstanivå då en modell med hög lägstanivå kommer få ett högre harmoniskt medelvärde än en modell med rejäla dippar och väldigt högt normalläge.

Njae, 10 fps vill man inte stanna länge vid... Men, jag har gjort det när allt nyare nöjen kom ut och mitt grafikkort inte klarade mer...

Åter till harmonin. Det kanske är så att FPS inte är rätt mått alls för det vi vill åt. Kan det vara så att TechReport har mer att komma med än vad andra vill tillkännage, i sin jakt på ett värde för en datorkomponent.

http://techreport.com/review/31546/where-minimum-fps-figures-...

Vi kanske saknar validitet i FPS. Det kanske inte mäter vad vi tror att vi mäter. Det kanske är tiden per se som är relevant, inte "hastigheten" eller något "per sekund". Då blir Tech Reports artikel enklare och "frame rate", dvs. FPS, är fel mått man använder, då det är en frekvens, en rate.

Ett exempel med bilens medelhastighet, som är en rate, som inte enkelt går att översätta med FPS, som också är en rate, "per sekund". Fast, okej, medelhastighet har två storheter, sträcka över tid. FPS har enbart en, över tid. Det är en skillnad, men jag känner inte igen skillnaden från andra sammanhang just nu.

EDIT: Jo, ljudfrekvenser, Hz är väl kanske en ingång, men jag vet inte hur man hantera det statistiskt, än.

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Permalänk
Datavetare
Skrivet av sAAb:

Njae, 10 fps vill man inte stanna länge vid... Men, jag har gjort det när allt nyare nöjen kom ut och mitt grafikkort inte klarade mer...

Åter till harmonin. Det kanske är så att FPS inte är rätt mått alls för det vi vill åt. Kan det vara så att TechReport har mer att komma med än vad andra vill tillkännage, i sin jakt på ett värde för en datorkomponent.

http://techreport.com/review/31546/where-minimum-fps-figures-...

http://techreport.com/r.x/2017_03_07_Where_minimum_FPS_figures_may_mislead_frame_time_analysis_shines/cry3-1800x-normalized2.png
http://techreport.com/r.x/2017_03_07_Where_minimum_FPS_figures_may_mislead_frame_time_analysis_shines/cry3-7700K-normalized.png

Vi kanske saknar validitet i FPS. Det kanske inte mäter vad vi tror att vi mäter. Det kanske är tiden per se som är relevant, inte "hastigheten" eller något "per sekund". Då blir Tech Reports artikel enklare och "frame rate", dvs. FPS, är fel mått man använder, då det är en frekvens, en rate.

Ett exempel med bilens medelhastighet, som är en rate, som inte enkelt går att översätta med FPS, som också är en rate, "per sekund". Fast, okej, medelhastighet har två storheter, sträcka över tid. FPS har enbart en, över tid. Det är en skillnad, men jag känner inte igen skillnaden från andra sammanhang just nu.

Vad jag skulle vilja se är lite åt TR hållet, skulle vilja få ett histogram där hinkarna är uppdelade efter scentid och visar antal frames som hamnar inom scentidsgränserna för respektive hink. Men då är problemet: det är inte ett tal för prestanda.

Detta då för GPU.

För CPU tycker jag dagens mätningar är vettiga, har dock lite åsikter om vilka program som används. Har skrivit att i min mening är flyttalsintensiva program som skalar nära perfekt med CPU-kärnor kraftigt överrepresenterat jämfört med vad normalanvändaren faktiskt kommer köra på en desktopdator.

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:

Vad jag skulle vilja se är lite åt TR hållet, skulle vilja få ett histogram där hinkarna är uppdelade efter scentid och visar antal frames som hamnar inom scentidsgränserna för respektive hink. Men då är problemet: det är inte ett tal för prestanda. Detta då för GPU. För CPU tycker jag dagens mätningar är vettiga, har dock lite åsikter om vilka program som används. Har skrivit att i min mening är flyttalsintensiva program som skalar nära perfekt med CPU-kärnor kraftigt överrepresenterat jämfört med vad normalanvändaren faktiskt kommer köra på en desktopdator.

Jo, per á priori bin är det en rimlig beskrivning.

"Problemet" är kanske grafiskt, att Sweclockers och andra sajter vill presentera värden för två dussin kompontenter (cpu, gpu, minnen, mm) i ett och samma diagram. Vilka möjligheter finns där, layoutmässigt?

Det blir nog svårt att få bort ofoget med ett värde per produkt...

EDIT: Här är två diagram som visar hur missvisande ett (1) värde kan vara. De kommer från http://techreport.com/review/22151/nvidia-geforce-gtx-560-ti-...

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Permalänk
Medlem

Jag återbesökte det här och stapeldiagrammen från Techreport.com för att se hur stor effekt olika typer av medelvärden och kvantiler har för utfallet. Själv tycker jag att det är spännande. Diagrammen är här

x-axeln visar fps och y-axeln visar hur många som finns av olika fps

Dold text

Här är resultatet @Yoshman, där vi ser att skillnaden mellan olika typer av medelvärden i princip är försumbara.

Sammanfattning

1800X

7700K

Fördel 7700K

aritmetiskt medelvärde

131,8

134,8

2,28%

geometrisk medelvärde

129,9

133,1

2,46%

harmoniskt medelvärde

128,0

131,4

2,66%

kvantil 50% (median)

128

132

3,13%

kvantil 10 %

104

112

7,69%

kvantil 1 %

80

92

15,00%

kvantil 0,1 %

64

76

18,75%

Jag kommer nog inte insistera på harmoniskt över aritmetiskt fler gånger om det är så här små skillnader...

Däremot är kvantilvärden relevanta!

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|