kyrsjo Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 Britene vil kutte Microsoft i skolen Syns eg les slike saker oftare og oftare. Du også? Bare koselig dette Tyder vel på at F/OSS er i ferd med å vinne aksept, også på desktop-markedet. Forøvrig liker jeg det nye designet til linux1 veldig bra Lenke til kommentar
JBlack Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 (endret) En annen tråd her på forumet fikk meg til å begynne å sjekke litt rundt float, double og long double, standarder, hastighet osv. Så jeg skrev et enkelt lite program, kompilerte og testet. Resultatet jeg fikk var noe overraskende: x86_64 AMD Athlon 64 Processor 3000+ float: 38 double: 21 long double: 42 i686 Intel® Pentium® 4 Mobile CPU 2.00GHz float: 1053 double: 1054 long double: 1070 Tider er tall brukt i hundredeler per sec. Og ingen optimaliseringsparamtre er gitt til gcc. Rimelig stor forskjell. Så dette må gjøres litt mer seriøst. Hvilke benchmarking program anbefaler folket? edit: Samme på en sparc (ukjent frekvens) float: 1467 double: 37 long double: 249 Moralen: Bruk alltid double til floating point dersom det er god nok presisjon. float er tregere Endret 10. mai 2005 av JBlack Lenke til kommentar
Velmont Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 La oss få programmet då - eg har ein Sparc eg kan teste på. Samt centrino- laptopen min og denne p4-maskina. :] Lenke til kommentar
JBlack Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 Ok, men det er bare et kjapt hack, og er ikke noen god form for benchmarking. For eksempel vil optimalisering (gcc -o2) gjøre at programmet kjører på omtrent null tid. Så om gcc på en plattform foretar noen form for optimalisering selv om det ikke er gitt i parameter, og som ikke foregår på andre plattformer, så vil dette kunne gi utslag. #include <stdio.h> #include <sys/times.h> #include <unistd.h> #define ITERATIONS 10000000 int main(){ float f; double d; long double ld; long int i; struct tms ts; clock_t t; printf ("%d %d %d\n",sizeof(float),sizeof(double),sizeof(long double)); printf ("%d\n",sysconf(_SC_CLK_TCK)); times(&ts); t=ts.tms_utime; for (i=0;i<ITERATIONS;i++){ f=f*1.5; f=f/1.2; } times(&ts); printf("float: %d\n",ts.tms_utime-t); times(&ts); t=ts.tms_utime; for (i=0;i<ITERATIONS;i++){ d=d*1.5; d=d/1.2; } times(&ts); printf("double: %d\n",ts.tms_utime-t); times(&ts); t=ts.tms_utime; for (i=0;i<ITERATIONS;i++){ ld=ld*1.5; ld=ld/1.2; } times(&ts); printf("long double: %d\n",ts.tms_utime-t); return 0; } Lenke til kommentar
kattemat Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 Kompiler den med -O3 -funroll-loops og prøv. Oj - plutselig har du en lynkjapp maskin Lenke til kommentar
JBlack Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 Kompiler den med -O3 -funroll-loops og prøv. Oj - plutselig har du en lynkjapp maskin Som sagt, -O2 holder. -O1 er faktisk nok. Så noen god benchmark er dette ikke. Lenke til kommentar
kattemat Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 (endret) tja... på min boks må jeg iallfall bruke både loop unrolling og O3 for å få 0 på alle testene(som var poenget mitt). Edit: holdt faktisk med loop-unroll og O2 Endret 10. mai 2005 av kattemat Lenke til kommentar
JBlack Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 (endret) tja... på min boks må jeg iallfall bruke både loop unrolling og O3 for å få 0 på alle testene. Ok da, fra 1 til 0. Edit: -O1 -funroll-loops Endret 10. mai 2005 av JBlack Lenke til kommentar
drall Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 (endret) Det blir optimalisert bort fordi du ikke bruker resultatet. Ellers er float reknet for å være raskere enn double på 32-bit x86, spesielt på konvertering til int. Double gir selvsagt bedre presisjon. edit: Tabell over ytelsen til ulike datatyper på en Xbox. Endret 10. mai 2005 av drall Lenke til kommentar
kyrsjo Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 -funroll-loops har en bakside: koden blir større. Er du skikkelig uheldig går den ikke inn i cache, og da blir det plutselig myyyye treigere... Lenke til kommentar
LessThanJake Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 Noen som vet om FreeBSD har pgrep eller noe lignende. Sitter på skolen, så jeg kan ikke instalere noe? Lenke til kommentar
LessThanJake Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 Angående det benchmark-programmer. Det er klart at float er raskere en double ellers hadde det ikke eksistert. Kan ikke gunnen være at når du skriver 1.5 eller 1.2, så er det double verdier og de må konvergeres før operasjonen kan gjennomføres. Husker ikke helt men 1.2F er det vel for å lage en float. Ytelsesforskjellen på amd-en og intellen er også mistekelig. De er vel klokket ca likt, og et slikt programm er veldig avhengig av klkkefrekvens? Lenke til kommentar
pgdx Skrevet 10. mai 2005 Forfatter Del Skrevet 10. mai 2005 long double: 42 Ser ut som om du har funnet svaret! Lenke til kommentar
zyp Skrevet 10. mai 2005 Del Skrevet 10. mai 2005 (endret) Forskjellen på float og double ligger bare i presisjonen. En double tar mer plass enn en float, men har flere gjeldene siffer og større rekkevidde for potens-leddet. Siden en float er mindre så er det nok ikke usannsynlig at det også er raskere å håndtere. Jeg kjørte testen et par ganger, og alle resultatene ble rundt 0 etterhvert, grunnen er at kode optimeres bort. For å forhindre at koden optimeres bort la jeg nøkkelordet volatile foran de tre variablene. Da fikk jeg mer fornuftige resultater. bash-2.05b$ gcc bench.c -o bench bash-2.05b$ ./bench 4 8 12 100 float: 28 double: 23 long double: 38 bash-2.05b$ gcc bench.c -o bench -O3 bash-2.05b$ ./bench 4 8 12 100 float: 28 double: 23 long double: 37 bash-2.05b$ gcc bench.c -o bench -O3 -funroll-loops bash-2.05b$ ./bench 4 8 12 100 float: 28 double: 22 long double: 39 bash-2.05b$ gcc bench.c -o bench -funroll-loops bash-2.05b$ ./bench 4 8 12 100 float: 29 double: 23 long double: 39 bash-2.05b$ gcc bench.c -o bench -Os bash-2.05b$ ./bench 4 8 12 100 float: 27 double: 34 long double: 38 Endret 10. mai 2005 av zyp Lenke til kommentar
objorkum Skrevet 11. mai 2005 Del Skrevet 11. mai 2005 Ingen er mer «åpne» enn Microsoft Lenke til kommentar
kattemat Skrevet 11. mai 2005 Del Skrevet 11. mai 2005 Var voldsomt med forklaringer da Tror både JBlack og jeg vet hva som skjer både ved -funroll-loops og diverse stages av optimalisering. Det hele var bare en spøk for å vise at en ente opp med å bruke 0 ticks på alle casene etter som koden faktisk blir mer eller mindre "optimalisert bort". Lenke til kommentar
olefiver Skrevet 11. mai 2005 Del Skrevet 11. mai 2005 Ingen er mer «åpne» enn Microsoft Fra digi.no: Kommersielle selskaper som IBM og Sun bruker ikke GPL, men benytter andre lisenser som også er godkjent av Open Source Initiative. IBM leverer linux baserte systemer, det er vel GPL... Fjonfjotten Ebert mener kanskje at de ikke slipper egne produkter på GPL? Noen som vet bedre enn meg? Lenke til kommentar
JBlack Skrevet 11. mai 2005 Del Skrevet 11. mai 2005 Jada, programmet mitt var aldri ment som noen seriøs benchmarking. Jeg var bare nysgjerrig på hastigheten på float, double og long double. Hva som er raskest på en gitt plattform er ikke direkte avhengig av presisjonen, men av størrelsen på FPU'en. Dersom FPU'en er 64bit og ikke har en 32bit modus, så må CPU'en bruke software for å emulere dette. Og da vil float bli tregere enn double. Programmet mitt har for øvrig en større og mer alvorlig feil. Det er at funksjonen jeg regner ut er eksponensiell og vokser mot uendelig, noe som fører til overflow. Dette gjør at det er ikke effektiviteten på matematikken som evalueres, men effektiviteten av feilhåndteringen. I'll be back! Lenke til kommentar
JBlack Skrevet 11. mai 2005 Del Skrevet 11. mai 2005 I'm back! Jeg har laget et eget topic på dette over i programmering/C++. Interesserte henvises dit. http://forum.hardware.no/index.php?showtopic=416483 For de som måtte lure, men ikke gidder lese masse, P4 og AMD64 er nå mye nærmere verandre hastighetsmessig. AMD64 3000+ (2GHz) nesten, men ikke fullt, dobbelt så rask som P4 mobile 2GHz. Og double er like rask som float. Lenke til kommentar
Cronius Skrevet 11. mai 2005 Del Skrevet 11. mai 2005 Ingen er mer «åpne» enn Microsoft Dette skillet mellom GPL og andre lisenser innen åpen kildekode gjenspeiler den samme interne striden innen åpen kildekodefellesskapet som kommer til uttrykk når for eksempel GNU-gründer Richard Stallman insisterer på å snakke om «free software» framfor «open source». At heller ikke digi.no har skjønt at det faktisk er en vesentlig forskjell mellom åpen kildekode og fri programvare er så grufult amatørisk at jeg begynner å røyte. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå