[C++] altera nios float vs double

[Verwijderd]

Voor een test net de altera nios ii processor had ik de volgende functie gemaakt om het integraal van een tweede orde vergelijking te benaderen en zo de processor te stressen

C++:

double secondOrderIntegral(double a, double b, double c, double intStart, 
    double intStop, double step)
{
  double pointer;
  double integral = 0.0;
  
  pointer = intStart;
  
  while (pointer <= intStop)
  {
    integral+=step*((a*pointer*pointer)+(b*pointer)+c);
    pointer+=step;
  }
  return(integral);
}

Daarvan heb ik een aanroep gedaan moet de volgende argumenten
a=3.0
b=0.0
v=2.0
intStart=-1.0
intStop=1.0
step=0.01

Daarna heb ik hetzelfde gedaan maar dan met een floating point berekening:

C++:

float secondOrderIntegral(float a, float b, float c, float intStart, 
    float intStop, float step)
{
  float pointer;
  float integral = 0.0;
  
  pointer = intStart;
  
  while (pointer <= intStop)
  {
    integral+=step*((a*pointer*pointer)+(b*pointer)+c);
    pointer+=step;
  }
  return(integral);
}

Vervolgens heb ik het aantal ticks gemeten die nodig is om de functie uit te voeren en dat vertaald naar een tijd, daar kwam uit dat voor de double ongeveer 13 ms nodig was maar voor de float 5 ms

Ik zou verwachten dat de double sneller was met vermenigvuldigen dan de float maar dat blijkt niet zo te zijn. Ik zou hier geen verklaring voor weten, kan iemand mij dit verhelderen? Ook een google zoektocht deed blijken dat een double sneller moet zijn, maar dit is gemeten op een pentium mmx ipv een nios processor en daarom (volgens mij) niet zo heel veel waard kwa meting

Even voor de duidelijkheid
Ik draai op een Cyclone II fpga waarop ik de Nios II/f softcore processor heb gedownload, daarop heb ik de MicroC rtos draaien met mijn programma in een thread met de hoogste prioriteit

[ Voor 13% gewijzigd door Verwijderd op 18-07-2005 11:19 ]

[El Psycho]

ik vind het vrij logisch dat een berekening met hogere precisie langer duurt dan een berekening met lagere precisie.... (double en float zijn beide floating point waarbij double 2 keer zo groot en dus ook 2 keer zo precies is)

[Zoijar]

Misschien moet je even kijken wat sizeof() zegt over double en float op jouw platform. Wellicht is een double 64it en een float 32bit, maar het kan ook heel goed v. 64 en 128 it zijn oid. of iets anders exotisch.

[Verwijderd]

De double was inderdaad 64 bit terwijl de float 32 bit is wat natuurlijk het snelheidsverschil verklaard. Gecheckt via de sizeof functie.

Op google had ik dit gevonden

http://www.gillius.org/files/fixtest.cpp

daaruit werd in dat geval geconcludeerd dat double sneller was, een quote uit het commentaar deel:

data as of 3/25/00 -- PIII 500 under Win98SE DOS box, 100k calcs
gcc -s -m486 -fomit-frame-pointer -ffast-math
Float : .130-.135
Double: .125-.135
Fixed : .060
Float was almost always slower but a little
gcc -s -o3 -m486 -fomit-frame-pointer -ffast-math
Float : .030-.035
Double: .030-.035
Fixed : .005 or less??? (.005 is lowest measurable)

[ Voor 68% gewijzigd door Verwijderd op 18-07-2005 12:07 ]

[.oisyn]

Voor een x86 maken de gebruikte types niet uit, een floating point register is immers 80 bits lang en de daadwerkelijk gebruikte precisie hangt af van de instellingen van de FPU. Het enige verschil tussen float en double is derhalve dat er voor de float 4 bytes gefetched moeten worden en voor double 8, maar met weinig lokale variabelen kun je er vanuit gaan dat alles in de cache staat en er dus geen verschil is.

[NMe]

Verwijderd schreef op maandag 18 juli 2005 @ 11:53:
Gecheckt via de sizeof functie.

offtopic:
sizeof is geen functie, maar een taalelement (een operator om precies te zijn).

[Glimi]

-NMe- schreef op maandag 18 juli 2005 @ 13:43:

offtopic:
sizeof is geen functie, maar een taalelement (een operator om precies te zijn).

