Hvilken prosessor er best på Super PI?

[Knick Knack]

tror ikke helt du skjønte poenget med det. Snorreh snakke tidligere om at han var utdannet fra UiB og ut fra hvordan han ordla seg forstod jeg det slik at du var NTNU student.

 

snorreh fra kl 18.25:

Det er kanskje slikt du lærer å gjøre på NTNU, men her ved UiB så lærer vi å alltid benytte oss av alle tilgjengelige data ved å bruke et representativt gjennomsnitt

 

Ville bare si at jeg var enig i hans gjennomsnittsbetrakning "på tross av" at jeg er NTNU-student.

 

Tredje gang: Hva var det du ville skulle bli oversatt til norsk fra fransk??

 

mag

 

EDIT: nå stikker jeg å tar meg en øl på Lucas, så vi får fortsette litt senere, men kom gjerne med det du ville ha oversatt

Her er linken:

http://www.x86-secret.com/articles/cpu/p43g/p43g-5.htm

Lurte bare på hva slags minne som benyttes i testing av P4 3.06GHz systemet.

Antagelig er det DDR333 eller DDR266

 

Hva gjennomsnitt angår: Tek på dette: om du vil vite hvor raskt en bil kan akselerere fra 0 til 100. hva gjør du da? jo du kjører selvsagt flere testløp. tar du gjennomsnittet? Nei! du tar den beste tiden fordi dette er hva bilen kan yte. Alle tester som viser lavere enn den beste skyldes at sjåføren ikke har kjørt nært nok optimalt. (han vil aldri klare 1005 optimalt). Samme gjelder for Super Pi testen. Noen ganger vil resultatet bli dårligere fordi prosesser i bakgrunnen (det kan gjerne være 20-40 stk) finner på å dra noe ytelse mens testen pågår!

 

Men grunnen til at jeg klager på snorreh sin fremstilling her er at jeg har han beskyldt for å ha bestemt seg for en teori for så å velge ut de data som passet han best og bortforklare/se bort fra de data som ikke passet til teorien. Om en leser hans respons på de data jeg fant ved tilfeldig søk så kommer dette svært tydelig frem.

 

Jeg tok en titt på den grafen som først ble presentert. Deretter lette jeg litt rundt på nettet og fant konsekvent at det var lagt til grunn svært dårlige data for de beste Intel CPU'ene ag svært gode data for de beste AMD CPU'ene i forhold til hva som var å oppdrive! Resultatet er den knekken en ser nederst på kurvene for P4. Bør jeg ikke bli litt skeptisk da?

 

snorreh: Jo det er svært interessant sammenligning dette og jeg synes spesielt den avrundingen på slutten av kurven til P4 er interessant. Den ville forklart et par umodne teorier jeg sitter å grubler på, men jeg er redd den krumningen først og fremst er et resultat av at datagrunnlaget er for dårlig. Den strider nemlig sterkt imot de faktum at krumningen ikke kan komme så brått og at 3.06 har HT.

Endret 23. mars 2004 av Knick Knack

[shit89]

Er ikke sikker, men yter ikke P4 bedre med DDR4000 minne?

[Knick Knack]

Ser forøvrig at du har gjort vesentlige forbedringer i grafen nå. krumningene kommer som forventet mye slakkere og starter mye tidligere. Dessuten ser en at krumningen fremkommer for alle prosessorseriene, noe som også er som forventet.

 

Et øyeblikk så skal jeg komme med det siste pirket før jeg friskmelder grafen!

[rlz]

Er ikke sikker, men yter ikke P4 bedre med DDR4000 minne?

Det er det ingenting som heter.

[Knick Knack]

Ok her er det siste pirket:

 

1) Grafene antyder at variabelen kun er CPU frekvens. I tilfellet med P4 2.8->3.06GHz og Opteron 144->146 er dette ikke riktig, men jeg foreslår å beholde sammenhengen da den vil vise fordelen med HT og høyere referanseklokke for minnet. (selv om HT ikke har betydelig invirkning på denne testen så håndterer den tross alt noe multitasking mellom OS og Super Pi)

 

