Hallo, klar heißt s wieder vom fall abhängig..aber wenn man einfach sachen macht, also nicht Schwerpunktmässig die stärken der CPU (Xmega schnelles Portschalten, ARM Flieskomma) Wie ist dann der Takt vergleichbar.. Liege ich richtig, das ein 32MHZ XMEGA bei den meisten Sachen extwas schneller als ein 70 oder 80MHz Arm ist? Ab 120MHZ der Arm schneller ist? Ab wieviel MHz bekommt das z.B. ein ARM hin? https://www.youtube.com/watch?v=CXFOTpM2Jn4 oder sowas https://www.youtube.com/watch?v=yK2MMMTw3SY leider finde ich nirgend z.B. ein Vergleichsdemo Man findet auch nur schwer vergleichbares..dashier ist unfair, weil der controller vermutlich genug damit zu tun hat den VGA Anschluss zu bedienen https://www.youtube.com/watch?v=RY92VcNa1fI
:
Bearbeitet durch User
Max Schauzer schrieb: > Liege ich richtig, das ein 32MHZ XMEGA bei den meisten Sachen extwas > schneller als ein 70 oder 80MHz Arm ist? > Ab 120MHZ der Arm schneller ist? Da Xmega eine 8 bit RISC-CPU und ARM eine 32 bit RISC-CPU ist das sehr unwahrscheinlich. MfG,
Fpga Kuechle schrieb: > Da Xmega eine 8 bit RISC-CPU und ARM eine 32 bit RISC-CPU ist das sehr > unwahrscheinlich. wenn für die Aufgabe 8bit reichen, spielt das keine rolle.
immerhin benötigt der ARm oft bis zu vier Taktzyklen mehr als der Xmega für einen Befehl..daher finde ich das nicht so klar
Peter II schrieb: > Fpga Kuechle schrieb: >> Da Xmega eine 8 bit RISC-CPU und ARM eine 32 bit RISC-CPU ist das sehr >> unwahrscheinlich. > > wenn für die Aufgabe 8bit reichen, spielt das keine rolle. wenn du meinst das 32MHz Taktung eine mehr als doppelt so hohe Taktung einer Machine mit vierfacher datenbusbreite kompensiert dann ist das natürlich nicht von Belang ...
Max Schauzer schrieb: > immerhin benötigt der ARm oft bis zu vier Taktzyklen mehr als der Xmega > für einen Befehl..daher finde ich das nicht so klar Tatsächlich? sind nicht beide CPU's RISC-maschinen mit single cycle Instructions? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337h/CHDDIGAC.html
Max Schauzer schrieb: > klar heißt s wieder vom fall abhängig..aber wenn man einfach sachen > macht, also nicht Schwerpunktmässig die stärken der CPU (Xmega schnelles > Portschalten, ARM Flieskomma) Anders ausgedrückt: Bei dem, was der AVR besser kann als der ARM, ist er besser. Bei dem, was er schlechter kann, ist er schlechter. Jetzt muss man nur noch wissen, aus welchen dieser beiden Alternativen das zu betrachtende Problem überwiegend besteht. ;-) Aber im Ernst: Es gibt neben Fliesskommarechnung auch weniger offensichtliche Punkte, wo ein 8-Bitter wie AVR mit oder ohne X schwächelt. Schon die Verarbeitung von nicht-statischen Adressen aller Art macht ihm deutlich Arbeit. Ob Umgang mit Pointern (zu wenig Adressregister) oder Array-Indizierung (16-Bit Rechnung mit Shift oder Multiplikation). Es gilt also das, was für Benchmarks generell gilt: Ein Vergleich zweier Systeme liefert nur eine Aussage für die dabei eingesetzte Software. Während bei PCs mittlerweile durch entsprechend grosse Benchmark-Suites immerhin ziemlich viel Software integriert ist (dutzende z.T. sehr grosse Programme) und sich das etwas ausmittelt, hat sich verständlicherweise niemand die Mühe gemacht, entsprechend umfangreiche Benchmark-Suites für Mikrocontroller zu entwickeln. Bleibt also eigentlich nur der im Controller-Sektor recht verbreitete Prozessor-Benchmark Dhrystone. da sollte sich auch was googeln lassen. Dir muss nur klar sein, dass damit eben nur die Performance des Dhrystones gemessen wird und die Performance deiner Anwendungen eine Grössenordnung neben dieser Peilung liegen kann.
Fpga Kuechle schrieb: > Tatsächlich? sind nicht beide CPU's RISC-maschinen mit single cycle > Instructions? Yep. Beide haben beispielsweise Shiftoperationen, die jeweils nur einen Takt brauchen. Fairer Vergleich, oder? ;-)
:
Bearbeitet durch User
so, hab es eben einfach mal getestet :-) Oha...das überrascht mich jetzt doch..habe einfach mal auf einem XMEGA128 und einem STM32F207
1 | TFT_Set_Pen(CL_black, 2); |
2 | TFT_Set_Brush(1, CL_BLUE, 1, LEFT_TO_RIGHT, CL_BLUE, CL_BLUE); |
3 | For n:=1 TO 320 Do TFT_Rectangle(0, 0, n, 20); |
4 | TFT_Set_Brush(1, CL_yellow, 1, LEFT_TO_RIGHT, CL_BLUE, CL_yellow); |
5 | For n:=1 TO 320 Do TFT_Rectangle(0, 0, n, 20); |
laufen lassen... ich muss glatt nochmal prüfen ob nich irgenwo eine Takteinstellung falsch ist..aber hier kackt der ARm gerade deutlich!! ab..mit 120MHz..das hätte ich niemals so krass erwartet. Habe hier von microe die beiden Micromedia Boards :-) Der Grund ist weil ich natrülich auch überelge zu Arm zu wchseln wie so viele..daher beschäftigt mich das gerade, was in der Hobbykiste landet...ob ich einen Xmea für3€ kaufe oder eine vergleichbaren M3 mit 120 oder mehr für 7-12€ ist ein heftiger Unterschied wenn man sich ein kleines Lager anlegen will
:
Bearbeitet durch User
Max Schauzer schrieb: > so, hab es eben einfach mal getestet :-) > Oha...das überrascht mich jetzt doch..habe einfach mal auf einem > XMEGA128 und einem STM32F207 >
1 | TFT_Set_Pen(CL_black, 2); |
2 | > TFT_Set_Brush(1, CL_BLUE, 1, LEFT_TO_RIGHT, CL_BLUE, CL_BLUE); |
3 | > For n:=1 TO 320 Do TFT_Rectangle(0, 0, n, 20); |
4 | > TFT_Set_Brush(1, CL_yellow, 1, LEFT_TO_RIGHT, CL_BLUE, CL_yellow); |
5 | > For n:=1 TO 320 Do TFT_Rectangle(0, 0, n, 20); |
> > laufen lassen... > ich muss glatt nochmal prüfen ob nich irgenwo eine Takteinstellung > falsch ist..aber hier kackt der ARm gerade deutlich!! ab..mit > 120MHz..das hätte ich niemals so krass erwartet. > Habe hier von microe die beiden Micromedia Boards :-) Ja, schlechte Software lässt jede CPU abkacken. Aber laut thread-titel willst du doch prozessoren vergleichen und nicht Software? Und wie es scheint testest du hier das Graphic-subsystem und nicht die CPU. Auch hier gilt eine miese Graka lässt jede CPU alt aussehen. MfG,
fehlalarm, bevor ihr euch gleich wieder zerfleischt..muss gerade neu booten..hatte die PLL noch falsch eingestellt :-)
naja,, ziemlich blödsinnig..ich habe für beide den gleichen Compiler von Microe..als absolut fair
Fpga Kuechle schrieb: > Ja, schlechte Software lässt jede CPU abkacken. Aber laut thread-titel > willst du doch prozessoren vergleichen und nicht Software? wie willst du ohne Software eine CPU vergleichen? Wiegen?
Peter II schrieb: > Fpga Kuechle schrieb: >> Ja, schlechte Software lässt jede CPU abkacken. Aber laut thread-titel >> willst du doch prozessoren vergleichen und nicht Software? > > wie willst du ohne Software eine CPU vergleichen? Wiegen? Technische Daten aus dem datenblatt.
eben und ich will nicht für jeden Controller den code erst optimieren müssen..sondenr vergleiche so wie man üblich programmiert wenn man schnell mal ein Projekt machen will...und daher habe ich ja ebe n diese beiden Zeilen unverändert auf beiden Controllern laufen lassen..dauert noch einen moment. erkennt gerade den Controller nicht am USB..blöde VMWare
haha, Dui minst also Theoretische werte :-) Mich interessieren aber eher wie gesagt die praktischen ;-) machen kann man viel aber was ist bei allgemeiner Programmierung.. Hmpf..nun noch 131 Windowx XP updates :-(
:
Bearbeitet durch User
Peter II schrieb: > wie willst du ohne Software eine CPU vergleichen? Wiegen? Och, da gibts noch mehr Varianten die mehr Sinn ergeben als das Gewicht. Gehäusetyp und Pindichte, Stromverbrauch und -Versorgungsoptionen, In-Circuit-Programmierung und -Debugging, Entwicklungssystem, ...
Fpga Kuechle schrieb: > Technische Daten aus dem Datenblatt. geht nicht sinnvoll, sonst würde Intel & Co nicht ihre vergleiche anhand von Benchmarks machen.
Peter II schrieb: > geht nicht sinnvoll, sonst würde Intel & Co nicht ihre vergleiche anhand > von Benchmarks machen. Fairerweise muss man sagen, dass man bei AvrX und Cortex M3 durch Abzählen von Takten von Befehlen eines Programms der Realität wesentlich näher kommt als bei Intel & Co. Bei den x86 von heute ist das ein völlig hoffnungsloses Unterfangen.
:
Bearbeitet durch User
Max Schauzer schrieb: > haha, Dui minst also Theoretische werte :-) > Mich interessieren aber eher wie gesagt die praktischen ;-) machen kann Ja in Praxis kann man auch die schnellste CPU so suboptimal programmieren das 99% des Leistungspotentials verschwendet sind. Um zu wissen was in Praxis optimal möglich muß man schon ins Datenblatt schauen. MfG,
Sind die Displays identisch? Sind sie identisch angeschlossen? Werden die Displayschnittstellen mit dem gleichen Takt betrieben? Sind die Bibliotheken identisch? Mit Deinem Test testest Du höchstens die Displays und die Bibliotheken, aber nicht den Prozessorkern. Und die Codequalität des Mikroe-Zeugs ist natürlich auch ungewiss. Nimm mal gcc, da weiß man wenigstens, dass da Profis am Werk waren. fchk
Fpga Kuechle schrieb: > das 99% des Leistungspotentials verschwendet sind. Um zu wissen was in > Praxis optimal möglich muß man schon ins Datenblatt schauen. Seit wann steht die realistische Performance direkt im Datasheet? Es ist eine Wissenschaft für sich, aus Doku zu ISA und Implementierung die Performance ganz grob einpeilen zu können.
Peter II schrieb: > Fpga Kuechle schrieb: >> Technische Daten aus dem Datenblatt. > > geht nicht sinnvoll, sonst würde Intel & Co nicht ihre vergleiche anhand > von Benchmarks machen. Doch man kann sehr wohl aus dem Datenblatt abschätzen wieviel Performance möglich ist und ob der Benchmark was taugt oder nicht. MfG,
"ind die Displays identisch? Sind sie identisch angeschlossen? Werden die Displayschnittstellen mit dem gleichen Takt betrieben? Sind die Bibliotheken identisch? Mit Deinem Test testest Du höchstens die Displays und die Bibliotheken, aber nicht den Prozessorkern." ja, alles gelich, selbst das Platinenlayout sieht gleich aus :-) Wie gesagt von Microe die micromedia board mit 320x240 Display, beide mit dem Pascal Compiler und beide die gleichen Zeilen code
gcc ist mir die Einrichtung zu blöd, mit microe bin ich soweit zufrieden..na was ivh immer so lese haben die "Profis" vom gcc auch genug Bugs drin :-)
Fpga Kuechle schrieb: > Doch man kann sehr wohl aus dem Datenblatt abschätzen wieviel > Performance möglich ist und ob der Benchmark was taugt oder nicht. Bei Intel&Co auch? ;-)
A. K. schrieb: > Fpga Kuechle schrieb: >> das 99% des Leistungspotentials verschwendet sind. Um zu wissen was in >> Praxis optimal möglich muß man schon ins Datenblatt schauen. > > Seit wann steht die realistische Performance direkt im Datasheet? Es ist > eine Wissenschaft für sich, aus Doku zu ISA und Implementierung die > Performance ganz grob einpeilen zu können. Datenbus-frequenz rauslesen, cycles pro transfers rauslesen, Datenbusbreite rauslesen -> Performance bestimmen Das hat man mit ein paar jahren Erfahrung schnell drauf. MfG,
A. K. schrieb: > Fpga Kuechle schrieb: >> Doch man kann sehr wohl aus dem Datenblatt abschätzen wieviel >> Performance möglich ist und ob der Benchmark was taugt oder nicht. > > Bei Intel&Co auch? ;-) Steht intel im Thread-Titel oder ARM? MfG,
Max Schauzer schrieb: > ja, alles gelich, selbst das Platinenlayout sieht gleich aus :-) Display mit eigenem Controller? Wenn der Anhänger nur 60kmh darf, dann sind Porsche und Trabbi gleich schnell. ;-)
Fpga Kuechle schrieb: > Steht intel im Thread-Titel oder ARM? In deinem Beitrag als Quote, d.h. du hattest auf "Intel" geantwortet.
Fpga Kuechle schrieb: > Das hat man mit ein paar jahren Erfahrung schnell drauf. Beim Blocktransfer ja. Bisschen schwieriger wird aber die Abschätzung, in wieviele Maschinenbefehle sich ein C Programm ungefähr übersetzt, und sei es nur in Relation zueinander. Bei Maschinen gleicher Klasse, also 32-Bitter gegeneinander klappt das schon wesentlich leichter als wenn völlig verschiedene 8- und 32-Bitter gegeneinander antreten.
Der Vergleich ist nicht so ganz einfach. Es dürften aber nur relativ wenige spezielle Aufgaben sein, wo der AVR mit weniger Taktzyklen auskommt als der ARM. Auch wenn keine Fließkommazahlen gebraucht werden, wird der ARM eher mit weniger Zyklen auskommen - wie viel hängt halt von der Aufgabe bzw. dem Programm ab. Bei den ARMs hat man keine lineare Skalierung mit dem Takt. Flash und IO Bus haben oft ein relativ niedriges Taktlimit. Mit 80 MHz ist der ARM entsprechend da nicht mehr 4 mal so schnell wie mit 20 MHz. Da unterscheiden sich wohl auch die Implementierungen. Code kann man ggf. auch schneller aus dem RAM ausführen - allerdings ist da ggf. der Platz knapp.
also irgendwie bleibt der nach wie vor lahmm...könnt ihr mal die Einstellungen überprüfen? http://www.directupload.net/file/d/3997/5bqls6vn_jpg.htm http://www.directupload.net/file/d/3997/asetjhsv_jpg.htm
Warum ist verwendest du den internen Oszillator (HSI) und nicht den Externen (HSE)? Gibt es überhaupt einen STM32 der mit dem Internen so hoch takten kann?
soweit ich weis sind alle takte mit dem internen möglich in zig Kombinationen..
Ja stimmt sehe gerade, dass der mit 16 MHz läuft. Dann muss es an der Einstellung liegen...
Damit kannst die Einstellung überprüfen (ist eine Excel Tabelle): http://www.st.com/web/en/catalog/tools/PF257926#
so..wie ich das sehe kackt der ARm voll ab :-( Also bleibe ich wohl doch beim Xmega.. Der Xmega ist ca. 40% schneller! Anbei nochmal die einstellungen falls jemand noch einen Fehler entdeckt.. ARM 120MHz gegen Xmega 32MHz!! http://www.directupload.net/file/d/3997/ozjnkjc3_jpg.htm http://www.directupload.net/file/d/3997/rikqsnuc_jpg.htm dann ist es also schon so wie ich es mir die ganze Zeit dachte..schade..can wäre schön gewesen..aber dafür so viel mehr kohle und mehr konfigurierei.neee
:
Bearbeitet durch User
Dass der XMega 40% schneller ist, kann nicht sein. Da ist definitiv was im Argen. Habe deine Einstellungen mal in STM32CubeMx übertragen und nach dessen Berechnung dürfte der ARM mit 20,48 MHz laufen (siehe Bild 1). Übernehme mal die Einstellung aus Bild 2.
ahh, super jetzt ist der ARM schneller, dennoch deutlich weniger als erwartet.. Habe den PLLP jetzt mal auf 6 gestellt, also 40MHz, dann ist der ARM tatsächlich etwas schneller als der Xmega mit 32MHz..Also scheinen noch gut direkt mit dem Takt vergleichbar zu sein
Max Schauzer schrieb: > Also scheinen noch > gut direkt mit dem Takt vergleichbar zu sein Mutige Verallgemeinerung.
:
Bearbeitet durch User
wieso? Das wir davon ausgehen das beides RISV ist haen wir ereits geklärt...
Max Schauzer schrieb: > wieso? Das wir davon ausgehen das beides RISV ist haen wir ereits > geklärt... Das sagt erst mal wenig aus. Denn da gibt es noch sowas wie Registerbreite, Busbreite, Taktfrequenz, Cache, Anzahl der Kerne, RAM-(Busbreite, Latenz, Größe), DMA, etc. . Lass die beiden erst mal mit größeren Zahlen rechnen, da wird der XMega kein Land sehen.
Max Schauzer schrieb: > wieso? Das wir davon ausgehen das beides RISV ist haen wir ereits > geklärt... Vergleich mal int shift(int x, int n) { return x >> n; } für variables n. Klar, beide RISCs haben einen Shift-Befehl, der nur einen Takt benötigt, aber... Schau dir mal an, was bei int a[10][10]; ... a[x][y] ... rauskommt und zähl die Takte mit. Oder Codelänge. Nur 2 Beispiele von vielen für stinknormalen Code. Wenn Programme grösser als ein paar KB sind und der Overhead vom Startup-Code nicht mehr dominiert, dann wirst du typischerweise auch feststellen, dass CM3 Code kürzer als AVR Code ist.
:
Bearbeitet durch User
Kleiner Spass am Rande: Vergleich mal den Code, der bei dieser völlig harmlosen und im Grafik-Umfeld auch nicht exotischen Funktion rauskommt:
1 | int shift(int a, int b, int n) |
2 | {
|
3 | return (n > 0) ? a | (b >> n) : a | (b << n); |
4 | }
|
wobei hier ein kleiner Abstecher zum klassischen ARM Befehlsatz durchaus lohnen kann, denn das ergibt: cmp r2, #0 orrgt r0, r0, r1, asr r2 orrle r0, r0, r1, asl r2 CM3 kommt da nicht ganz ran: cmp r2, #0 ite gt asrgt r1, r1, r2 lslle r1, r1, r2 orr r0, r0, r1 CM0 erst recht nicht: cmp r2, #0 ble .L2 asr r1, r1, r2 b .L4 .L2: lsl r1, r1, r2 .L4: orr r0, r1 von AVR ganz zu schweigen: cp _zero_reg_,r20 cpc _zero_reg_,r21 brge .L2 rjmp 2f 1: asr r23 ror r22 2: dec r20 brpl 1b rjmp .L4 .L2: rjmp 2f 1: lsl r22 rol r23 2: dec r20 brpl 1b .L4: or r22,r24 or r23,r25 PS: Ok, das ist etwas "tuned for ARM" ;-)
:
Bearbeitet durch User
TriHexagon schrieb: > Lass die beiden erst mal mit größeren Zahlen rechnen, da wird der XMega > kein Land sehen. Richtig. Nur ist der springende Punkt ja gerade, daß man in kleineren Steuerungsaufgaben fast nie mit großen Zahlen rechnen muß. Wenn nur maximal 10 Bits reinkommen und nur maximal 10Bits wieder rausgehen können, muß man bei allen üblichen Algorithmen halt maximal mit 20..24 Bits rechnen. In dem meisten Fällen genügen aber auch 16 oder noch weniger. Ja, es gibt leider sehr viele Leute, die sind nur dazu in der Lage, vorhanden Quelltext per C&P zu übernehmen. Nur dieses KRASS UNFÄHIGE PACK braucht dann oft zwingend 32Bit oder gar eine Double-fähige FPU noch dazu, und das nur, weil der raubkopierte Quelltext halt eigentlich für Desktop-PCs geschrieben wurde... Das ist aber nur bemitleidenswerter Programmiererabschaum. Nicht wirklich Programmierer. Irrelavant, außer für BWLer, die solche Abschaum natürlich gern einkaufen, weil er einfach mal billich ist.
c-hater schrieb: > Richtig. Nur ist der springende Punkt ja gerade, daß man in kleineren > Steuerungsaufgaben fast nie mit großen Zahlen rechnen muß. > > Wenn nur maximal 10 Bits reinkommen und nur maximal 10Bits wieder > rausgehen können, muß man bei allen üblichen Algorithmen halt maximal > mit 20..24 Bits rechnen. In dem meisten Fällen genügen aber auch 16 oder > noch weniger. Dir ist schon klar, dass eine acht Bit CPU mehr Takte/Klimzüge braucht, wenn Du zehn Bits oder mehr verarbeiten möchtest gegenüber einer 16-/32-Bit CPU... und gerade beim multiplizieren, sollte genug "Luft" an Bitbreite für das Ergebnis vorhanden sein, oder man muss vorher Prüfen, ob es keinen Überlauf gibt - zwei 16-Bit Zahlen zu multiplizieren mit einer 32-Bit CPU dürfte schneller von statten gehen, als bei einer 8-Bit CPU...
Max Schauzer schrieb: > so, hab es eben einfach mal getestet :-) > Oha...das überrascht mich jetzt doch..habe einfach mal auf einem > XMEGA128 und einem STM32F207 TFT_Set_Pen(CL_black, 2); > TFT_Set_Brush(1, CL_BLUE, 1, LEFT_TO_RIGHT, CL_BLUE, CL_BLUE); > For n:=1 TO 320 Do TFT_Rectangle(0, 0, n, 20); > TFT_Set_Brush(1, CL_yellow, 1, LEFT_TO_RIGHT, CL_BLUE, CL_yellow); > For n:=1 TO 320 Do TFT_Rectangle(0, 0, n, 20); Eigentlich ist dieses Programm auch absolut unbrauchbar für den Vergleich. Hier werden nur Daten verschoben und dafür brauch man keine CPU. Da benutzt man einen DMA, dann geht die Belastung auf die CPU gegen null. Und das auch nur weil DMA und CPU den gleichen Bus benutzen.
Ich hatte mal privat die Taktzyklen eines AVR gemessen, die für die Durchführung einer 64 Bit Ganzzahldivision benötigt werden. Dann hatte ich aus beruflichen Gründen den "Trace" einer 64Bit Ganzzahldivision auf einem ARM Cortex-A9 vorliegen. Das Ergebnis: Anzahl der Taktzyklen auf einem AVR * 4 = Anzahl der Assembler Befehle auf einem Cortex-A9. Das sagt leider nichts darüber aus, wie schnell der ARM jetzt ist, da die Taktzyklen dort nicht gezählt wurden. Der Faktor *4 würde natürlich passen, da erstere 8Bit und letztere in 32Bit rechnet, unter der (zu optimistischen) Annahme dass der AVR jeden Befehl in einem Takt ausführt. Wie schnell nun der ARM pro Takt im Verhältnis zum AVR ist, hängt auch wieder von der ARM Architektur ab. Der Cortex A8 hat zwei Ausführungseinheiten und kann somit im günstigsten Fall zwei Befehle gleichzeitig ausführen. Im wesentlichen kann man sich das so vorstellen, dass der zweite Befehl angefangen wird, bevor der erste fertig berechnet wurde. Das klappt (vereinfacht gesagt), solange der zweite Befehl keine Register verwendet, die auch im ersten Befehl verwendet werden. Die erreichbare Geschwindigkeit hängt somit davon ab, wie geschickt der Compiler dabei ist die einzelnen Befehle so zu verschachteln, dass möglichst viel anderer Code zwischen zwei Befehlen liegt, der das gleiche Register verwendet.
1 | ldr r0, =123456 |
2 | ldr r1, =234567 |
3 | add r2, r1, r0 |
4 | mov r4, #0 |
dürfte langsamer sein als
1 | ldr r0, =123456 |
2 | ldr r1, =234567 |
3 | mov r4, #0 |
4 | add r2, r1, r0 |
Beim Cortex A9 ist dies ebenfalls so, dafür kann der Out-of-Order ausführen, also die Reihnfolge der Befehle selbstständig ändern.
"Eigentlich ist dieses Programm auch absolut unbrauchbar für den Vergleich. Hier werden nur Daten verschoben und dafür brauch man keine CPU. Da benutzt man einen DMA, dann geht die Belastung auf die CPU gegen null. Und das auch nur weil DMA und CPU den gleichen Bus benutzen.§ mir völlig wurscht..das ist das was die meistn hier mit den Controllern machen, fenster Zecihnen, Button anlegen für touch etc...das ist daher für 90% ein brauchbarer Test. MPEg kodieren, mit Fliesskoma rechnen im großen Stiel, Spracherkennung udn Mondfahrzeuge bauen hier die wenigsten..daher interessieren mit die theoretichen Diskussionen hier..0
Max Schauzer schrieb: > ..daher interessieren mit die theoretichen Diskussionen hier..0 Wenn dich Antworten nicht interessieren, weshalb fragst du dann? Den wohl einzigen verbreiteten Benchmark im Embedded-Bereich hatte ich anfangs bereits genannt. Es ist auch nicht schwer, danach zu Suchen und Zahlen zu gewinnen. Das fand ich zumutbar.
:
Bearbeitet durch User
Der 8-Bitter kackt doch schon bei einfachen Arrayzugriffen gnadenlos ab: - lade 2 Register mit Base - lade 2 Register mit Offset - addiere 2 mal - lese 2 mal vom SRAM (für int16) Er braucht jedesmal die doppelte Anzahl an Befehlen.
Peter Dannegger schrieb: > Er braucht jedesmal die doppelte Anzahl an Befehlen. Eine ggf. skalierte Addition ist beim ARM Teil des Ladebefehls. ldr r0, [r0, r1, lsl #2] v. lsl r22 rol r23 add r22,r24 adc r23,r25 movw r30,r22 ld r24,Z ldd r25,Z+1 für
1 | int f(int a[], int i) |
2 | {
|
3 | return a[i]; |
4 | }
|
:
Bearbeitet durch User
Peter Dannegger schrieb: > Der 8-Bitter kackt doch schon bei einfachen Arrayzugriffen gnadenlos ab: nicht jedes Programm braucht das. ARM ist auch nicht gut bei Video-Codierung.
Peter II schrieb: > ARM ist auch nicht gut bei Video-Codierung. Würde ich so allgemein nicht unterschreiben. Kommt etwas drauf an welcher ARM. Die Bandbreite dessen, was unter dieser Flagge segelt, ist recht hoch. Aber klar, nix taugt für alles. Wenn AVR reicht, warum wechseln? Aber der Thread bezieht sich letztlich auf die Frage, was bei einer strategischen entweder-oder Entscheidung flexibler ist, AVR oder ARM. Und das ist mittlerweile ARM.
:
Bearbeitet durch User
Max Schauzer schrieb: > "Eigentlich ist dieses Programm auch absolut unbrauchbar für den > Vergleich. Hier werden nur Daten verschoben und dafür brauch man keine > CPU. Da benutzt man einen DMA, dann geht die Belastung auf die CPU gegen > null. Und das auch nur weil DMA und CPU den gleichen Bus benutzen.§ > > mir völlig wurscht..das ist das was die meistn hier mit den Controllern > machen, fenster Zecihnen, Button anlegen für touch etc...das ist daher > für 90% ein brauchbarer Test. > MPEg kodieren, mit Fliesskoma rechnen im großen Stiel, Spracherkennung > udn Mondfahrzeuge bauen hier die wenigsten..daher interessieren mit die > theoretichen Diskussionen hier..0 Füllst du dich jetzt etwa beleidigt? Mein Beitrag war in keiner Weise beleidigend oder böse gemeint. Weißt du überhaupt was ein DMA ist? Was daran jetzt theoretisch sein soll, verstehe ich auch nicht. Du verfeuerst hier unnötig Rechenleistung für simples Kopieren von Daten. Aber gut wenn du meinst, das macht jeder so und das soll so bleiben, wünsche ich dir noch viel Spaß. Kannst dich ja wieder melden, wenn du einen Benchmark STM32F207 vs Rasperry Pi machst ;) .
Peter II schrieb: > Peter Dannegger schrieb: >> Der 8-Bitter kackt doch schon bei einfachen Arrayzugriffen gnadenlos ab: > > nicht jedes Programm braucht das. Also bei mir kommt kein einziges Programm ohne Pointer aus, ob Strings, Buffer, Lookup-Tables, switch/case, command-parser usw. usw. Und oftmals sind sogar Pointer auf Pointer nötig, d.h. mehrfache Indirektion. Allerdings habe ich keinerlei Zeitprobleme, daher reicht der AVR mir aus und läuft oft mit Werkseinstellung 8MHz/8. Ist aber schön zu wissen, falls man dochmal eilige Anwendungen hat, daß der ARM sowas in einem Befehl kann, statt in 7 beim AVR.
A. K. schrieb: > Peter II schrieb: >> ARM ist auch nicht gut bei Video-Codierung. > > Würde ich so allgemein nicht unterschreiben. Kommt etwas drauf an > welcher ARM. Die Bandbreite dessen, was unter dieser Flagge segelt, > ist recht hoch. ARM Systeme sind sehr wohl für Video/Graphic geeignet, das hat schon der Ur-ARM im Archimedes Acorn bewiesen dessen Graphic-leistung Ende der Achtziger einen Commodore Amiga oder Mac CE alt ausehen ließ: http://en.wikipedia.org/wiki/Acorn_Archimedes https://www.youtube.com/watch?v=h6a8FMak-Pk (bspw. ab 2:00) Heute überzeugt die Videoausgabe auf Smartphones oder in HDMI Sticks - ARM von Cortex M0 32 MHz bis multicores im GHz bereich bei Cortex-A12?. Und ARM selber ist nur der Core, bezüglich der "Chip-ausgabe" über Peripherals wie GPIO's, HDMI etc. ist der Lizennehmer verantwortlich. Und da gibt recht ordentliche Exemplare wo jeder Vergleich mit einem 8 bit Waschmaschinencontroller lächerlich ist. Bspw Chromecast: https://tomkanok.wordpress.com/2013/07/25/chromecast-device-cpu-detailed-specifications/ MfG,
Hat Moby eigentlich Ferien? Ich denke, er könnte abschließende Klarheit über die Leistungfähigkeit von AVRs bringen. Max Schauzer schrieb: > mir völlig wurscht..das ist das was die meistn hier mit den Controllern > machen, fenster Zecihnen, Button anlegen für touch etc...das ist daher > für 90% ein brauchbarer Test. > MPEg kodieren, mit Fliesskoma rechnen im großen Stiel, Spracherkennung > udn Mondfahrzeuge bauen hier die wenigsten..daher interessieren mit die > theoretichen Diskussionen hier..0 Nimm den AVR! Das ist der beste µC der Welt. ARM taugt absolut nichts, da viel zu langsam. Vielleicht kennt jemand noch einen guten Prozessor nicht zum Fenster zeichnen, sondern zum Fenster putzen - auch von außen?
m.n. schrieb: > Vielleicht kennt jemand noch einen guten Prozessor nicht zum Fenster > zeichnen, sondern zum Fenster putzen - auch von außen? Kein Problem. Sind aber nur als Einzelstücke mit subtil unterschiedlichen und nicht immer vorher bekannten Eigenschaften verfügbar. Und die wirklich günstigen Typen sind nur sehr eingeschränkt versendefähig, weil der Zoll sie abgreift und zurückschickt oder einlagert, da hilft auch kein CE Zeichen (wenn sie nicht sowieso schon unterwegs absaufen). Gelegentlich wird auch von Problemen mit der Programmiersprache berichtete, eine Einhaltung von hiesigen Standards ist nicht garantiert.
:
Bearbeitet durch User
Max Schauzer schrieb: > mit Fliesskoma rechnen im großen Stiel ... das sagt alles über die Genauigkeit des Autors ...
A. K. schrieb: > Peter II schrieb: >> geht nicht sinnvoll, sonst würde Intel & Co nicht ihre vergleiche anhand >> von Benchmarks machen. > > Fairerweise muss man sagen, dass man bei AvrX und Cortex M3 durch > Abzählen von Takten von Befehlen eines Programms der Realität wesentlich > näher kommt als bei Intel & Co. Bei den x86 von heute ist das ein völlig > hoffnungsloses Unterfangen. Selbst bei den ARM ist das schon ein schwieriges unterfangen weil auch diese bereits pipelining/prefetch/branch speculation usw. beherrschen. http://de.wikipedia.org/wiki/Pipeline_(Prozessor) Cortex-M0+: 2-stufige Pipeline Cortex-M0 : 3-stufige Pipeline Cortex-M3 : 3-stufige Pipeline mit Sprungvorhersage Cortex-M4 : 3-stufige Pipeline mit Sprungvorhersage Cortex-M7 : 6-stufige Dual-Issue-Pipeline mit Sprungvorhersage Ein einfaches aufsummieren der Befehle aus dem Handbuch gibt allenfalls einen theoretischen Worstcase aber für eine realistischen Wert müsste man genau betrachten in welcher Reihenfolge die verschiedenen Compiler die befehle anordnen (und ggf. auch bezüglich Piplining hin optimieren), wie sich diverse Waitstats im Flash/RAM der verschiednen Modelle auswirken (bzw. in wie weit diese z.B. durch Prefetch neutralisiert werden) und dann noch wie gut die sprungverhersage für den genauen Fall ist usw. Ist insgesamt nicht wirklich viel einfacher aus bei einem der früheren x86.
@ Fpga Kuechle (fpgakuechle) Benutzerseite >ARM Systeme sind sehr wohl für Video/Graphic geeignet, das hat schon der >Ur-ARM im Archimedes Acorn bewiesen dessen Graphic-leistung Ende der >Achtziger einen Commodore Amiga oder Mac CE alt ausehen ließ: >http://en.wikipedia.org/wiki/Acorn_Archimedes >Youtube-Video "DustyShows - Acorn Archimedes Xperience Szenedemo" (bspw. >ab 2:00) Das ist von 1994. Auserdem war die Graphikleistung der 16 Bit System der 80er in erster Linie von den Customchips abhängig, die CPU hat da weit weniger eine Rolle gespielt. Das Video/Demo ist Klasse, aber auch der Amiga konnte sowas. >Heute überzeugt die Videoausgabe auf Smartphones oder in HDMI Sticks - Wirklich? Die Standardsachen ala MP3/Videoplayer sind OK, weil wirrklich optimiert. Aber massig Apps und einfache Games sind einfach nur grausam! Da ruckelt und zuckelt es, trotz GPU und GHz CPU! >ARM von Cortex M0 32 MHz bis multicores im GHz bereich bei Cortex-A12?. Dito heute. Die Graphik macht die GPU, nur selten die CPU.
Irgendwer schrieb: > A. K. schrieb: >> Fairerweise muss man sagen, dass man bei AvrX und Cortex M3 durch >> Abzählen von Takten von Befehlen eines Programms der Realität wesentlich >> näher kommt als bei Intel & Co. > > Selbst bei den ARM ist das schon ein schwieriges unterfangen weil auch > diese bereits pipelining/prefetch/branch speculation usw. beherrschen. > > http://de.wikipedia.org/wiki/Pipeline_(Prozessor) > Cortex-M0+: 2-stufige Pipeline > Cortex-M0 : 3-stufige Pipeline > Cortex-M3 : 3-stufige Pipeline mit Sprungvorhersage > Cortex-M4 : 3-stufige Pipeline mit Sprungvorhersage > Cortex-M7 : 6-stufige Dual-Issue-Pipeline mit Sprungvorhersage Allerdings beherrscht der ARM bedingte Befehlsausführung was die Anzahl der bedingten Sprünge und damit der pipeline stalls bei falsch vorhergesagten Sprüngen deutlich minimiert. Und kennt man die pipelinetiefe, kann man die zyclenzahl für eine schleife immer noch genau bestimmen. Auch ein Einberechnung der pipeline flush Kosten ist nun wirklich kein Hexenwerk (bei sprung anzahl clock cycles laut datenblatt drauf). Kritischer ist IMHO die Abschätzung des Einflußes der Caches insbesonders bei nicht voll assoziativen Caches und Multi-Task systemen. Cache ist allerdings nur bei langsamen (externen) Speicherinterfaces sinnvoll, so braucht der Cortex-M3 keinen Cache. MfG,
irgendwie verstehen hier offenbar einige oder die meisten! gar nicht worum es geht...obwohl der Threatstarter sogar Beispiele gebracht hat.r.affen es einige immer noch nicht.. Es geht nicht darum ob ein ARM generell besser ist, es geht darum ob es für umsteiger eine Überlegung ist, die eigentlich das übliche machen was 90% der Leute hier amchen..nämlich LED Blinken, Button Zeichen auf Displays und einfach TExtausgabe bzw Balken... Die Frage war ob ein ARM hierbei wirklich so viel schneller ist als ein mit 32MHZ getakteter XMEGA z.B. Stattdessen kommen hier Beispiele mit Videocodierung und so ein tinnef... UM es noch mal zu sagen..das FAZIT!! war ein mit 32MHz getakteter ARM ist für sowas genauso schnell..oder nahezu...wie ein 32MHz XMega.. Also ist ein mit 72MHz getakteter ARM auch tatsächlich bei solchen Aufgaben schon erheblich schneller und mit 120MHz noch mehr... Eigentlich war die Frage gar einfach..aber 90% hier schon damit überfordert...
haha, da fallen mir so geiel Beispiele zu diesem Forum hier ein :-) Wenn hier eienr fragt wie man eine Glühlampe am besten wehchselt, weil er sich damit nicht auskennt..werden daraus 45 Antworten doer mehr..sowas wie..warum nimmst Du nicht gleich LED, abbauen und T8 nehmen etc pp LOL Dann kommen die üblichen Sicherheitsdiskussionen das er das besser sein lassen solle und jemand holen soll, andere erklähren den Wirkungsgrad von LED und LAmpen vs T8. Dann kommen welche die sagen das das Thema geschlossen werden könne, weile s sicher nur ein Troll ist hahah, ich schmeiß mich weg
die hinweise auf die Rechtschreibung habe ich vergessen LOL
Thread beobachten
Seitenaufteilung abschaltenBitte 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.