LPC2103 63MIPS?

"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

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

@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

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

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.

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.

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

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.

@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

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?

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

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.

@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

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.

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

@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

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

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/