Liebes Forum, Ich wollte die Leistung zweier Prozessoren vergleichen: ARM Cortex-M4F (TI Tiva TM4C1231H6PGE), http://www.ti.com/lit/ds/spms338e/spms338e.pdf und Atmel/MCP SAM3X (http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A_Datasheet.pdf) Beide 32bit, der Cortex M4F läuft mit max 80MHz, der Cortex M3 mit max. 84MHz. Zum Cortex M3 finde ich die Angabe "105 MIPS", zum Cortex M4F "100 DMIPS". Angeblich kann man MIPS und DMIPS nicht einfach so umrechnen... Wie und mit welcher Aussagekraft kann ich die Leistung der CPUs zueinander in Relation stellen? Und hat eine FPU (M3 hat keine, M4F hat eine) einen Einfluss auf diese Zahlen (MIPS, DMIPS)? Danke :-)
Martin Z. schrieb: > Wie und mit welcher Aussagekraft kann ich die Leistung der CPUs > zueinander in Relation stellen? Die beste Aussagekraft hat das Programm, um das es dir geht. Notfalls reduziert auf jenen Kern, der Performance benötigt. MIPS = Meaningless Indicator of Processor Speed.
Ein M4 ist meistens schneller als ein M3, da er mehr Instructions hat, die spezielle Berechnungen beschleunigen können. Wie viel das ausmacht, hängt vom Programm ab. Gleiches gilt für die FPU. Werden floats gar nicht oder nur ein paar bei der Initialisierung benutzt, hat diese keinen Einfluss auf die Geschwindigkeit. Werden floats allerdings häufig benutzt, macht eine FPU einen riesen Unterschied. Der M4 kann beispielsweise mit einer Instruktion 2 32bit Werte zu einem 64bit Wert multiplizieren, der M3 kann das nicht. Auch einige andere Instructions wie MAC (multiply accumulate) sind auf dem M4 schneller.
Es gibt aber auch Operationen, wo sowohl Cortex M3 als auch M4 (bei gleicher Taktfrequenz) kein bisschen schneller sind, als ein oller 8bit AVR. Es gibt sogar ein paar wenige Fälle, wo sie langsamer sind. Deswegen sagte A.K. schon zu Recht, dass der einzig aussagekräftige Benchmark das konkrete Anwendungsprogramm ist.
Stefanus F. schrieb: > Es gibt aber auch Operationen, wo sowohl Cortex M3 als auch M4 (bei > gleicher Taktfrequenz) kein bisschen schneller sind, als ein oller 8bit > AVR. Es gibt sogar ein paar wenige Fälle, wo sie langsamer sind. Kannst du ein paar Beispiele nennen? Stehe vor einem ähnlichen Problem wie der T0.
Jakob schrieb: > Stefanus F. schrieb: > >> Es gibt aber auch Operationen, wo sowohl Cortex M3 als auch M4 (bei >> gleicher Taktfrequenz) kein bisschen schneller sind, als ein oller 8bit >> AVR. Es gibt sogar ein paar wenige Fälle, wo sie langsamer sind. > > Kannst du ein paar Beispiele nennen? Stehe vor einem ähnlichen Problem > wie der T0. Zum Beispiel können sie I/O Pins nicht schneller ein/aus schalten, als AVR (bei gleicher Taktfrequenz - wohlgemerkt). Wo sie langsamer waren, habe ich vergessen. Das stand irgendwo in dem YIU Buch (The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors von Joseph Yiu). Für mich ist die CPU Geschwindigkeit nicht so spannend. Die meisten Anwendungen laufen bei mir mit 1 oder 8 MHz, weil es genügt.
...Danke für die Ausführungen. Die konkrete Anwendung wäre ein Audio/Video-Controller, d.h. Steuerung und Überwachung von Geräten, wie Projektoren etc. über IP, RS232... Es werden hauptsächlich ein paar Strings durch die Gegend geschickt und ausgewertet und auf Eingaben gewartet... Software ist in C (arm gcc). Es gibt professionelle A/V-Controller mit dem Cortex M4F drin und ich hatte mich gefragt, ob ein M3 im Vergleich ein grosser Rückschritt wäre. Wie der A/V-Cointroller von DSP-Funtionen und FPU profitiert, ist mir auch eher unklar. Wird ja beispielsweise kein Audio gerechnet.
Martin Z. schrieb: > Es werden hauptsächlich ein paar Strings durch die Gegend geschickt Dann sollte die CPU Leistung völlig irrelevant sein.
Martin Z. schrieb: > ...Danke für die Ausführungen. > > Die konkrete Anwendung wäre ein Audio/Video-Controller, d.h. Steuerung > und Überwachung von Geräten, wie Projektoren etc. über IP, RS232... Es > werden hauptsächlich ein paar Strings durch die Gegend geschickt und > ausgewertet und auf Eingaben gewartet... Software ist in C (arm gcc). Dann wäre der TM4C129 mit seinem internen Fast Ethernet MAC+PHY vielleicht sinnvoller. Was auch einen EInfluss hat, ist das Flash. Das bremst nämlich einen Cortex M aus. Wenn Geschwindigkeit eine Rolle spielen sollte: Den TM4C129 gibts mit 256k RAM, d.h. da hast Du genug Platz, um kritischen Code aus dem Flash ins RAM zu kopieren und dort laufen zu lassen. Genau deswegen gibts z.B. auch NXP LPC4000'er ohne jegliches Flash, aber mit 1M RAM. Ich denke aber, bei Dir sind andere Sachen wichtiger als ein paar % Geschwindigkeit. fchk
Martin Z. schrieb: > ...Danke für die Ausführungen. > > Die konkrete Anwendung wäre ein Audio/Video-Controller, d.h. Steuerung > und Überwachung von Geräten, wie Projektoren etc. über IP, RS232... Es > werden hauptsächlich ein paar Strings durch die Gegend geschickt und > ausgewertet und auf Eingaben gewartet... Software ist in C (arm gcc). Dann würde ich eher schauen, dass der µC alle benötigten Schnittstellen schon mitbringt. Die Rechenpower des CPU-Kerns ist dagegen wohl eher nicht so entscheidend. > Wie der A/V-Cointroller von DSP-Funtionen und FPU profitiert, ist mir > auch eher unklar. Nach deiner Beschreibung zu urteilen: Gar nicht.
Frank K. schrieb: > Was auch einen EInfluss hat, ist das Flash. Das bremst nämlich einen > Cortex M aus. Wenn Geschwindigkeit eine Rolle spielen sollte: Den > TM4C129 gibts mit 256k RAM, d.h. da hast Du genug Platz, um kritischen > Code aus dem Flash ins RAM zu kopieren und dort laufen zu lassen. Genau > deswegen gibts z.B. auch NXP LPC4000'er ohne jegliches Flash, aber mit > 1M RAM. Ist es aber bei den Cortex-M3/4 nicht teilweise sogar so, dass Sie bei Ausführung aus dem Ram langsamer werden? Ich dachte wenn viele Speicher-/Lade-Operationen in den Ram stattfinden bremst der Bus das System aus. Bei ST sind bei höheren Taktraten die M4 merklich schneller als gleich getaktete M3. Der Einfluss des Prefetchers (ART Accelerator) ist in allen Anwendungen die ich kenne messbar. Für volle PErformance im Ram, kenne ich es von einer anderen Architektur, dass der Code auf anderen Ram Bänken liegen muss. Dann kann parallel auf Daten und Instructions zugegriffen werden … würde mich wundern wenn das beim genannten LPC4000 nicht so ist. Renesas ist sehr schnell auf dem Flash unterwegs … ist aber nicht mehr schneller als ST mit deren Prefetcher. Für die genannte Aufgabe würde ich aber auch eher den Blick auf die Peripherie werfen, wie es einige Vorposter schon getan haben.
Wumpe schrieb: > Der Einfluss des Prefetchers (ART Accelerator) ist in > allen Anwendungen die ich kenne messbar. Bleibt nur die Frage, ob er benutzt wird oder werden darf weil evtl. Code eingeschleust werden könnte wie bei Intel. Wie A.K. schon schrieb: das benutzte Programm entscheidet. Was nützt beste Rechenleistung, wenn auf irgendwelche I/O-Prozesse gewartet werden muss?
Sobald Caches in Spiel kommen muss man die Zugriffscharakteristik des konkreten Programms betrachten. Womit nicht nur CPU-Caches gemeint sind, sondern auch auch Prefetcher und Flash-Caches. Wumpe schrieb: > Ist es aber bei den Cortex-M3/4 nicht teilweise sogar so, dass Sie bei > Ausführung aus dem Ram langsamer werden? Wenn der Core parallele Zugriffspfade von I-Fetch zu Flash und und von Daten zu RAM hat, kann das so sein. Andererseits ist die Zugriffszeit auf RAM kürzer als die auf nichtsequentielles und in keinem Cache enthaltenes Flash. Es kann u.U. sein, das Interrupt-Handler aus dem RAM schneller starten und langsamer laufen als aus dem Flash. M.a.W: Das ist ein komplexes Thema und die Komplexität steigt ungefähr mit <n> in Cortex M<n>.
:
Bearbeitet durch User
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.