ARM Cortex M0+ CoreMark-Bewertungen

Kurze Antwort:

1. Ja
2. Nein

Lange Antwort:

ARM-Kerne haben Funktionen, die jeder Hersteller implementieren kann oder nicht (z. B. Caches, Bus-Fetch-Breite, FPU, MPU usw. - natürlich hängt die Verfügbarkeit vom Kerntyp ab, z. B. 7xx, 9xx, M0, M0+, M3, M7 usw.).

Das Vorhandensein oder Fehlen einer Funktion wirkt sich auf die CPU-Leistung aus.

Das folgende Bild stammt aus dem SAMD21-Datenblatt. Wie Sie sehen können, entscheiden sie sich für die Implementierung eines schnellen Multiplikators und einer 32-Bit-Abrufbreite. Dies ermöglichte dem SAMD21 wahrscheinlich, einen Wert von 2,46 CoreMark/MHz zu erreichen.

Das Datenblatt besagt:

Die SAM D21-Bausteine ​​arbeiten mit einer maximalen Frequenz von 48 MHz und erreichen 2,46 CoreMark/MHz

(Die SAMD20 gibt übrigens auch an, dass sie diese Zahl erreichen kann, und nicht nur 2,14).

Die SAM D20-Geräte arbeiten mit einer maximalen Frequenz von 48 MHz und erreichen 2,46 CoreMark®/MHz.

Wenn Sie in ASM zwei verschiedene Cortex M0+ mit unterschiedlichen Optionen programmiert haben (z. B. einer hat einen langsamen Multiplikator und eine 16-Bit-Busbefehlsabrufbreite und der andere einen schnellen Multiplikator und eine 32-Bit-Abrufbreite), dann wären die Ergebnisse unterschiedlich. Die Ergebnisse wären auch anders, wenn der Test auf Speichern mit unterschiedlichen Zugriffszeiten ausgeführt würde.

Außerdem geben die Coremark-Ergebnisse, die auf der Coremark-Website zu finden sind, die Compiler-Version (und die zum Kompilieren des Tests verwendeten Flags) an. Daher sind sie auch Compiler-abhängig.

Mir sind keine Varianten des m0+-Kerns bekannt, aber verschiedene Chips haben unterschiedliche Speicherbusverbindungen und FLASH-Controller. FLASH-Speicher sind normalerweise zu langsam, um mit modernen Mikrocontrollern Schritt zu halten. Die meisten Mikrocontroller verfügen über FLASH-Beschleuniger , um den sequentiellen Zugriff zu beschleunigen. Bei wahlfreiem Zugriff, wie einem Sprung oder einer Verzweigung, könnten jedoch mehrere Wartezyklen beteiligt sein.

Dies könnte bedeuten, dass der Controller einen höheren Coremarks/MHz-Wert erreichen kann, wenn der Controller mit einer niedrigeren Taktrate betrieben wird. Natürlich führt der Prozessor bei einer höheren Taktrate mehr Berechnungen durch, was nur bedeutet, dass bei höheren Takten mehr Wartezustände beteiligt sein könnten. Einige Mikrocontroller haben sehr gute FLASH-Beschleuniger, obwohl es fast keine Wartezustände gibt.

Darüber hinaus verfügen einige Mikrocontroller möglicherweise über genügend SRAM-Speicherplatz und -Blöcke, um den Benchmark vom SRAM auszuführen. Dies könnte schneller sein, wenn es keine Konflikte mit dem Datenzugriff gibt. Wahrscheinlich wird ARM mit dieser Technik testen, da sie am Benchmarking ihres CPU-Kerns und nicht an der FLASH-Implementierung eines bestimmten Anbieters interessiert sind.

Wahrscheinlich ebenso dramatisch ist der Fortschritt in der Compiler-Technologie. Dies könnte manchmal sogar noch undeterministischer sein. Compiler können im Normalfall recht gut optimieren, können aber dennoch seltsamen Code erzeugen, der sich auch bei scheinbar nicht zusammenhängenden Codeänderungen ändert (selbst wenn Sie eine bestimmte Routine überhaupt nicht berühren).

Außerdem können meiner Erfahrung nach einige architekturspezifische Compiler-Flags bestimmte Programme schneller und andere langsamer machen. Manchmal erstellt O2 oder sogar Os schnelleren Code in GCC als O3, was zur Optimierung der Geschwindigkeit gedacht war.

Die Coremark-Datenbank listet immer die verwendete Compiler-Version und alle Compiler-Flags des Programms auf. Benchmarker dürfen keine Änderungen am Benchmark-Code vornehmen und greifen daher nicht zu sehr in die Optimierungen ein, die der Compiler vornehmen kann. Sicherzustellen, dass diese Bedingungen erfüllt sind, ist der fairste Vergleich; aber selbst dann kann es hier und da Unterschiede geben.

Das Datenblatt des SAM D20 bezieht sich ebenfalls auf 2.46. Wie Sie sehen können, wenn Sie dem Link auf der Arm-Site zum EEMBC-Ergebnis folgen, machen die Speicherkonfiguration, der Compiler und die Compiler-Flags einen Unterschied in den Ergebnissen eines Benchmarks. Da der Benchmark in C geschrieben ist, ist es notwendig, einen Compiler zu verwenden, anstatt in Assembler zu schreiben. Dies liegt in der Natur von Benchmarks, sie beinhalten einen Aspekt, wie gut ein Compiler auf den Kern abzielt (und wie gut der spezifische C-Code auf die Hardware abgebildet wird).

Cortex-M0+ kann entweder mit einem schnellen oder einem kleinen Multiplikator konfiguriert werden. Das Datenblatt für das Teil hier gibt an, dass die Einzelzyklus-Multiplikation implementiert ist. Seite 40 des Datenblatts gibt an, dass r0p1 des Arm-Kerns implementiert ist.

Ein wichtiger Faktor zwischen verschiedenen Low-Power-MCU-Teilen könnte die Speicherarchitektur sein. Zum Beispiel die Flash-Speicherbreite, das Zwischenpuffern von Befehlsabrufen usw. Es ist beispielsweise möglich, einen 16 Bit breiten Befehls-Flash-Speicher zu implementieren (da der Befehlssatz Thumb ist) oder eine CPU-Taktrate zu haben, die höher als die Flash-Geschwindigkeit ist (und vielleicht eine breite Flash-Schnittstelle) - alle mit unterschiedlichen Kompromissen.