Forum: Mikrocontroller und Digitale Elektronik LPC2103 63MIPS?


von Bernd (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe da eine Verständnisfrage.

Laut der Philips Homepage steht:
 http://www.philips.semiconductors.com/news/infocus/lpc2103/
"70 MHz operation (63 MIPS) from both on-chip Flash and SRAM"

Wenn ich aber jetzt mal in Keil die Befehlsausführungszeiten betrachte,
erreiche ich weniger als die Hälfte.

Habe den Controller so Konfiguriert (15MHzQuarz,
PLLx4/PLLDIVx2(M=4->Wert 3,P=2->Wert 1;). => CCLK=60MHz

Das Bit Toggeln läuft in der realen Hardware mit 33ns->17,5MHz. Von
daher würde ich mal behaupten, dass der Prozessor richtig konfiguriert
ist.

Die Assembler-Befehle liegen aber zwischen 17ns und 50ns, wobei die
17ns (würden zwar passen) fast nicht vorkommen. Rein gefühlt würde ich
die mittlere Befehlsausführungszeit wohl ehr leicht oberhalt von 33ns
ansetzen (siehe Bild). Also schaft mein LPC2103 20-30MIPS bei CCLK von
60MHz.
Habe ich noch was falsch konfiguriert, oder sind die 63MIPS@70MHz
Wunschdenken von Philips (=maximale Geschwindigkeit, wenn man nur 1
Cycle Befehle verwendet, was in der Praxis ja nicht vorkommt)?

Danke,
Bernd

von A.K. (Gast)


Lesenswert?

Herstellerangaben zu MIPS sind ungefähr so wie die Geschwindigkeit von
Autos gemessen im freien Fall. Nur zu gebrauchen als Wert der
garantiert nie überschritten aber in realen Programmen kaum je erreicht
wird.

I/O-Pins lassen sich nur per Store-Befehl ansprechen, und der braucht
halt etwas länger als die Addition zweiter Register.

von Peter D. (peda)


Lesenswert?

"sind die 63MIPS@70MHz Wunschdenken von Philips (=maximale
Geschwindigkeit, wenn man nur 1 Cycle Befehle verwendet, was in der
Praxis ja nicht vorkommt)?"


Genau so isses.

Ist aber allgemein so, nicht nur bei Philips.


Peter

von Dominic R. (dominic)


Lesenswert?

Philips kann man sogar noch zu gute halten, dass man MIPS auch als die
Zahl Instruktionen, die maximal pro Sekunde gefetched werden können,
auslegen kann. Das wird durch das MAM und die breite Anbindung des
Flashes ermöglicht. Anderen Designs wie Atmel's SAM7 sind da bereits
aufgrund des Flash Interfaces niedrigere Grenzen gesetzt.

Gruss,

Dominic

von bernd (Gast)


Lesenswert?

Also wenn ich mir einen dsPIC30 (30MIPS) oder PIC18 (10MIPS) ansehe,
arbeiten diese Prozessoren wirklich 95% aller Befehle in einem Zyklus
ab.
Ich werden mir mal einen kleinen Benchmark zusammenbauen, um einige
Funktionen auf verschiedenen MCUs (PIC18, dsPIC, AVR, ARM) zu testen.
Meine gestrigen Versuche sahen aber so aus, das der 16Bit dsPIC
schneller war als der 32Bit LPC ARM bei halber MIPS Zahl.

Gibt es den einen handlichen (vom Gehäuse her noch selber ätzen und
Löten) Mikrocontroller, der so ungefähr die 4fache dsPIC30@30MIPS
Performance bietet? Kann ruhig 16Bit sein, wobei 32 Bit natürlich
schöner wären.

Bekommt man eigentlich schon irgendwo die 40MIPS dsPIC33/PIC24? Die
sollten doch zumindest etwas schneller sein.

von Franz (Gast)


Lesenswert?

>Also wenn ich mir einen dsPIC30 (30MIPS) oder PIC18 (10MIPS) ansehe,
>arbeiten diese Prozessoren wirklich 95% aller Befehle in einem Zyklus
>ab.

und was hilft es mir ,wenn ich gerade die restlichen 5% der Befehle
brauche ,die dann im Schnitt 4 Zyklen andauern??

von Peter D. (peda)


Lesenswert?

@Bernd,

ohne zu wissen, wobei der dsPIC schneller war, kann man überhaupt
nichts dazu sagen.


Besonders unter C hängt es mehr von der Qualität des Compilers ab, wer
schneller ist.
Und was der GCC so für den LPC produziert, sah mir ziemlich suboptimal
aus, da bestehen noch massig Reserven.


Und bei den neueren LPCs haben sie wohl nochmal die Portbitschubserzeit
und das SPI verbessert. Da bestand ja wirklich erheblicher
Handlungsbedarf (8051 war sogar schneller).


Peter

von Dominic R. (dominic)


Lesenswert?

Das hängt ganz davon ab, was du mit den 30MIPS deines dsPICs anstellst.
Der ARM ist sicher überlegen, wenn es um algorithmische Aufgaben geht,
oder wenn ein grosses RAM gefragt ist. Wenn du allerdings nur Port Pins
mit möglichst hoher Geschwindigkeit toggeln willst ist er womöglich
nicht die richtige Wahl.

Der ARM7 führt viele Befehle in einem Takt aus, allerdings keine Loads
(3 Takte) und keine Stores (2 Takte). Ausserdem brauchen
Multipliationen zwischen 2 und 7 Takten, abhängig vom Befehl (MUL, MLA,
...) und den Operanden ('kleine' Operanden sind schneller).

Dein Benchmark sollte also möglichst die Funktionen testen, die du
häufig benötigst. Ausserdem ist es wichtig, das MAM Modul des LPCs
richtig zu initialisieren.

Gruss,

Dominic

von bernd (Gast)


Angehängte Dateien:

Lesenswert?

Also, hier habe ich einen kleinen Benchmarktest. (Siehe Anhang)
Ich habe zu jedem Programmteil die Ausführungszeit (laut Simulator)
oberhalb des Programmteiles eingetragen.

Für dsPIC30 und PIC24 habe ich MPLab und den C30 (demo) verwendet.
Für AVR (AVR-Studio und WinAVR).
Für LPC2103 (µVision und CARM von Keil (demo)).

Ich muss zugeben: Auch wenn der erste Eindruck anders war, der ARM hat
bis auf einen Test alle mit Abstand gewonnen, selbst bei
speicherintensiven Schleifen.

Nur bei 16Bit Divisionen war der dsPIC30/PIC24 schneller.

Den PIC18 konnte ich auf die schnelle nicht testen, aber er dürfte bei
10MIPS so ca. 30% länger als der ATmega@16MIPS brauchen.

Das heißt für mich, dass ich mich ab jetzt nur noch auf den LPC21xx
konzentrieren werde.

Wenn jemand Lust hat, kann er ja an meinen Benchmarktest noch den ein
oder anderen Test oder die ein oder andere CPU anhängen.

Dann könnte man mal herausfinden, wie leistungsfähig die MCUs wirklich
sind.

Grüße,
Bernd

von gerhard (Gast)


Lesenswert?

einen vergleich der performance verschiedener µController findet sich
hier:
http://www.freertos.org/PC/index.html

gruss
gerhard

von bernd (Gast)


Lesenswert?

Demnach schneidet der LPC2106 auch gut ab. Habe festgestellt, dass sich
der LPC2103 offensichtlich auch noch mit CCLK=PLL=120MHz betreiben
lässt. Muss mal schauen, ob da noch alles stabiel läuft :-)

von Robert Teufel (Gast)


Lesenswert?

@viele
LPC2103 bei 120 MHz, nicht stabil!!

MIPS definition. Da gibts es einen benchmark der so heisst (Dhrystone
MIPS). Witzigerweisse kann die MIPS Zahl deutlich hoeher sein als die
Anzahl der ausgefuehrten Befehle !@$! ;-)
Bei ARM7 gelten die folgenden Definitionen angenommen keinerlei
Wait-States: 0,9 Mips / MHz, daher kommen die 63 MIPS.
Zu Thema durchschnittliche Taktzyklen pro Befehl, die Messungen waren
recht gut, es sind so im Bereich 1,7 bis 1,9 CPI (Clocks Per
Instruction).
Zum Thema division schneller im dsPIC, das wundert mich nicht, der ARM7
hat keinen DIV befehl im assembler und muss die ganze Sache in einer
SW-Library abarbeiten.

Mich wuerden mal interessieren wieviel teurer der dsPIC waere im
Vergleich zum LPC2103 obwohl er in den Test deutlich in Performance
geschlagen wurde?

Robert

von Robert Teufel (Gast)


Lesenswert?

@Bernd,

hab mir jetzt erst die Zeit genommen deinen Benchmark und die
Ergebnisse anzuschauen.
Meine Folgerung kann nur sein, dass 40 PIC-MIPS ungefaehr halb so viel
Performance entsprechen wie 60 LPC2103-MIPS.
Wenn du von 60 MIPS sprichst meinst du damit 60 MHz (denn das sind laut
Berechnung lediglich 54 MIPS) oder laeuft der LPC mit 70 MHz?
Nur aus Neugierde, denn es gibt ein Vergelichspapier von Microchip das
behauptet, der PIC24 und / oder DSPic waeren bei 30 MHz schneller als
der LPC bei 60 MHz. Vielleicht wurde da einfach was verdreht,
vielleicht ist der LPC ja mit 30 MHz schneller als der DSPic mit 60
MHz.  OOpps, haette fast vergessen den gibts ja nur bis 40 MHz und
dummerweise kostet bereits der 20 MHz chip mit 20 I/O Leitungen fast
doppelt soviel wie der LPC2103 mit 32 I/O Leitungen.
Genug gelaestert, schoenes Wochenende!

Robert

von bernd (Gast)


Lesenswert?

@Robert:
Ich hatte mich nach dem Keil Simulator gerichtet, und bei dem ist der
kürzeste Befehl bei 60MHz (LPC2103) 0,017µs. Daraus habe ich auf 60MIPS
geschlossen. Die Zeiten für den LPC beziehen sich also auf ECHTE 60MIPS
und nicht auf 60MHz!?!?!



Ich habe aber bei der Gelegenheit noch etwas weiter experientiert. Und
ich muss sagen, in Punkto Performance sind alle C Compiler was für die
"Tonne".

Hier mal ein paar Zeiten für das Füllen/Löschen von 256 einzelnen Bytes
in Assembler:
Hier noch einmal die Zeiten in C:
// fill 256 single bytes
// dsPIC@30MIPS    = 128.26µs
// ATMEGA@16MIPS   = 657µs
// LPC2103@60MIPS  = 46.93µs
  pa8 = a;
  for (i=0; i<256; i++) {
     *pa8++=0x11;
  }

Und hier die Zeiten in Assembler:

dsPIC30@30MIPS 8,63µs (das Füllen von 128x16Bit dauert 4,3µs):
  mov    #0x800,w7
  mov    #0xFF, w6
  repeat #255
  mov.b  W6, [W7++]

Und PIC10@10MHz 103µs:
  LFSR   0, 0x100; pointer 0
  clrf  0; GPR 0 = 8 bit counter
  movlw  0x55
loop:
  movwf POSTINC0
  decfsz 0; General Purpose Register 0
  bra loop

