www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Floating-Point Leistung mit Emulation


Autor: Michael Stather (kyromaster)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie hoch ist denn (geschätzt) die Floating-Point Leistung eines AVR in 
Relation zur Ganzzahlleistung, zum Beispiel bei Addition und 
Multiplikation?
So wie ich das verstehe muss das Ganze ja in Software emuliert werden.
Gibt es eigentlich Gründe dass in vielen Embedded Prozessoren keine 
Floating-Point Unit drin ist? Also einfach "das viele Anwendungen so 
etwas nicht brauchen" rechtfertigt das ja IMHO nicht ganz.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Grund: Kosten!  Ein FP-Unit ist viel komplexer als eine AVR CPU und 
somit viel groesser auf dem Chip. Groesse des Chip -> Preis
Also viele brauchen es nicht, wollen also nicht dafuer bezahlen -> ist 
nicht drauf.

Weiss nicht welcher Jahrgang Du bist aber es gab mal einen Float 
Coprozessor von Intel, den 8087 und spaeter den 80287, die waren jeweils 
um ein vielfaches teurer als die 8086 / 80286.

In der Emulation gibt es aber maechtige Unterschiede. Z.B. gibt es 
einfach Befehlssaetze (nicht AVR ;-) die Floatingpoint in Software recht 
gut unterstuetzen.  Ausserdem sind Floatingpointdaten VIEL breiter als 
8-bit, somit ist es fuer 16- oder 32-bit Prozessoren einfacher die 
Software Emulation zu berechnen.

Gibt ne Menge Optionen, ein paar Millisekunden warten mit dem AVR ist 
wohl die einfachste.

Gruss, Robert

Autor: Postman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Weiss nicht welcher Jahrgang Du bist aber es gab mal einen
>Float Coprozessor von Intel, den 8087 und spaeter den 80287

Ach ja, die gute alte Zeit. Im Windows-Compiler konnte man damals 
einstellen, ob der Code mit dynamischer, statischer und gar keiner 
FP-Unterstützung erzeugt werden soll. Beim dynamischen, würde zur 
Laufzeit nachgeguckt, ob eine FP-CPU anwesend war. Ich weis bis heute 
nicht, wie das ging. Dann kamen aber die DX-Prozessoren und das Problem 
war gelöst :-)

Autor: Fritz G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert
Weiss nicht welcher Jahrgang Du bist, aber es gab mal einen Float
Coprozessor von AMD (AM9511), der sehr teuer war und mit seinen 2-4 MHz 
Ende der 70er berauschend schnell war. Ein paar Jahre später wurde die 
gleiche Geschwindigkeit mit dem Fast Floating Point Package von Motorola 
auf dem 68000 mit 8 MHz erreicht ....

> ... ein paar Millisekunden warten mit dem AVR ist wohl die einfachste.
Das muß nicht sein !

@Michael
Solange man mit 8bit-char oder 16bit-int Variablen auskommt, sind 
Ganzzahloperationen deutlich schneller, insbesondere die Multiplikation, 
da sie 8bit-weise von der CPU unterstützt wird. Die Division wird schon 
deutlich langsamer.
Ein Vergleich der Rechenzeiten ist erst bei 32bit-long in Bezug auf 
32bit-float sinnvoll. Für float auf einem 16 MHz AVR habe ich Zeiten von 
20-30µs im Kopf. Im Vergleich MUL32 zu FMUL32 ist MUL32 etwa 3 mal 
schneller, da hier wiederum die CPU ihre speziellen MUL-Befehle 
einsetzen kann. Bei DIV32 zu FDIV32 gibt es keine großen Unterschiede, 
da die Hauptarbeit durch Bitschiebereien erledigt werden muß: 32 Bit bei 
long und 24 Bit bei float (Mantisse).

Float hat den großen Vorteil, immer hohe Auflösung bei akzeptabler 
Geschwindigkeit zu bieten. Braucht man z.B. 1000 Operationen/Sekunde 
wird die CPU mit (nur) <5% belastet. Geschickt ist es, Divisionen durch 
Multiplikationen mit dem Kehrwert auszuführen (z.B. Skalierung von 
AD-Werten).

