Testresultat: AMD FX-8150 med KB2592546 – uppdaterad schemaläggare i Windows 7

Det där är bara tragiskt

http://techreport.com/discussions.x/22179

Jaså blir man stämplad som fanboy bara för att man påpekar systematiska fel i testmetodiken nu? Jag har påpekat denna brist många gånger för i många andra tester men ju i det här fallet var det extra påtagligt hur viktigt det är att faktiskt utföra en korrekt analys av sina mätvärden. Sweclockers är inte ensamma om att missa detta, jag har inte sett några sidor göra vettiga statistiska analyser av sina resultat. Inte ens alla seriösa forskare tittar på sina mätvärden eller gör känslighetsanalyser som de borde. Ingenstans kommenterade jag prestandan hos Bulldozer utan bara testresultaten och hur de presenterades.

Verkar som MS var lite heta på (jule)gröten:
http://www.brightsideofnews.com/news/2011/12/16/microsoft-rel...

Jaså det viktigaste är att det är överskådligt och inte att det är rätt?
Faktum är att tabellen är mer överskådlig nu än den var tidigare. Ser man massa minustecken tolkar man automatiskt det som att är en försämring även om det är -0,4 % som dessutom är statistiskt felaktigt. Det är ju dessutom betydligt tydligare med nollor där det ska vara nollor än massa små siffror. Då kan du filtrera bort obetydlig data direkt. Sen måste du vara väldigt lättförvirrad om (σ=20) i kanten är för mycket. Egentligen behöver de inte redovisa standardavvikelser så länge de själva gör analysen vilket bevisligen inte är fallet. Vad PhysiX har med korrekta mätvärden förstår jag inte riktigt, det är ju snarare en till sak som förvirrar dig eftersom de inte sällan testar spel både med och utan PhysiX. De kanske ska sluta testa flera olika kort också och med flera olika inställningar eftersom det blir komplicerat att titta på.

Som sagt, att inte titta på standardavvikelser och liknande ger felaktiga mätvärden. Risken är stor att man skriver saker som inte är sanna, men det bryr du dig tydligen inte alls om, så länge färgerna är tydliga.

Nu tar du dock i från tårna, hehe.
Även om vi inte når upp till dina krav på beviskvalitet står vi bakom resultaten vi publicerar, och de analyser vi gör är så nära sanningen vi kan komma. Ser vi att testerna diffar för mycket eller helt enkelt inte visar vad de borde kontrollerar vi vad som går fel och kör om tills vi är nöjda, alltså tills värdena vi får ut ligger tillräckligt nära varandra för att kunna anses vara korrekta. Att vi sedan inte redovisar hela processen är en annan femma, och det kan vi som tidigare sagt eventuellt se över i framtiden.

Om du eller andra vill diskutera vidare passar en tråd i Feedback bättre för ämnet.

AMD programmerare har varit aktiva i Linux kerneln runt Juli och hjälpt till där med förbättringar för att hantera BD bättre. Inte awesome resultat men men. Vad de gör med Windows och hur mycket eller om de hjälper till vet jag inte.

Och jag försöker förklara att inte en jävel bryr sig så länge man förstår När man skriver fort så är det lätt att det blir fel i grammatiken.

Angående PhysX av eller på så var grafikkortstesterna förr att man endast testade de funktioner som alla hade. Det har idag gett oss grafikkort som inte är så väldigt upplyftande.
Sen tror jag inte att swe klarar av att prestera så avancerade värden som standardavvikelser i sina tester.
Många av de s.k. differenserna kan mycket väl bero på mjukvaran är annorlunda installerad eller att någon annan del drar igång ibland. Skillnader på några fps kan vara slumpen men oftast helt betydelselös även om vissa anser att det är helt avgörande.

Frånsett testerna så:
Patchen har visat att BD har en potential att bli bättre. Om programvaran blir rätt så kan många delar förbättras en del, sen om den enbart förbättrar hanteringen av flera trådar eller om även de nya instruktionerna har kommit med delvis får man väl snart se.
Sen kommer nästa del när även speltillverkarna inser att de kör med föråldrade program så kan det börja bli riktigt bra framöver.