Damit wäre der 60MIPS LPC2103 in C doppelt so schnell wie ein 10MIPS
PIC18 in Assembler. Gegenüber dem dsPIC30@30MIPS in Assembler braucht
der LPC bei doppelter MIPS Zahl die 5,4-fache Zeit :-(

Zugegeben, der Vergleich ist nicht ganz fair, aber mit ARM Assembler
kenne ich mich noch nicht gut genug aus. Vielleicht kann das ja mal
jemand anders für mich übernehmen.

Immerhin können die PICs in einem einzigen Zyklus jede beliebige
Speicherzelle incrementieren. Wie lange braucht dafür ein ARM?
Andererseits hat ein ARM 13x 32Bit Register. Ich denke die vielen
Prozessorregister sind die Stärke des ARM, nicht so sehr seine MIPS
Zahl.

Ich denke die Stärken der ARM Prozessoren liegen im C Bereich. In
reinem Assembler könnte der Vergleich völlig anders ausfallen.

Grüße und schönen Wochenende,
Bernd

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Dhrystone oder Speicher füllen scheint mir als Benchmark ziemlich
sinnlos und wenig aussagekräftig. Mess doch lieber mal welcher
Prozessor einen FIR Filter schneller berechnet oder sowas in der
Richtung.

von Bernd (Gast)


Lesenswert?

@Andreas: Mit DSP habe ich nicht fiel am Hut. Wäre aber sicher auch
interessant. Aus dem Musikbereich weiß ich, dass noch vor 10Jahren
alles auf DSPs geschwört hat. Heute gibt es Tonstudios, die alleine von
der Rechenleisung moderner PCs leben. Pro MIPS erreicht man bei DSPs
bestimmt mehr FLOPS, aber auf das Endergebnis kommt es schließlich an.


@All:
Hier noch mein Versuch den letzten Test in ARM Assemnbler zu
realisieren:
LPC@60MIPS 25,6µs.
  mov r0, #0x3FFFFFFF  ; RAM address
  mov r1, #0x55; fill value
  mov r2, #0x100;
loop:
  strb r1, [R0,#0x1]!
  subs r2, r2, #1
  bne loop

Damit wäre der LPC2103 vier mal so schnell wie der PIC10. Gegenüber dem
dsPIC aber immer noch 3x langsamer.
Hier sind die DSP Befehle wie repeat doch zumindest in einigen
Bereichen deutlich leistungsfähiger.

von A.K. (Gast)


Lesenswert?

Wenn schon handoptimieren, dann bitte richtig ;-).
  ldr r0, =0x55555555
  mov r1, r0
  mov r2, r0
  mov r3, r0
  mov r4, r0
  mov r5, r0
  mov r6, r0
  mov r7, r0
  ldr r8, =ram_address
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
  stmia r8!, {r0,r1,r2,r3,r4,r5,r6,r7}
Macht ~93 Takte, also ca 1,5µsec.

Nicht dass dieser Vergleich irgendeinen Sinn hätte...

"die Stärken der ARM Prozessoren liegen im C Bereich"

Damit liegst du richtig. Erst recht C++.

von A.K. (Gast)


Lesenswert?

"Heute gibt es Tonstudios, die alleine von der Rechenleisung moderner
PCs leben."

Lass es ein paar Dutzend Tonstudios pro Lösung sein. Macht viel
Entwicklungsaufwand umgelegt auf sehr kleine Stückzahl. Ergebnis:
Kosten der Hardwarebasis sind völlig irrelevant, dafür ist die
Entwicklung der Software entscheidend. Und die ist auf dem PC
einfacher.

Wenn das Produkt jedoch beispielsweise ein Kabelmodem werden soll, mit
6-7-stelliger Stückzahl, dann sieht die Rechung etwas anders aus. Kein
Mensch kauft dir dafür einen angepassten PC ab.

von bernd (Gast)


Lesenswert?

@A.K.:
Und wo ist die Schleife und der Single Byte Zugriff?

O.K. Wir wissen jetzt alle, dass der LPC tendenziel Leistungsfähiger
ist.

Im Übrigen ging es mir ja nur darum, dass ich endlich die
Assemblerprogrammierung aufgeben möchte und auch auf Mikrocontrollern
eine höhere Spreche verwenden möchte. Und da ich keine Massenprodukte
entwickle sonder nur zu Hause ein bischen bastelle, ist für mich nicht
der Preis des Controllers im Vordergrund (zumindest nicht bei ein paar
Euro unterschied), sondern die Einfachheit der Programmierung von
größter Bedeutung.

Langsammer Prozessor -> viel Optimierung erforderlich -> viel Zeit
erforderlich
Schneller Prozessor -> weniger Optimierung erforderlich für gleiche
Performance -> weniger Aufwand bei gleichem Endergebnis und weiteres
Potenzial bei Bedarf.

Außerdem möchte ich mich auch nicht ständig in neue Controller
einarbeiten müssen, nur weil der bisher verwendete gerade nicht mehr
reicht. Dann lieber immer gleich eine Nummer größer. Und mit 7x7mm ist
der LPC ja doch noch recht handlich. :-)

Grüße,
Bernd

von Henry (Gast)


Lesenswert?

Neue Datei benchmark.c mit den Testwerten des Zilog Z16F.

von Henry (Gast)


Angehängte Dateien:

Lesenswert?

Und nochmals...

Neue Datei benchmark.c mit den Testwerten des Zilog Z16F.

von Be M. (bemi)


Lesenswert?

