Gast
#1189098
Wieviele flops schafft den ein ATmega? Wieviele ein 16-bit dsPIC? Anzahl benötigter Zyklen pro Flop? danke!
Gast
#1189142
Ich bin mir sicher die Datenblätter auf http://www.atmel.com/ und http://www.microchip.com helfen bei der Beantwortung.
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.
Gast
#1189195
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.
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!
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.
@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
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.
Gast
#1189740
@ 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?"
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 :-)
Gast
#1189756
Worauf bezieht sich dein 'unfair'?
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.
Gast
#1189938
> 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.