Wieviele Flops?

[Olivier (Gast)]

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

[Gast (Gast)]

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

[(prx) A. K. (prx)]

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.

[Henry (Gast)]

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.

[Master S. (snowman)]

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!

[Timmo H. (masterfx)]

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.

[Mark .. (mork)]

@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

[(prx) A. K. (prx)]

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.

[Henry (Gast)]

@ 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?"

[Karl H. (kbuchegg)]

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 :-)

[Henry (Gast)]

Worauf bezieht sich dein 'unfair'?

[Karl H. (kbuchegg)]

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.

[Henry (Gast)]

> 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.