Die benötigte Codegröße für die Grundrechenarten und 
Vergleichsoperationen liegt bei guten Compilern unter 1K, um den 
Kritikern gleich den Wind aus den Segeln zu nehmen :-)

Vor längerer Zeit hat hier jemand etwas zu Rechenzeiten von FMUL/FDIV 
auf einem ARM7 berichtet: 1-2 µs. Sehr beachtlich.

Autor: Michael Stather (kyromaster)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die ausführliche Info :)
3 mal langsamer ist ja gar nicht so viel, ich hatte so mit 20mal 
langsamer oder so gerechnet.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Stather wrote:

> Also einfach "das viele Anwendungen so
> etwas nicht brauchen" rechtfertigt das ja IMHO nicht ganz.

Mö, viele MC-Anwendungen benutzen ja float.
Bloß sie brauchen es nicht sauschnell.


Peter

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael,
was willst du denn mit floating point ? So toll ist das gar nicht. Ein 
single precision float hat 32 bit, wovon 23 bit mantisse ist, was einen 
dynamischen Bereich von 8e6 betraegt. Den krieg ich auch mit 24bit 
integer. Der normale longint hat einen dynamischen Bereich von 4e9. Dazu 
muss man dann schon auf double gehen bei float. Und double auf einem 
AVR, falls ueberhaupt unterstuetzt, ist nochmals ein Stueck langsamer. 
Dazu ist anzumerken, dass auch mit Integern als fractional gearbeitet 
werden kann. Behalte den exponenten in Kopf, resp auf dem Papier.
Floating point haelt die Entwickler vom Denken ab. Sobald man sin, cos, 
exp moechte wird float extrem zeitaufwaendig. Da kann man oft was mit 
Polynom approximationen, Tabellen, Splines und dergl. arbeiten.

rene

Autor: Michael Stather (kyromaster)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin wirklich kein Profi was AVR angeht, bins halt von C++ aufm PC 
gewohnt einfach den float-Datentyp zu nehmen. Und für die Sachen die ich 
bis jetzt mit AVR gemacht habe hat die Rechenlsitung immer gereicht.
Meinst du mit "integer" dass man die Berechnung quasi mit integer-werten 
umsetzt (also ohne Compiler-Unterstützung)?

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm fixed point... ((int)(1.2*256)*x)>>8 = 1.2*x

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wobei x natürlich auch ein fixed point wert sein muss

Autor: Johnny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> nimm fixed point... ((int)(1.2*256)*x)>>8 = 1.2*x

Genau, das mach ich auch immer so falls möglich / sinnvoll.

Das heisst also konkret: (307 * x) >> 8
Dabei kann das >> 8 wahrscheinlich vom Compiler/CPU in einem Zyklus 
durch einen Kopierbefehl gemacht werden.

Es ist nur zu beachten, dass x * 307 keinen Überlauf verursacht, wenn 
das Ergebnis zu gross wird. Also ist auszurechnen, wie gross x für 
diesen Fall maximal sein darf und eventuell abfangen.

Sonst gehts auch kleiner, aber auch ungenauer:
z.B. (19 * x) >> 4 Das würde dann x * 1.1875 entsprechen.

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man rechnet am besten mit 64 bit. die ARMs können das sehr gut, ein AVR 
wohl eher weniger.

Wenn du nur 8.8 zahlen hast kannst du auch wunderbar mit 32 bit rechnen 
(also hast du dann 24.8) dann hast du weniger probleme mit dem überlauf. 
Oder halt 16.16 dann hast du zwar mehr präzision aber kannst im grunde 
nur 8.16 mit 8.16 im vollen integerbereich miteinander multiplizieren

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rene,

Irren ist menschlich, aber die Ansammlung Deiner Irrtümer muß ich leider 
als totalen Müll bezeichnen.

Nur soweit: Bereiche werden durch Unter- und Obergrenzen beschrieben. 
Bei 'float' ist dieser +/- 1.18e-38 bis +/- 3.39e+38.

Viel Spatz beim Approximieren, Tabellieren und Splinieren.

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.