Ich habe mir meine alte benchmark.c gerade noch mal angesehen. Mit dem, 
was ich bisher dazugelernt habe ist die Datei so nicht aussagekräftig. 
Außerder habe ich einen Fehler gefunden.
So sollte es eigentlich richtig sein:
1
asm volatile ("":::"memory");\
2
// copy 64 32bit words
3
// PIC18@10MIPS    =
4
// PIC24@40MIPS    = 40.25?s
5
// dsPIC@30MIPS    = 53.66?s
6
// ATMEGA@16MIPS   = 274?s
7
// Z16F@20MIPS  = 23.0?s
8
// LPC2103@60MIPS  = 17.10?s
9
  pa32 = (long*)a;
10
  pb32 = (long*)b;
11
  for (i=0; i<64; i++) {
12
    *pa32++=*pb32++;
13
  }

Vielleicht ist die Idee einen MCU Benchmark zu erstellen garnicht so 
schlecht, aber es müssen viele Dinge beachtet werden, die Ich darmals 
vielleicht übersehen habe.

1. Generell sollte der Verwendete Compiler (Version) angegeben werden.
2. Dann sollte sichergestellt werden, daß immer die beste Optimierung 
für Geschwindigkeit gewählt wird.
3. Da der C32 teilweise sehr "wild" optimiert, sind Memory Barriers (asm 
volatile ("":::"memory"); // in GCC) nützlich, damit man auch wirklich 
sicherstellt, daß der gesammte Codeblock auch an einem Stück ausgeführt 
wird.
4. Dadurch daß man alle Variablen volatile deklariert, verhindert man 
zwar, daß der Compiler die komplette Berechnung wegoptimiert, allerdings 
geht hierbei auch die Stärke von CPUs verloren, welche sehr viele CPU 
Register haben und eigentlich weniger Speicherzugriffe brauchen, als 
andere, wenn eben nicht alles volatile ist.
5. Vielleicht währe es aussagekräftiger, wenn die einzelnen Codeblöcke 
etwas umfangreicher währen und in sich bereits einen Mix aus 
verschiedenen Operationen beinhalten. Also ein Benchmark für eine 
komplexe float Berechnung, eine andere, die ein int Array verarbeitet, 
eine Routine die Strings aufbereitet (String zusammenbauen, in den 
mehrere Werte float, int ... einzuarbeiten sind) und so. Es dürfen 
allerdings nur Routinen verwendet werden, die auf reinstem C basieren 
oder auf absoluten Standardbibliotheken, da sonst der Vergleich 
unmöglich würde.

von Robert T. (robertteufel)


Lesenswert?

Noch ein Vorschlag. Der Focus auf Division in den meisten Teilen dieses 
Benchmarks laesst den LPC2103 eigentlich echt schlecht aussehen, der 
ARM7 hat naemlich keinen DIV Befehl. Waere interessant einen STM32 oder 
LM3xx mit Cortex M3 auch zu listen, die haben einen DIV Befehl.
Da ist schon der Simulator von Keil MDK sehr aufschlussreich und 
hinreichend genau.

Robert

von Be M. (bemi)


Lesenswert?

Währe interessant, aber erst mal bräuchte man einen Benchmark Test, 
welcher auch in der Lage ist eine halbwegs verlässliche Aussage über die 
Leistung in dem ein oder anderen Bereich zu machen. Und wie oben schon 
erwähnt, glaube ich nicht, daß meine Benchmark.c dazu optimal ist.

Es währe erst einmal zu Klären, was man denn überhaupt vergleichen will.
So Konstruktionen wie "asm volatile ("":::"memory");" sind GCC 
spezifisch und müßten irgendwie auf andere Compiler übertragen werden.

von Robert T. (robertteufel)


Lesenswert?

@Bernd,

so einen Benchmark gibt es sogar, meiner Meinung nach. Schau mal 
spasshalber rein bei http://www.eembc.org/home.php . Ich war dort ca 10 
Jahr in dem Konsortium, allerdings ist der Fokus ganz eindeutig auf 
high-end und die Benchmark Sourcen werden nicht veroeffentlicht. Auf 
einem 8-bit Rechner wuerden die allermeisten Benchmarks gar nicht 
funktionieren wegen Speicherbedarfes. Da kommen aber solche kleinen 
Vergleiche wie Dein Code hinzu, wie lange dauert ein MUL, DIV, Daten 
verschieben, Daten mit logischen Operatoren verknuepfen, die Daten 
variieren von 1/8/16/32/(64?) bit und float. Das ganze in einer Schleife 
abarbeiten und schon hat mein einen low-end Benchmark, der dann von 
allen zerissen wird, die dabei nicht ihre eigenen Anwendungen 
wiederfinden ;-))

