Sår tvil om Futuremarks troverdighet

[knopflerbruce]

Dette gjaldt vel ikke hele PCMark, men kun en av mange deltester?

 

Det var minnetesten, ironisk nok...

[Ourasi]

Dette gjaldt vel ikke hele PCMark, men kun en av mange deltester?

 

Det gjelder Minne benchmark delen, og alle minnetestene utenom "Latency" får kraftige hopp i ytelse ved forandring av ID, spesiellt til Intel som nevnt i artikkelen. CPU scoren er altså den samme uansett ID i PCmark 2005., men jeg anntar at minne testen er med i utregningen av totalscoren, men er ikke helt sikker...

 

Nå er vel PCmark Vantage "Vista only", og han valgte XP som OS da han mente dette passet bedre for denne typen hw, men han kunne kanskje tatt seg tid til å ta en rask test av PCmark Vantage i vista også i lys av det han oppdaget..

Endret 5. august 2008 av Ourasi

[ArneJ.]

Hehe, ingen bombe at syntetiske tester er mest bare bullshit. Som de fleste voksne personer her inne har kommentert tidligere så er det faktiske applikasjoner og spill som betyr noe. Disse testene er i beste fall kun skikkelig sammenlignbare mellom produkter i samme serie.

[hifiking]

Slike tester er jo greie for å måle økning i ytelse ved overklokk. Få spill/programmer har jo en slik funksjon.

[ArneJ.]

Slike tester er jo greie for å måle økning i ytelse ved overklokk. Få spill/programmer har jo en slik funksjon.

Ytelse som kun gir 100% mening i forhold til den riggen du allerde har i akkurat det testprogrammet. Om du får 10% ekstra ytelse i 3dmark, men dette kun gir 3% utslag i flere spill du spiller. Hva har du da målt?

Endret 5. august 2008 av Onanias

[hifiking]

Slike tester er jo greie for å måle økning i ytelse ved overklokk. Få spill/programmer har jo en slik funksjon.

Ytelse som kun gir 100% mening i forhold til den riggen du allerde har i akkurat det testprogrammet. Om du får 10% ekstra ytelse i 3dmark, men dette kun gir 3% utslag i flere spill du spiller. Hva har du da målt?

 

Ingen programmer reagerer likt på overklokking. Men man ser det fungerer og man får et tall på det.

 

Man må også skille på gfx og cpu score. Så vet man at feks spillet er cpu avhengig. Mye man kan finne ut om man går litt dyperer inn i scoren en kun xxx 3dmarks :- )

 

Men er enig i at FM lager programmer som bør brukes som et spill, ikke som et beslutningsgrunnlag.

[Flippo]

Trodde da det var ganske vanlig å kompilere forskjellige versjoner med optimiseringer for hver CPU. De fleste kompilatorer har vel switcher for hvilke multimedia extensions og greier som skal brukes hvor dem prøver å sette opp rekkefølgen av instruksjoner optimalt for målstrukturen. Synes det ville vært rart om PCMark ikke hadde slike optimaliseringer som en del av testen? At en CPU som Via Nano da oppfører seg forskjellig avhengig av hvilken kode som kjøres på den, optimisert for AMD eller Intel, er da vel ikke helt uventet? Det samme problemet hadde man da også å "gamle dager" med de første Cyrix, AMD, ... x86 kloner.

[WaterMarked]

Var da ekstremt mye forskjell det var.

Litt merkelig.

Men jeg har ikke noe kunnskap om programmering, så tror jeg holder kjeft.

[Gjest Slettet-Pqy3rC]

Trodde da det var ganske vanlig å kompilere forskjellige versjoner med optimiseringer for hver CPU. ... At en CPU som Via Nano da oppfører seg forskjellig avhengig av hvilken kode som kjøres på den, optimisert for AMD eller Intel, er da vel ikke helt uventet?

 

Dersom forskjellig kode/utregninger benyttes burde PCMark presentert ulike resultater, f.eks "Intel optimized score", "AMD optimized Score" og "No optimization Score".

 

Ulike regnestykker bør ikke kokes sammen til en og samme resultatscore fordi dette forvirrer mer enn det opplyser.

