www.mikrocontroller.net

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


Autor: Kxx S. (kskolik)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Kxx S. (kskolik)
Datum:

Bewertung
0 lesenswert
nicht 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! :-)

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Kxx S. (kskolik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar, vielen Dank für die schnelle Hilfe.

-Kai

Autor: Norgan (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Kxx S. (kskolik)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Norgan (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.