Nästan lika dålig som SB.

Fredagspanel hos SweClockers, vecka 50

<Emil> I många fall ser vi faktiskt en ganska signifikant prestanda förlust. Speciellt då där många trådar utnyttjas.
<Emil> Speciellt i ett spel, om jag minns rätt så var det Metro, som tappade jätte mycket prestanda.
<Jonas> Vad var det, runt 20% prestanda?
<Emil> Ja i värsta fall runt 20%
<Emil> Helt plötsligt började det dippa på väldigt många ställen.
<Emil> Det blev hackigare helt enkelt och betedde sig väldigt märkligt i största allmänhet.

<Jonas> Sen får vi se vad som händer om Microsoft lägger ut en ny version av den här patchen.
<Emil> Precis.
<Jonas> Som kanske fungerar bättre, eller varför inte sämre ?

Men det är ju jätte bra...
AMD släpper en processor som fungerar bäst som direktverkande eluppvärmning och har prestanda typ som en Core 2.
Sen efter ett antal uppdateringar så kommer man ha prestanda som en 486:a.
It just keeps getting better....

AMD Netburst ? Nya Pentium 4 utmanaren?

När AMD kom med Athlon 64 och verkligen var konkurrenskraftiga trodde man inte riktigt att det skulle gå så här. De har åtminstone sina Llano och Brazos och allt vad de heter som har sin plats på marknaden. Grafikkorten är också bra.
Men Bulldozer känns mest malplacerad. För dålig prestanda för att vara high end och för hög strömförbrukning för att vara midrange eller budget.

Är inte llano utan GPU typ phenom 3 i 32nm?

Som sagt, det är snorenkelt att kolla standardavvikelser eftersom Excel räknar ut det åt dig. Det är alltså lika lätt som att räkna ut ett medelvärde. Har för mig kommandot heter STDEV() så får man standardavvikelsen på alla värden man stoppar in.

Sen är det just de där slumpmässiga skillnaderna man vill åt! Det är för att det ÄR skillnad av olika anledningar som det är viktigt att visa hur säkra ens mätdata är. Hade alla mätningar gett exakt samma resultat hade det inte behövts men nu är inte det fallet, alltså behövs statistiska metoder för att kvantifiera slumpmässiga mätfel. Du verkar helt ha missat varför man gör sådana här tester.

Vet inte om jag håller med dig där, 8150 är överlag förutom några program/tillämpningar överlag en bit långsammare än 2500k i vardagsbruk, och dessutom en bit dyrare. Men Sitter man mest och 7zippar, gör renderingar eller kodar x264 så är nog inte 2500k ens val ändå. Du vet nog redan att man inte kan jämföra rena TDP-siffror från olika eller ens samma tillverkare. Skillnaden är lite mer än de 30W du föreslår, tester uppvisar vid last en skillnad på 80+W snarare.

De drar inte bara i OC som sagt, utan även vid last utan OC som det är, problemet är att Sandy har relativt jämn prestanda överlag nästan oavsett vad du har den till, ovanpå det så har du en låg förbrukning och lätt och rätt bra OC. Det är en svårslagen kombo, tyvärr, vi behöver AMD med en ny bra processor-generation Snart.

Nope
Mer som Athlon, det är ingen L3 cache och väldigt lite L1 och L2 Dock så presterar den väldigt bra ändå

Du har rätt, jag överdrev.
Men efter att Bulldozer hypats en del, så känns det ändå som en besvikelse.
Om man vill ha något kraftfullare än atom och som har bra IGP kan processorer som E-350 och dylikt vara
intressant. Men har man högre prestanda krav så skulle jag hellre välja 2500K eller 2600K än FX om jag skulle köpa ny dator nu.