Gruss aus California, Robert
bei Sonnenschein und 15C, ein wunderschoener Herbst- oder Fruehlingstag

von Be M. (bemi)


Lesenswert?

Na ja, theoretisch kann man ja jeden Programmschnippsel als Benchmark 
für irgendetwas verwenden. Wichtig wäre nur, daß die Rahmenbedingungen 
stimmen. Im Endeffekt wäre es ja kein reiner CPU Benchmark, sonder immer 
ein Benchmark für einen Mix aus CPU und Compiler. Was nützt die beste 
MCU, wenn der Compiler nicht optimal arbeitet. Andersherum mag ein top 
Compiler einer eigentlich schlechteren MCU zum Sieg verhelfen.

Wie oben schon erwähnt, verhindern zu viele "volatile"s, daß der 
Compiler optimalen Code erzeugt. Andererseits, läßt man volatile weg, 
kann es passieren, daß der ein oder andere Compiler ganze Berechnungen 
wegläßt, da die Ergebnisse ja nirgends mehr gebraucht werden. Man müßte 
also sicherstellen, daß man dem Compiler alle nur erdenklichen 
Freiheiten für die Optimierung unter realen Bedingungen läßt und 
andererseits darauf achten, daß alle Rechenergebnisse am Ende auch 
tatsächlich irgendwo benutzt werden, so daß der Compiler sie nicht 
wegoptimieren kann.
Problematisch ist es auch mehrere Benchmarks in einem Program 
zusammenzufassen, da z.B. der C32 die Befehlsanordnung kräftig 
durcheinanderrüttelt. Daher auch die Idee mit der Memory Barrier, damit 
zusammen bleibt was zusammen gehört. Sonst wüßte man ja nie, ob zwischen 
zwei Breakpoints auch tatsächlich alle Befehle abgearbeitet wurden.

Übrigens: Hier ist es bereits dunkel und wir haben schnuckelige -4°C, 
aber drinnen ist es wärmer ;-)
Verwendet man in Amerika nicht eigentlich °F? Oder hast Du umgerechnent?

von Robert T. (robertteufel)


Lesenswert?

15C ist ca 59F.

Du hast den Nagel mit der Kombination Compiler / MCU voll auf den Kopf 
getroffen. Da trennt sich auch oft die Spreu vom Weizen, der GCC 
schneidet oft nicht so toll ab in der Kombination 
Kompaktheit/Performance. Manchmal lohnt sich fuer 5% Unterschied in 
Performance oder Groesse ein grosser Betrag, denn das macht den im 
Zweifelsfall Unterschied zwischen 2 sonst vergleichbaren Endprodukten. 
Wieder gilt, wenn der Programmierer in beiden Faellen gleich faehig ist.
Es fehlt ausserdem auch noch die Selbststaendigkeit der Peripherie. So 
kann z.B. bei manchen MCUs, die Kombination Schnittstelle mit DMA die 
CPU sehr entlasten, vor allem von echtzeitkritischen Anforderungen und 
hohen Baudraten. Selbiges gilt fuer ADC + DMA usw. Bei EEMBC haben sich 
ca. 20 Firmen, die alle MCUs herstellen manchmal fast die Koepfe 
eingeschlagen was getestet werden sollte. Der eine hatte ein tolle CPU 
aber keine Peripherals (z.B. Intel, AMD, High-End ARM XScale...), andere 
haben ein komplettes System auf dem Chip aber die CPU leistet nur 10% 
der erst erwaehnten. Je nach Anwendung kann z.B. ein Soft-UART voll 
ausreichend sein, sofern es anderweitig wenig Echtzeitanforderung gibt, 
wenn aber schnell auf einige Interrupts reagiert werden soll, z.B. 
Motorsteuerung, Umrichter, dann kommt man in echte Konflikte. Es ist ein 
sehr weites Feld, das mit den Benchmarks, hab da schon viel gemacht, 
aber es gibt nicht wirklich einen Benchmark, der es allen recht machen 
kann. Z.B. hat hier noch fast keiner verstanden was DMIPS heisst. Es ist 
ein Benchmark, genannt Dhrystone, der die Anzahl der Dhrystones misst 
mit Bezug auf eine steinalte Architektur VAX PDP11, welche per 
Definition 1 MIPS hatte.