2) Opteron 144 ser ut til å være plottet med resultater for DDR400. Det er forsåvidt greit nok, men det stemmer ikke med teksten over bildet i første post både fordi det ikke er spec og fordi det står eksplisitt at den kjører på DDR333. Jeg mener det ville vært bedre å plote resultater fra en test med DDR333 fordi da vil en bedre se fordelen ved å øke minnebussen til DDR400 på 146 og det er tross alt spec.

 

3) P4 3.06GHz er en vrien cpu da den er testet med svært mange chipset og minne typer. Jeg foreslår å benytte data fra en test med i845 chipset da dette er den mest naturlige DDR platformen for denne brikken. Altså se bort fra x86-secret sin test på i875 som er et "for bra" chipset til denne cpu'en. behold for all del i850 grafen den er en viktig del av P4's totalbilde.

 

4) Ser ingen feil i testen som målte P4E 3.2GHz til 41s?

 

5) avventer fortsatt flere tester av P4C 3.4GHz før jeg synes noe som helst om den.

 

Med disse data så mener jeg grafen er god nok til at en i allefall kan begynne å se konturene om ikke trekke konklusjoner!

Endret 23. mars 2004 av Knick Knack

[snorreh]

Men grunnen til at jeg klager på snorreh sin fremstilling her er at jeg har han beskyldt for å ha bestemt seg for en teori for så å velge ut de data som passet han best og bortforklare/se bort fra de data som ikke passet til teorien. Om en leser hans respons på de data jeg fant ved tilfeldig søk så kommer dette svært tydelig frem.

Jeg har da ikke bortforklart noen helst data

 

Alle date er tatt med i gjennomsnittet av hver enkelt prosessor, også de de omdiskuterte 50 og 60 sekunders resultatene for P4B 3.0GHz med DDR-minne

 

Jeg presiserer, jeg har ikke sett bort fra noen data annet enn de som er forekommet som resultat av overklokking.

 

Jeg tok en titt på den grafen som først ble presentert. Deretter lette jeg litt rundt på nettet og fant konsekvent at det var lagt til grunn svært dårlige data for de beste Intel CPU'ene ag svært gode data for de beste AMD CPU'ene i forhold til hva som var å oppdrive! Resultatet er den knekken en ser nederst på kurvene for P4. Bør jeg ikke bli litt skeptisk da?

Du må gjerne tro det, men det er det ingen grunn til å hevde. De fleste resultatene er hentet fra Hardware.no sine tester faktisk, eller stoler du ikke på dem heller?

 

snorreh: Jo det er svært interessant sammenligning dette og jeg synes spesielt den avrundingen på slutten av kurven til P4 er interessant. Den ville forklart et par umodne teorier jeg sitter å grubler på, men jeg er redd den krumningen først og fremst er et resultat av at datagrunnlaget er for dårlig. Den strider nemlig sterkt imot de faktum at krumningen ikke kan komme så brått og at 3.06 har HT.

Bra du i minste synes det er interessant da, noe annet poeng har jeg faktisk ikke

 

Jeg bruker alle data jeg til enhver tid har tilgjengelig, så jeg fatter fortsatt ikke hva du mener jeg har gjort galt her?

 

Som sagt hvis du mener du kan gjøre det så mye bedre, så værsågod!

[mar]

Er jo litt morsomt hvor mye styr man kan lage av super pi resultater. Testen sier jo ikke noen annet enn hvor lang tid det tar å finne pi med flere desimaler enn folk flest trenger. Er jo mange som mener at dette er en god måling på prosessorens ytelse når det gjelder tallknusing, men det er jo ikke nødvendigvis sant.

 

Veldig mange tunge regningsoppgaver er basert på matrisesystemer der de enkelte koordinatene påvirker hverandre etter en eller annen formell. For eksempel ved simulering av energifordeling (feks et prosjektil som treffer en metall plate).

 

Algoritmene for å løse slike oppgaver er så også (nesten)alltid basert på at man skal bruke flere prosessorer.

 

At FPU delen i AMD sine siste prosessorer er vesentlig bedre enn den i P4 er det ingen tvil om, det ser vi jo også i super pi testen. At super pi sier noe om prosessorens evner når det gjelder tunge regneoppgaver er ikke fult så sikkert. Super pi kjører bare en tråd og dersom jeg ikke tar feil så er det vel ikke så mye matrise regning involvert heller.

 