Een operator is ook een functie, echter met andere syntax. Het kan zijn dat het een language construct is, maar dat heeft weinig met het operator zijnde te maken in C++.
Niet kwaad bedoelt en al helemaal niet als het bekende 'Acedemische Afzeiken'.

[.oisyn]

Nee, niet iedere operator is een functie (denk bijvoorbeeld aan ::, ., .*, -> en ->*), en sizeof is daar één van, aldus Bjarne

[Glimi]

.oisyn schreef op maandag 18 juli 2005 @ 13:55:
Nee, niet iedere operator is een functie (denk bijvoorbeeld aan ::, ., .*, -> en ->*), en sizeof is daar één van, aldus Bjarne

Conceptueel gezien vind ik dat toch wel vrij vreemd eigenlijk. Opzicht levert sizeof een mapping/relatie van ruimte A naar ruimte B.

[Zoijar]

Elke functie is toch eigenlijk een operator in C++, daar het strongly typed language is?

[.oisyn]

Glimi schreef op maandag 18 juli 2005 @ 14:15:
[...]

Conceptueel gezien vind ik dat toch wel vrij vreemd eigenlijk. Opzicht levert sizeof een mapping/relatie van ruimte A naar ruimte B.

Tja, als je er per se andere termen bij wil betrekken dan diegene die in de specificatie van de taal zelf gedefinieerd zijn, dan zou je sizeof kunnen zien als een functie ja. Zelf houd ik me liever aan de specificatie van de taal, waarin een functie een identifier binnen een namespace met een return-type en 0 of meer parameters van een willekeurig type, en al dan niet cv-qualified. En de sizeof operator is volgens dit principe geen functie, om het simpele feit dat je geen types als parameters mee kunt geven aan een functie, en het feit dat expressions die je meegeeft niet geevalueerd worden.

[Glimi]

.oisyn schreef op maandag 18 juli 2005 @ 15:08:
Tja, als je er per se andere termen bij wil betrekken dan diegene die in de specificatie van de taal zelf gedefinieerd zijn, dan zou je sizeof kunnen zien als een functie ja.

Hoe kom je erbij dat ik perse er andere dingen bij wil betrekken? Ik ken de C++ specificatie gewoon niet op detail niveau en weet wel hoe in de wiskunde een functie gedefinieerd is. Dat is alles en ik zie daarin geen reden om zo suf te reageren.

Je uitleg is wel duidelijk though.

[.oisyn]

Je neemt mijn post te letterlijk, ik bedoel niet dat jij per se andere termen erbij wilt betrekken, ik bedoelde het meer zoals je het nu zelf schetst: je gebruikt andere termen omdat je dat gewend bent. Maar dat maakt de opmerking van -NMe- niet minder waar

[Glimi]

Ok, excuus

[MSalters]

.oisyn schreef op maandag 18 juli 2005 @ 15:08:
[...]
Zelf houd ik me liever aan de specificatie van de taal, waarin een functie een identifier binnen een namespace met een return-type en 0 of meer parameters van een willekeurig type, en al dan niet cv-qualified.

Constructors en destructors zijn geen functies? En operators?

[.oisyn]

Ik zou 't geen functies willen noemen nee. Je kunt er bijvoorbeeld geen adres van opvragen . Maar 't zijn dan ook special cases.

[NMe]

MSalters schreef op maandag 18 juli 2005 @ 16:44:
Constructors en destructors zijn geen functies? En operators?

Standaard operators wel, volgens de omschrijving van .oisyn. Die hebben toch een returnwaarde en 0 of meer parameters?

C++:

mijnObject& operator+(const mijnObject&);

[MSalters]

En wat is de identifier van operator+? Overigens heeft sizeof een identifier, 1 argument en een returnwaarde terwijl het toch geen functie is.

[MSalters]

.oisyn schreef op maandag 18 juli 2005 @ 16:52:
Ik zou 't geen functies willen noemen nee. Je kunt er bijvoorbeeld geen adres van opvragen . Maar 't zijn dan ook special cases.

Zou erg onhandig zijn als een ctor geen functie is. Want dan kan ie geen exceptions gooien, of lokale variabelen declareren, of andere functies aanroepen. Ongeveer het enige was mist is een naam. Vervelend dat je nu juist een naam nodig hebt om een adres te krijgen