Gruss, Robert

von (prx) A. K. (prx)


Lesenswert?

Robert Teufel wrote:

> mit Bezug auf eine steinalte Architektur VAX PDP11, welche per

Fast. Die Referenz ist die (32bit) VAX 780, nicht die (16bit) PDP11. Und 
die hatte nur per Definition 1 MIPS, nicht wirklich.

von Robert T. (robertteufel)


Lesenswert?

@A.K.

Du hast natuerlich recht mit der 780. Im Bezug auf MIPS allerdings denke 
ich, das ist sehr stark eine Sache der Definition. All die MIPSs, die 
immer erwaehnt werden, z.B. Cortex M3 mit 1.25 DMIPS/MHz, beziehen sich 
auf diesen VAX780 Wert. Eine MIPS Bewertung ohne einen festen Code ist 
noch weniger sinnvoll als es dieser Dhrystone Code ohnehin schon ist. 
Die meisten Architekturen koennen NOPS echt schnell ausfuehren ;-)
Also wenn schon die sinnlosen MIPS, dann bitte DMIPS und nicht einer der 
sagt, mein Micro kann nur alle 16 Zyklen eine MUL durchfuehren oder die 
Sache mit den Port Toggeln....

Robert

von (prx) A. K. (prx)


Lesenswert?

Ich beziehe mich dabei auf diesen Wikipedia Satz:

"For a while the VAX-11/780 was used as a baseline in CPU benchmarks 
because its speed was about one MIPS. Ironically enough, though, the 
actual number of instructions executed in 1 second was about 500,000."

Klar konnte man mit NOPs auch schneller sein, aber es entbehrt nicht 
einer gewissen Ironie wenn die "Einheit" MIPS nicht einmal dort auch nur 
annähernd passt wo sie herkommt.

von Patrick W. (seennoob)


Lesenswert?

Naja Benchmarks sind auf eine gewisse weiße immer relativ. Das erinnert 
mich an die Highend Grafikkarten. Die eine hat laut Hersteller einen 
schnelleren Chip. Trotzdem kann die Grafikkarte mit dem langsameren Chip 
bei vielen Anwendungen (Spielen) mit halten.

Also die Leistung ist schlicht von der Anwendung abhängig.

MFG Patrick

von Robert T. (robertteufel)


Lesenswert?

@Patrick

Du hast den Nagel absolut auf den Kopf getroffen. Benchmarks sind in 
erster Linie dazu da, eine Vorauswahl zu treffen, denn fuer eine 
groessere Anwendung ist es nicht praktikabel mehrere Prozessoren auf der 
Hardware zu testen.
Meiner Meinung nach kommt der Ansatz von http://www.eembc.org dem 
Gedanken am naehesten verschiedene Anwendungen zu testen. Allerdings 
sind diese Benchmarks nicht open source, sondern werden mit Aufwand 
gepflegt von ein paar Ingenieuren, die auch Familien muessen. Der 
Vorteil bei diesen Benchmarks ist eine recht gute Vergleichbarkeit. 
Leider sind die "low end 32-bit" sehr schwach vertreten, keiner will 
Tests veroeffentlichen, bei denen er schlechter abschneidet als der 
direkte Mitbewerb.

Gruss, Robert

von Patrick W. (seennoob)


Lesenswert?

Ach immer mit dem Geschwindigkeits Vergleich da ! Erinnert mich an einen 
Professor der alles mit einem Controller abdecken will. Naja der 
Techniker von heute muss Flexibäl sein. Ich will da ned sagen für jedes 
Projekt einen anderen nehmen sondern nicht nur an die Rechenleistung 
denken!

Was nutzt ein 64 Bit µC @200MHz wenn man nur I/O macht wie 
Parallelport/SPI/TWI dann sind die 200MHz durch die Interrupts weg. Da 
nehm ich doch lieber so ein PICxx mit DMA oder ARM xxxx (Cortex M3)mit 
DMA und lass die ganzen Trnasfers im Hintergrund laufen und hab dann 
denn Kern frei für die eigentliche Arbeit.

Aber der allerwichtigste Faktor ist man muss das Teil auch verstehen! 
Wer schon Probleme hat das Datenblatt eines AVR's oder 8051er zu lesen 
der wird sich wohl nicht bei den 32Bit (Monstern) leichter tuen.

