mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wieviele Flops?


Autor: Olivier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieviele flops schafft den ein ATmega? Wieviele ein 16-bit dsPIC? Anzahl 
benötigter Zyklen pro Flop? danke!

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir sicher die Datenblätter auf http://www.atmel.com/ und 
http://www.microchip.com helfen bei der Beantwortung.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir sicher, dass man dort zu FLOPS 
(http://de.wikipedia.org/wiki/FLOPS) nichts finden wird.

Das ist Sache des Compilers, und dazu finden sich allenfalls mal 
irgendwelche Benchmarks. Bei solchen Prozessoren darf man aber wohl 
selbst Hand anlegen, denn die werden nicht oft über FLOPS beworben.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal in diese Datei. Da sind auch float mul/div Vergleiche drin.

http://www.mikrocontroller.net/attachment/46272/benchmark.c

Der ATmega ist bei Gleitkomma so schwach das ein Vergleich zum Lächeln 
anregt.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei den Atmels kenne ich mich nicht aus, aber bei den 16bit-PICs (bis 
40MIPS) fand ich das hier: 
http://ww1.microchip.com/downloads/en/DeviceDoc/51459b.pdf
Edit: @Herny, ist ja hoch interessant :-) vielen dank für den link!

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FLOPS anzugeben macht nur sinn bei Architekturen die auch eine FPU 
haben. Alle anderen machen das über Libs und das ist vergleichsweise 
lächerlich langsam.
Darum gibts bei µCs auch meist den Wert MIPS, wobei der alleine 
natürlich noch nichts über die Geschwindigkeit bei Rechenoperationen 
aussagt.

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Henry

Irgendwie mag ich nicht so recht glauben, dass das alles ist, was der 
ATmega kann. Allein schon der erste Test ergibt sehr fragwürdige Zeiten. 
Eigentlich sollten fürs Füllen von 256 Bytes ca 96µS verbraucht werden, 
denn das Speichern dauert 2 Takte, der Vergleich auch 2 Takte und der 
bedingte Sprung ebenfalls, macht alles zusammen 256*3*2 = 1536 Takte = 
96µS @ 16MHz + Overhead um die Register mit Werten vorzuladen. Und bei 
den restlichens Benchmarks tauchen änliche Widersprüche auf...

MfG Mark

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark P. wrote:

> Eigentlich sollten fürs Füllen von 256 Bytes ca 96µS verbraucht werden,
> denn das Speichern dauert 2 Takte, der Vergleich auch 2 Takte und der
> bedingte Sprung ebenfalls

Wenn er das im Pointer-Register lässt. Nur hat der AVR im GCC 
Maschinenmodell möglicherweise kein dafür permanent verfügbares 
Pointerregister, also könnte viel redundantes Geschubse drin stecken. 
Könnte auch vom Optimierungslevel abhängen. Solche Schleifen profitieren 
teilweise von unrolling. Erzeugten Code ansehen.

Aber wie ich oben schon schrieb: Das ist Sache der Implementierung im 
Compiler und dessen Laufzeitbibliothek. Andere Compiler können grad an 
solchen Stellen drastisch bessere oder schlechtere Werte liefern.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Mark P.

Ja die ATmega Werte waren wirklich falsch aber nicht von mir.
ATmega habe ich nochmals ermittelt, im Simulator bei 20MHz.

Beitrag "Re: LPC2103 63MIPS?"

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

Bewertung
0 lesenswert
nicht lesenswert
Henry wrote:
> @ Mark P.
>
> Ja die ATmega Werte waren wirklich falsch aber nicht von mir.
> ATmega habe ich nochmals ermittelt, im Simulator bei 20MHz.


> Messungen ohne Codeoptimierung.

Ich schwanke noch, ob ich das als unfair bezeichnen würde oder nicht :-)

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Worauf bezieht sich dein 'unfair'?

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

Bewertung
0 lesenswert
nicht lesenswert
Unfair gegenüber dem Compiler, unfair gegenüber dem µC

Hier werden absolute Zeiten gemessen. Da sollte IMHO der Compiler auch 
zeigen dürfen was er kann.

Aber lass uns jetzt bitte nicht in einen Glaubenskrieg zum Thema "Sinn 
und Unsinn von Benchmarks" oder noch schlimmer "meiner ist schneller als 
deiner" eintreten.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da sollte IMHO der Compiler auch zeigen dürfen was er kann.

Das hätte ich mir auch gewünscht aber bei diesem simplen Benchmark 
funktioniert das nicht.

Zum messen der Zeit jedes Codeabschnitts müssen Breakpoints gesetzt 
werden. Der GNUCC verwürfelt aber schon in der kleinsten 
Optimierungsstufe –O1 den Code dermaßen, dass die Zuordnung zwischen 
C-Quellcode und Assembler verloren geht. Dadurch ist Debugging und 
Breakpoint nicht mehr möglich. Das könnte man sicher irgendwie hinbiegen 
aber wer hat dazu schon Lust.

Da alle Tests ohne Codeoptimierung gemacht wurden hat man auch so einen 
Richtwert der Controller-Leistung.

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.