Et matrise problem som kunne løses ved parallellprosessering ville nok gitt helt andre resultater. P4 prosessoren kunne da fått utnyttet fordelene med HT, og skikkelig SSE støtte hadde fått veldig mye å si (dersom programmet faktisk brukte det).

 

Ble litt på siden av tema dette her, men det er jo så mange som har argumentert med at super pi sier alt om tallknusingsevnen, noe som er ganske langt fra sannheten. Det eneste Super pi sier noen om er ytelsen på en tradisjonell X86 FPU.

 

Sikkert mange rare feil her, er ”litt” trøtt..

[Knick Knack]

Hadde det ikke vært interessant hadde jeg ikke kommentert det vel?

 

presiserer fortsatt det med gjennomsnitt:

 

Hva gjennomsnitt angår: Tenk på dette: om du vil vite hvor raskt en bil kan akselerere fra 0 til 100. hva gjør du da? jo du kjører selvsagt flere testløp. tar du gjennomsnittet? Nei! du tar den beste tiden fordi dette er hva bilen kan yte. Alle tester som viser lavere enn den beste skyldes at sjåføren ikke har kjørt nært nok optimalt. (han vil aldri klare 100% optimalt). Samme gjelder for Super Pi testen. Noen ganger vil resultatet bli dårligere fordi prosesser i bakgrunnen (det kan gjerne være 20-40 stk) finner på å dra noe ytelse mens testen pågår!

 

Det er vel ikke sannsynlig at det skiller 12sek mellom RDRAM og DDR for 3.06GHz? det er en økning på 25% fra RDRAM det! Greit at jeg har påstått at RDRAM er dramatisk bedre enn DDR, men jeg sa ikke at det var overnaturlig mye bedre Ergo må testen som ga 60s være helt på jordet... eventuelt så har hw.no juksa!

Endret 23. mars 2004 av Knick Knack

[snorreh]

Knick Knack: Nå har jeg også oppdatert teksten i min første post. Håper du endelig er fornøyd nå

[Martin Lie]

AMD (...) ikke er 100% perfekt til alt fra 3D-spilling til padleåre.

Hehe. Denne kommentaren var det meget god Inquirer-stil over. Kudos! (Ok da, kanskje jeg har lusen humor...)

 

eller at Intel (kanskje spesielt Itanium?) ikke er 100% perfekt til alt fra tallknusing til gummibåt

Haha. Godt å se at andre har sarkasmen i behold også! Men gummibåt var dessverre litt for likt padleåre. Du skulle sagt "lommelykt" eller noe sånt. Fikk likevel en god latter. (Se kommentaren om min humor, over...)

 

Jepp, å vifte med "titler" er noe herk. Mister desverre respekten for folk som hele tiden må tittelere seg for et eller annet

Sier, DU, som har en yrkestittel i NICKET. Haha! (Ja, det var 100% pure ironi.)

[rlz]

Haha. Godt å se at andre har sarkasmen i behold også! Men gummibåt var dessverre litt for likt padleåre. Du skulle sagt "lommelykt" eller noe sånt. Fikk likevel en god latter. (Se kommentaren om min humor, over...)

Det var med vilje for å mest mulig kopieree Knick Knack

[Knick Knack]

Knick Knack: Nå har jeg også oppdatert teksten i min første post.  Håper du endelig er fornøyd nå

Jeg har nettopp spist middag og er derfor kjempefornøyd!

 

Når det gjelder grafen så har jeg fortsatt et par småting jeg mener ville bringe den nærmere den virkelige verden, men noe dramatisk er det ikke.

 

som sagt tidligere:

flytt p4e->41, Opt144->50 og p4b 3.06->52 vet jo ikke hvor mye arbeid du gidder legge i det...

 

Da ser en hvordan det egentlig henger sammen. At p4b 2.8 blir "stikkende ut" er naturlig da den er høyeste p4b uten HT. En får også frem fordelen med raskere minne på Opteron. På den annen side så ser en krumningen bedre nå. Kanskje plotte begge? Kan jo plotte Opt 144 med DDR400 med stiplet linje slik at en fortsatt ser krumningen for Opteron også.

 

Det står også i første post at alle Athlon xp kjører DDR400. jeg tror ikke det stemmer.

Endret 23. mars 2004 av Knick Knack

[rlz]

