double belegt weniger Speicher als float?

[LuXXuS 9. (aichn)]

Hi Leute!

Ich brauch mal euren Expertenrat - ich habe hier ein paar Routinen 
geschrieben, welche ich in einer .h per Definition komplett als float 
oder als double kompilieren lassen kann.

Grund ist, je nach geforderter Genauigkeit umzustellen, um die 
Geschichte zu beschleunigen und Code zu sparen.

Dachte ich, aber da lieg ich offenbar falsch.


Wenn ich alles als double berechne, dann sieht der Speicher 
folgendermaßen aus:

12926 Code
  539 Data
   64 Const

Als float:

14466 Code
  427 Data
   64 Const

Compiler ist IAR und der Controller ist ein MSP430.

Also dass bei double die Größe der Daten ansteigt leuchtet mir ja ein, 
aber wieso wird der Code bei float größer?


Kann mir da einer was zu sagen?


---------------------------------

Nachtrag: Eine bestimmte Berechnung dauert im double 77044 Cycles
                                           im float  71957 Cycles

Schneller ist float also, wenn auch nur geringfügig...

[Klaus W. (mfgkw)]

Nach C-Standard werden alle Gleitkommaoperationen in double ausgeführt, 
also auch wenn du float*float rechnest.
Das kostet logischerweise mehr Code als gleich alles in double zu 
halten.

Ich vermute, daß es daran liegt (kenne dein System nicht).

float spart nur Speicher; besonders bei großen Feldern natürlich.

[LuXXuS 9. (aichn)]

Klaus Wachtler schrieb:
> Nach C-Standard werden alle Gleitkommaoperationen in double ausgeführt

Ach so ist das - das wusste ich nicht. Ich dachte immer, dass 
double-Genauigkeit ja eher selten nötig ist, daher lieber float, wenns 
reicht...weil eben auch schlanker im Betrieb.

Klaus Wachtler schrieb:
> kenne dein System nicht

Was musste wissen?

[Klaus W. (mfgkw)]

LuXXuS 909 schrieb:
> Klaus Wachtler schrieb:
>> kenne dein System nicht
>
> Was musste wissen?

Bei avr-gcc ist es beispielsweise so, daß es gar keinen eigenenen 
double-Typ gibt, bzw. sind float und double dort identisch.
Dann gilt meine obige Aussage natürlich nicht.
Ob das bei dir auch so ist, müsstest du bei deinen Unterlagen finden 
(oder einfach sizeof(double) und sizeof(float) ausgeben und 
vergleichen).

[(prx) A. K. (prx)]

Klaus Wachtler schrieb:

> Nach C-Standard werden alle Gleitkommaoperationen in double ausgeführt,
> also auch wenn du float*float rechnest.

Nixda. Das war zwar zu Grossvaters Zeiten (anno K&R) mal so definiert, 
gilt aber schon seit ANSI C nicht mehr.

[Egal Anders (Gast)]

> Nach C-Standard werden alle Gleitkommaoperationen in double ausgeführt

In der Praxis ist es um einiges verwickelter.

Zumindest der GCC betreibt einigen Aufwand um so weit wie möglich bei 
float zu bleiben. Gibt dann sogar 2 Sätze Funktionen (sin, cos...) in 
der Library.

Hast du schon kontrolliert, ob in deiner float-Variante die Libraries 
doppelt eingebunden wurden? Z.B. "sin" und "sinf".

[Volker S. (volkerschulz)]

A. K. schrieb:
> Klaus Wachtler schrieb:
>
>> Nach C-Standard werden alle Gleitkommaoperationen in double ausgeführt,
>> also auch wenn du float*float rechnest.
>
> Nixda. Das war zwar zu Grossvaters Zeiten (anno K&R) mal so definiert,
> gilt aber schon seit ANSI C nicht mehr.

ANSI C hat aber bei float_variable*float_konstante noch in double 
gerechnet... Und sowas gibt es bestimmt auch heute noch. ;)

Volker

[Egal Anders (Gast)]

> Und sowas gibt es bestimmt auch heute noch.

Vorstellbar wäre z.B.

a = log(2.0 * b)
statt
a = log(2,0f * b)

und schon weiß der Optimizer nicht mehr, dass eine Float-Konstante 
ausreichen würde.

[(prx) A. K. (prx)]

Volker Schulz schrieb:

> ANSI C hat aber bei float_variable*float_konstante noch in double
> gerechnet... Und sowas gibt es bestimmt auch heute noch. ;)

Aber nur dann, wenn du bei der float_konstante das "F" vergessen hast 
und es deshalb eine double_konstante ist. Oder wenn der Compiler das 
neue mögliche Verhalten nur optional freischaltet.

[(prx) A. K. (prx)]

Egal Anders schrieb:

> und schon weiß der Optimizer nicht mehr, dass eine Float-Konstante
> ausreichen würde.

Wie denn auch? log() ist kein Operator, sondern eine Funktion mit 
definiertem Parametertyp, auch wenns nicht selten auf irgendein 
__builtin_log() oder so rausläuft. In C++ mit operator overloading sähe 
das im Prinzip wieder anders aus.

[Egal Anders (Gast)]

> sondern eine Funktion mit definiertem Parameter

Theoretisch ja,

aber zumindest die GCC Entwickler sehen das recht pragmatisch. Gibt 
einige üble Makros in der bits/mathcalls.h und 2 Funktionen in der 
Library.

[LuXXuS 9. (aichn)]

Mein double ist in IAR auf 64Bit eingestellt. Ob Sinus / Kosinus doppelt 
drin ist....? Keine Ahnung, hab einfach die math.h eingebunden. Müsste 
ich also auch noch verschiedene Funktionen benutzen?

[(prx) A. K. (prx)]

Egal Anders schrieb:

> aber zumindest die GCC Entwickler sehen das recht pragmatisch. Gibt
> einige üble Makros in der bits/mathcalls.h und 2 Funktionen in der
> Library.

Yep, aber zwei verschiedene. log() für double und logf() für float. In C 
geht das nicht anders. Wobei vor ANSI C ein logf() unsinnig gewesen 
wäre, weil per Sprachdefinition Parameter (vmtl. auch Returnwert) 
zwingend double waren, nicht float sein konnten.