Forum: Compiler & IDEs cycles bei Rechnung mit float-Zahlen


von Kxx S. (kskolik)


Lesenswert?

Guten Morgen,

ich arbeite gerade an einem Projekt, bei dem ich (leider) mit float 
Zahlen rechnen muss.
Dieses Projekt woll auf einem µC Controller implementiert werden, den 
ich zur Zeit noch suche.
Aus diesem Grund muss ich im Vorhinein möglichst genau wissen, wie viel 
Rechenzeit benötigt wird.

Da ich den Controller ja noch nicht habe, kann ich es auch schlecht 
messen. Wenn ich den Simulator im AVR Studio verwende, kann ich ja den 
cycle counter verwenden. Wenn ich allerdings die Optimierung einschalte, 
kann ich nicht mehr durch das Programm laufen und die benötigten cycles 
ablesen.

Jetzt meine Frage:
Wie wirkt sich die Optimierung in etwa aus? Das hängt sicherlich stark 
von dem speziellen Fall ab, aber vielleicht ist ja eine tendenzielle 
Aussage treffbar.

Eine andere Hilfe wäre auch, wenn mir jemand sagen könnte, wie viele 
cycles die einzelnen Rechenoperationen mit float beanspruchen (Addition, 
Substraktion, Multiplikation und Division. Modulo wäre auch noch von 
Nöten).
Kann man das bei float allgemein (so wie bei int) sagen, oder hängen die 
cycles auch von der Größe der Variablen etc ab?

MfG,
Kai

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Die zyklen hängen von den Variablen ab. Der AVR muß nämlich nach der 
berechnung ggf. noch wieder anpassungen druchführen damits wieder in 
IEEE Format passt.
Das beste ist, du überlegst dir wieviel Zeit du hast, machst ein 
Programm was nur die Rechenoperation durchführt und mißt die Zeit/Cycles

von Kxx S. (kskolik)


Lesenswert?

Ja, das habe ich bereits gemacht.
Also Variablen definiert mit den ungefähren späteren Werten und dann die 
Rechnungen selbst in einer while Schleife mehrere Male laufen lassen und 
dann den Mittelwert der Zyklen genommen.

Und wie ist das mit den Optimierungen? Kann ich da viel rausholen, oder 
ist das (tendenziell) eher wenig (bei algebraischen Rechnungen)

Danke trotzdem! :-)

von Εrnst B. (ernst)


Lesenswert?

Die Float-Berechnungs-Routinen werden aus einer Library 
dazugelinkt/kopiert, und nicht jedes mal neu kompiliert.
Die Optimierung hat also wenig Einfluss auf die 
Berechnungsgeschwindigkeit.

von Oliver (Gast)


Lesenswert?

>Und wie ist das mit den Optimierungen? Kann ich da viel rausholen, oder
>ist das (tendenziell) eher wenig (bei algebraischen Rechnungen)

Da die eigentlichen Berechungen ja in der float-lib passieren, und deren 
Laufzeit unabhängig von der Optimierungsstufe deines Programms ist (die 
wird ja nicht neu übersetzt), dürfte sich da nicht viel ändern.

Oliver

von Kxx S. (kskolik)


Lesenswert?

Alles klar, vielen Dank für die schnelle Hilfe.

-Kai

von Norgan (Gast)


Lesenswert?

> ich arbeite gerade an einem Projekt, bei dem ich (leider) mit float
> Zahlen rechnen muss.

Musst du nicht. Ne, wirklich jetzt, musst du nicht. Ok, es gibt 
Ausnahmen, aber die sind sehr selten. Fast alles in einem µC geht ohne 
Floating-Point Zahlen. Erzähl doch mal, warum du musst.

Das typische Anwendungsszenario für einen µC sieht etwa wie folgt aus: 
Irgendwie (Port, AD/Wandler, Timer) kommen Integer-Werte rein, irgendwie 
(Port, D/A-Wandler, PWM) müssen Integer-Werte raus. Keine der 
beteiligten µC-Komponenten kann dabei was mit Floating-Point Zahlen 
anfangen.

Zum Rechnen mit den Integer-Zahlen reicht ein bisschen Skalieren hier, 
ein bisschen Skalieren da, ein paar Kettenbrüche und andere 
Approximationen zur Garnitur, gewürzt mit etwas Kreativität.

Sogar bei der Darstellung einer Zahl mit Nachkommastellen auf dem 
Display kann man normalerweise die Umwandlung (Skalierung) eines 
Integer-Wertes in den darzustellenden Wert bis zum letzten Moment 
aufschieben.

> Aus diesem Grund muss ich im Vorhinein möglichst genau wissen, wie viel
> Rechenzeit benötigt wird.

Gerade wenn du dir sorgen um die Rechenzeit machst, und wenn du einen µC 
ohne FPU nimmst, wäre es eine gute Idee sich nicht von vorneherein auf 
Floating-Point Rechnen festzulegen.

von Karl H. (kbuchegg)


Lesenswert?

Norgan wrote:

> Zum Rechnen mit den Integer-Zahlen reicht ein bisschen Skalieren hier,
> ein bisschen Skalieren da, ein paar Kettenbrüche und andere
> Approximationen zur Garnitur, gewürzt mit etwas Kreativität.

Nicht zu vergessen den Fall, bei dem eine komplexe Berechnung
komplett durch eine Look-Up Tabelle ersetzt wird.

von Kxx S. (kskolik)


Lesenswert?

Stimmt schon.
Im Prinzip lässt sich jede Rechnung auf int zurückführen. Problematisch 
in meinem Fall ist allerdings, dass ich teilweise Zahlen multiplizieren 
muss, die sich um einige (9-10) Zehnerpotenzen unterscheiden.

Sind halt ein paar echt eklige Rechnungen bei.

von Norgan (Gast)


Lesenswert?

> Problematisch
> in meinem Fall ist allerdings, dass ich teilweise Zahlen multiplizieren
> muss, die sich um einige (9-10) Zehnerpotenzen unterscheiden.

Was sofort die Frage aufwirft, wie kommen diese radikal 
unterschiedlichen Zahlen in den µC?. Das übliche grösste Verhältnis dass 
man so findet sind vier bis fünf Zehnerpotenzen (1 : 2^16), wenn man 
z.B. einen kleinen Wert mit einem großen 16-Bit Timer-Wert 
multiplizieren möchte.

Wenn man nicht absichtlich grob unterschiedliche Zahlern reinsteckt, 
dann hat man die nicht. Und wenn man sie hat, sollte man mal über eine 
Skalierung nachdenken. Braucht man wirklich > 32 Bit Auflösung ( 
log2(10^10) ), wenn man z.B. zum Schluss doch nur einen 8-Bit 
D/A-Wandler bedient?

Je nach Rechnung kann man alternativ überlegen, den ganzen Multiplikator 
oder Multiplikant als separaten Skalierungsfaktor durch die ganze 
Rechnung zu schleppt.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Kai Skolik wrote:
> Stimmt schon.
> Im Prinzip lässt sich jede Rechnung auf int zurückführen. Problematisch
> in meinem Fall ist allerdings, dass ich teilweise Zahlen multiplizieren
> muss, die sich um einige (9-10) Zehnerpotenzen unterscheiden.

Problematisch ist Multiplikation da nicht, was eklig wäre sind an der 
Stelle Plus und Minus.

Was zu überlegen ist
-- welche Auflösung wird gebraucht (je nach Bereich bringt Fixpunkt 
bessere Auflösung als Floats)
-- wie sind die Bereichsgrenzen der Werte? In Deinem Beispiel sind 
offenbar (mindestens) zwei Bereiche sinnvoll, falls es in Fixpunkt 
gemacht werden soll.

Zu den Optimierungen: debig-informationen werden mit -g... auch zusammen 
mit -O... erzeugt (zumindest macht GCC das so).

Speziell wirde -O1 konzipiert, um bei optimiertem Code halbwegs 
vernünftig debuggen zu können. Möglicherweise fliegt bei Deinem Code zu 
viel redundantes Zeug raus, und dann gibt's natürlich auch keine 
Debug-Info mehr (zB für wegoptimierte lokale Vaiablen).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.