Jeg har nettopp spist middag og er derfor kjempefornøyd!

Litt off-topic, men denne går inn i listen min over godbiter fra forumet

[Simen1]

som sagt tidligere:

flytt p4e->41, Opt144->50 og p4b 3.06->52 vet jo ikke hvor mye arbeid du gidder legge i det...

Sikker på det? Det ser ikke særlig riktig ut i forhold til de andre punktene..

[Knick Knack]

som sagt tidligere:

flytt p4e->41, Opt144->50 og p4b 3.06->52 vet jo ikke hvor mye arbeid du gidder legge i det...

Sikker på det? Det ser ikke særlig riktig ut i forhold til de andre punktene..

Jeg tok det rett ut fra hue. kanskje jeg husket feil. husk det er her snakk om å plotte DDR333 kontra DDR400 data for denne prosessorern. Jeg mener å huske 50 var det tallet snorreh hadde selv. før jeg fant en test der de kjørte DDR400, som er utenfor spec.

 

Jeg synes forøvrig det ser fornuftig ut. Da får en omtrent samme endring fra 1.6 til 1.8 GHz som en får fra 2.0 til 2.2 GHz. Det store spranget kommer mellom 1.8 og 2.0 i steden for mellom 1.6 og 1.8. Det er naturlig siden det er her en egentlig går fra DDR333 til DDR400.

Endret 23. mars 2004 av Knick Knack

[snorreh]

[...]

som sagt tidligere:

flytt p4e->41, Opt144->50 og p4b 3.06->52 vet jo ikke hvor mye arbeid du gidder legge i det...

[...]

Det står også i første post at alle Athlon xp kjører DDR400. jeg tror ikke det stemmer.

Jeg har nå oppdatert figuren med gjennomsnittet for alle tilgjengelige data, og lar det ligge inntil vesentlig flere data blir tilgjengelig. Opteron 144 på 50 sekunder, hvor får du det fra og sa du ikke tidligere 45 sekunder for denne prosessoren med DDR400 (jeg hadde tidligere 48 sekunder for den med DDR333) da? Som sagt så er gjennomsnittet for alle tilgjengelige data (50,51,52,54,54,55,56,60) på P4B 3.06GHz nøyaktig 54 sekunder, så den lar jeg også stå.

 

Jeg er rimelig sikker på at alle Athlon XP dataene er med DDR400 minne, men selv om de skulle ha vært med DDR333 så utgjør ikke det større effekt en feilmarginen på Super PI som er +/- 1-2 sekunder likevel ifølge mine egne tester.

Endret 23. mars 2004 av snorreh

[Knick Knack]

Da var det vel 48 jeg mente... husket feil. Jeg er nå uansett prinsippielt imot å regne gjennomsnitt da det egentlig bare er å ta det riktige resultatet for så å legge til gjennomsnittlig feilmargin. Hvorfor skulle en ønske å legge til den? Svar meg på det!

[Coffie=JavaCode]

Mener ikke å ødlegge for dere, men who the fucks care? Det er en ******* test. Og den tester ting og tang, denne testen handler om å regne ut noen jævlige tall. Hadde ikke bryd meg om min prossesor brukte 34 dager på den testen, så lenge den funkt til det jeg bruker den til.

 

Og dette viser at prossesorene er så god som like gode til det meste vanlige ting, så lenge du ikke har tatt et alvorlig galt kariere valg og skal finne ut hvor mange desimaler det er i PI.

 

Dette sier dessuten ikke så alt for mye om prossesoren er rask, men bare at prossesor kjernen er rask.

 

Men kanksje viktiks så kan man aldri stole på tall, eller grafer, statestikker, det er egentlig bare det du selv har prøvet at du kan stole på hva som er bra.

[trMaG]

Her er linken:

http://www.x86-secret.com/articles/cpu/p43g/p43g-5.htm

Lurte bare på hva slags minne som benyttes i testing av P4 3.06GHz systemet.

Antagelig er det DDR333 eller DDR266

 

heisann,

 

er tilbake fra pausen. Glad for å se at det fortsatt diskuteres. Leste gjennom artikkelen og i siste setningen i artikkelen står det at det ble brukt Dual DDR333-minne for P4 3.06GHz systemet. I tillegg står det at de to andre P4 systemene ble testet med Dual DDR400 + PAT:

A noter que le P4 3.06 Ghz fonctionne en mode DualDDR333 (puisque FSB533) et que les deux autres P4 fonctionnent en Dual DDR400 + PAT.

 

 

I forbindelse med gjennomsnittet:

Hva gjennomsnitt angår: Tek på dette: om du vil vite hvor raskt en bil kan akselerere fra 0 til 100. hva gjør du da? jo du kjører selvsagt flere testløp. tar du gjennomsnittet? Nei! du tar den beste tiden fordi dette er hva bilen kan yte. Alle tester som viser lavere enn den beste skyldes at sjåføren ikke har kjørt nært nok optimalt. (han vil aldri klare 1005 optimalt). Samme gjelder for Super Pi testen. Noen ganger vil resultatet bli dårligere fordi prosesser i bakgrunnen (det kan gjerne være 20-40 stk) finner på å dra noe ytelse mens testen pågår!

 

Slik jeg ser det er det forfatteren av testen/grafen som velger hvilket datagrunnlag han legger som grunnlag. Det viktigste mener jeg er at personen som gjennomfører testen eller lager grafen oppgir hvilke kriterier og forutsetninger personen har lagt til grunn for testen/grafen, og at man er konsekvent for alle produktene som testet(likt for alle) . Da er det også opp til andre å kritisere dette grunnlaget og valgene den personen har gjort, slik du gjør nå (og som du i prinsippet har rett til).

 

Jeg vet ikke nok til å kunne si hva som er "normen" (det som vanligvis blir gjort) når det gjelder prosessortester, men skulle tro at et gjennomsnitt av et gitt antall gjennomkjøringer med samme testoppsett vil gi det mest troverdige datagrunnlaget. En annen måte, som du nevner i posten din, er å velge den gjennomkjøringen som gir det beste resultatet.

 

For bilprodusenter og bedrifter som skal selge noe er det selvfølgelig i deres interesse og velge den beste gjennomføringen og distribuere dette som fakta. For oss forbrukere vil det være mest interessant å se på et gjennomsnitt av gjennomkjøringer, siden det alltid er unøyaktigheter i teknisk utstyr og i software.

Selvfølgelig mener jeg at det er riktig å fjerne resultater som ikke ligger fjernt fra forventningsområdet for testen (en verdi var jo på 60 mens de andre lå mellom 50 og 54)

 

Et særdeles vikig punkt vi må huske på er at grafen som snorreh laget ikke er en profesjonell graf laget av statistikere, men en graf laget av en med interesse for data og som har samlet inn litt data bare for å kunne gjøre en enkel sammenlikning. I en profesjonell sammenlikning måtte man ha tatt for seg datagrunnlaget på en mye mer nøyaktig måte og kanskje gjort egne tester av systemene. De kommentarene knick knack kommer med er bra i den forstand at den gjør grafen mer profesjonnell, med bedre datagrunnlag. Men i utgangspunktet var ikke dette en profesjonell sammenlikning, men en subjektiv vurdering laget av en med interesse for data.

 

Istedenfor å angripe grafen og dens opphav til de grader, burde du heller lage din egen med et bedre og grundigere datagrunnlag. Alternativt lage en i samarbeid med snorreh! Noe dere mer eller mindre nå har gjort, men på en særdeles aggressiv måte.. hehe

 

mag

 

EDIT: skrivefeils

Endret 23. mars 2004 av trMaG

[snorreh]

Da var det vel 48 jeg mente... husket feil. Jeg er nå uansett prinsippielt imot å regne gjennomsnitt da det egentlig bare er å ta det riktige resultatet for så å legge til gjennomsnittlig feilmargin. Hvorfor skulle en ønske å legge til den? Svar meg på det!

Jeg tror jeg har begrunnet metoden jeg benytter godt nok allerede, og bruker altså ALLE tilgjengelige data uten unntak som grunnlag for beregning av et representativt gjennomsnitt for hver enkelt prosessor. Så også for Opteron 144 og alle de andre prosessorene som er med her... Jeg lar figuren snakke for seg selv, men den bør ses i sammenheng med en feilmargin på minst +/- 1-2 sekunder for hver prosessor selvsagt.

Endret 23. mars 2004 av snorreh