Gå til innhold

Den frie kafeen


Anbefalte innlegg

Videoannonse
Annonse

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. :blink:

 

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 av JBlack
Lenke til kommentar

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

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

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 av zyp
Lenke til kommentar

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

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. :blush:

 

I'll be back! :yes:

Lenke til kommentar
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

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...