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
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
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! :-)
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.
>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
> 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.
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.
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.
> 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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.