Endret 5. august 2008 av Slettet-Pqy3rC

[Gjest Slettet-Pqy3rC]

Var da ekstremt mye forskjell det var.

Litt merkelig.

Men jeg har ikke noe kunnskap om programmering, så tror jeg holder kjeft.

 

Du trenger ikke programmerings erfaring for å vurdere dette, tenk deg følgende:

 

Ingar, Amders og Vidar flytter stein til daglig.

Futuremark vil finne ut hvor fort de kan flytte stein.

En stein hentes og en avstand de skal flytte steinen bestemmes.

 

Alle tre kan altså bære steinen. Nå vet Futuremark i tillegg at Ingar kan fly og Amders kan kjøre bil, mens Vidar vet de ingenting om. Derfor setter de opp et fly for Ingar, en bil for Amders mens stakkars Vidar må følgelig bære steinen hele veien.

 

Futuremark presenterer tiden de forskjellige fikk, men sier ingenting om at operasjonen faktisk ble utført helt ulikt.

 

Dersom Vidar sier han heter Ingar får han også et fly og derfor bedre tid (score). Men han gjør ikke lenger operasjonen på samme måte og dette burde vært oppgitt/synliggjort.

Endret 5. august 2008 av Slettet-Pqy3rC

[ze5400]

Er vel ikke umulig dette har med SSE å gjøre?

[knopflerbruce]

Er vel ikke umulig dette har med SSE å gjøre?

 

Det er enttopp det jeg har lest at det har. Intel kjører på SSE3 der det er mulig, AMD K8 kjører SSE2 (selv om SSE3 er støttet på hele 90nm minus Winchester), mens VIA kjører SSE (aner ikke hva som er støttet i de der). Latterlig business av FM, hva som fikk de til å gjøre noe sånt kan man jo bare lure på...

[CosmoK]

Mmm... må si at dette minner meg om tidligere episoder angående Futuremark's produkter. Men jeg er enig i at denne gangen virker det langt mindre en bevisst handling fra deres side, og heller "litt uflaks" i form av dårlig programmering/optimalisering.

[Simen1]

Det er mildt sagt mistenkelig, <..>

Helt klart. Hvis ikke Futuremark rydder skikkelig opp i eget reir etter denne avsløringen, og kommer med en grundig forklaring og kanskje viser frem kildekoden til utslagsgivende kodesnutter så er det ikke mye troverdighet fra den kanten lengre.

 

Uansett grunn, er det en påminnelse om at resultater i syntetiske testprogrammer må tas med en stor klype salt.

Det verste er at slikt ikke bare forekommer i syntetiske tester. De fleste større programmer har en CPUID-sjekk for å bestemme hvilke optimaliseringer som skal brukes. Tidligere har jeg lest om programmer der man har klart å endre den kompilerte koden akkurat rundt der sjekken gjøres slik at programmet får injisert feil CPUID. Dette har ført til ganske store ytelseforskjeller. Særlig i programmer som slår av alle SSEx-instruksjoner dersom CPUID er "feil". Selv om prosessoren takler SSEx.

 

Intel har blant annet vært mistenkt for å levere kompilatorer med diskriminerende CPUID-sjekker innebygget. Satt litt på spissen ser jeg for meg en slik psaudo-kode:

IF CPUID=GenuineIntel THEN run program ELSE Turn off MMX, SSE, SSE2, SSE3, SSE4 and run program.

 

Nå skal det etter sigende være ryddet opp i det meste av slik diskriminering, trolig fordi det ble for lett å avsløre og klart i strid med konkurranselover.

 

Programvareleverandører kan se seg mer tjent med å ta i mot bestikkelser for å innføre kunstige bremser eller rett og slett droppe optimaliseringer av annet enn markedslederen for å spare penger, enn de ville gjort ved å optimalisere for flere prosessortyper/produsenter.

 

Jeg håper det dukker opp noen ES-versjoner av Barcelona/Shanghai med åpen CPUID så Ars Technika eller andre får testet hva som skjer da.

[SVD]

Litt morsomt at VIA har åpen CPUID, kanskje de viste at dette kom til og skje og derfor valgte de det, hehe litt konspirasjonsteori kanskje

Endret 5. august 2008 av SVD