Jag hoppas nästa generation/revision blir bättre. Är rätt stor sannolikhet att nästa gen/rev blir bättre än nuvarande, frågan är hur mycket bättre. Hade varit kul att se AMD göra en ny 'Athlon 64', alltså en processor där de tekniskt ligger före Intel så de får till en storsäljare, kan fylla på sina kassor och lägga ännu mer resurser på utveckling i framtiden. Tror att ett jämnare förhållande mellan AMD och Intel hade kunnat gynna oss konsumenter.

Enda fördelen med att Intel inte behöver stressa på prestanda uppgraderingarna lika mycket är väl att det blir enklare att göra någorlunda strömsnåla kretsar då.

Flera som frågar efter standardavvikelser här, men en standardavvikelse av 3-5 värden är knappast tolkbart. Ska man ha spridningsmått som är meningsfulla så måste man ha fler testkörningar, och då blir det genast mkt mer jobb. Sedan vet jag inte om fler körningar tillför så mycket ändå. Antagligen kommer du att få en bunt av stabila värden inom 1-2 FPS från maxvärdet, samt ett fåtal värden som är lägre pga att du just då hade otur med schemaläggningen eller någon systemprocess som just då tog resurser. Med en sådan fördelning så är inte heller standardavvikelse så meningsfullt oavsett antalet körningar, då det måttet inte skiljer på variation över och under medelvärdet. Rimligare då att bara rapportera ett typiskt (stabilt) värde, vilket verkar vara det Swec gör.

(Jag noterar att Emil rekommenderar en egen tråd för denna diskussionen, men det kändes lite konstigt att skapa en egen tråd för att argumentera för att samma tråd inte behövs, så jag skriver här i alla fall).

Jag uppdaterade artikeln.

Skönt att de drog tillbaka uppdateringen. Det kunde ju vilket stolpskott som helst räknat ut att den inte var klar för lansering. Tillbaks till ritbordet.

Jag har redan påpekat att även ett intervall hade gett mycket mer information än ett värde.
Sen är det som sagt slumpvariabler som "otur med schemaläggaren" som gör att det är viktigt med någon sorts analys av resultaten. Har man otur med schemaläggaren hälften av körningarna så är det ju högst relevant att ta med det i beräkningarna. Att då bara titta på de bästa värdena blir ju direkt missvisande. Det faktum att en dator har massa smågrejer som går i bakgrunden gör det ju viktigt att faktiskt analysera sina resultat ordentligt och inte bara hoppas på att ett medelvärde duger, eller fallet FPS där det är medelvärde av ett medelvärde.
Där är för övrigt en intressant parallell, när det kommer till bildfrekvens i spel rapporteras både medel och min, ibland även max eftersom ett medeltal är högst ointressant då de är de lägsta nivåerna som är störande. Samma hänsyn tas inte till de andra testerna.
Som sagt, om man inte orkar göra några ordentliga analyser så borde åtminstone intervallet redovisas så man kan se hur säkra siffrorna är. Börjar intervallen överlappa för två olika scenarion kan man ju då räkna med att de är samma eller så nära varandra att det i praktiken inte är intressant, såvida man inte kör till exempel ett T-test och visar att det faktiskt är skillnad.

Just i det här fallet var ju mätvärdena direkt vilseledande eftersom man rent undermedvetet tolkar minustecken som något negativt även om det bara var "otur med schemaläggaren" eller "någon process i bakgrunden" som var den egentliga orsaken. Ska man då utvärdera skillnaden mellan två olika scenarier får man antigen se till att det inte finns några andra yttre påverkningar vilket är i princip omöjligt i en dator, eller så får man använda sig av någon sorts statistisk metod för att på så sätt filtrera fram ett representativt värde.

En standardavvikelse baserad på 3-5 körningar är fortfarande mer värdefull än inget alls eftersom det ger en indikation om hur mycket mätvärden varierar. Nu vet vi inte ett piss mer än att mina körningar varierade med 4 % åt båda hållen.

Ah, just det, tänkte inte på det.