MFG Patrick

von Henry (Gast)


Angehängte Dateien:

Lesenswert?

Neue Datei benchmark.c mit den Testwerten des Zilog Z8Encore!XP.

von Henry (Gast)


Angehängte Dateien:

Lesenswert?

Nochmals überarbeitete Datei benchmark.c weil die ATmega Werte falsch 
waren. Messungen ohne Codeoptimierung.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

Henry wrote:
> Nochmals überarbeitete Datei benchmark.c

Mir ist aufgefallen, dass die Parameter für Multiplikation und Division 
zwar 16 bzw 32bit Typen sind, die Werte allerdings nicht alle Bits 
belegen (y16, y32). Die Laufzeit einer Software Divison unterscheidet 
sich aber zum Teil erheblich in Abhängigkeit von den tatsächlichen 
Werten. Multiplikation auch (z.B. beim ARM7), nur ist da der Unterschied 
nicht so dramatisch.

Gruß
Marcus
http://www.doulos.com/arm/

von seennoob (Gast)


Lesenswert?

Mal eine Frage zu dem Benchmark.
Müsste der dsPIC30 nicht besser abschneiden als der PIC24 bei dem Sinus 
berechnen ?
Wie der Name des dsPIC schon besagt hat ja der DSP-Funktionalitäten die 
sich positiv auf das auswirken müssten ?
Oder liege ich hier falsch ?

MFG Patrick

von seennoob (Gast)


Lesenswert?

Naja ich find so Benchmarks sowieso immer lustig.

Denn man kann nie mit normierten Codes das optimum herausholen also -> 
Warum macht man dann die Sachen ?




MFG Patrick

von Bernd (Gast)


Lesenswert?

Es ist zwar schon lange her, dass ich dieses Thread gestartet habe, aber 
wie oben ja auch schon erwähnt, testet man immer die Kombination aus MCU 
und Compiler.

Wieso versucht man überhaupt sowas wie einen Benchmark zu basteln?
Die Idee war überhaupt erst mal ein Gefühl für die Leistungsfähigkeit 
der einzelnen MCU/Compiler Kombinationen zu bekommen.

Aufgrund unterschiedlicher Peripherie und unterschiedlicher 
Kompileroptionen kann ohnehin nur ein grober Vergleicht entstehen.

Niemand hat behauptet, dass so ein Benchmark eine für den Einzelfall 
richtige Aussage zuläßt. Aber eben doch ein grobes Gefühl darüber 
vermittelen kann, was mit Standardcode möglich ist.

Wieso dsPIC30 und PIC24 gleich abschneiden ist einfach. Soweit ich mich 
erinnere gabe es darmals nur einen Compiler für die 16 Bit PICs. Wenn 
ich mich recht erinnere war es so, dass der Compiler die speziellen DSP 
Funktionen garnicht zur Codeerzeugung verwendet hat, sofern man nicht 
spezielle in Assembler geschriebene Bibliotheken verwendet hat. Das mag 
sich inzwischen geändert haben, da es ja mittlerweile unterschiedliche 
Compiler gibt.

Grüße,
Bernd

von m.h. (Gast)


Lesenswert?

Ich habe mir grad auch mal die benchmark.c angeschaut. Dabei ist mir 
aufgefallen dass die PIC24 bei den 8 und 16 bit copy, fill und clear 
Tests wesentlich schneller sein müssten, wenn man statt der for-schleife 
ein repeat-konstrukt benutzt. Also in etwas wie asm:
1
repeat w2
2
mov.b [w0++],[w1++]
Dazu kommt ein wenig Overhead um die Pointer in die Arbeitsregister zu 
laden.
Damit kommt man dann auf weniger als 10µs für 256 x 8 bit oder 256 x 16 
bit bei 40Mhz. Sogar die die 24F schaffen das dann in weniger als 20µs 
bei ihren max 16Mhz.

von Henry (Gast)


Lesenswert?

Ist es denn so schwer zu verstehen, dass es bei diesem Benchmark um ein 
PI mal Daumen Einschätzung des Controllers geht. Weder die Qualität des 
Compilers noch die Vorzüge der Assembler Programmierung stehen zur 
Diskussion.

Bitte 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
Noch kein Account? Hier anmelden.