ARM8/ARMv4-Eigenschaften für einen qualitativen Vergleich zwischen RISC-, CISC- und MISC-Prozessordesigns

Sie werden nicht abschließend in der Lage sein, ein Ergebnis zu erzielen, das ist nicht möglich. Benchmarking ist immer subjektiv und kann und wird häufig verwendet, um das gewünschte Ergebnis zu erzielen (A ist besser, B ist besser, C ist besser usw.).

Die Anzahl der Befehle ist nicht relevant, nicht mehr als die Anzahl der Register usw. Die Anzahl der Transistoren ist interessant, aber der Vergleich eines einzelnen Soc-Chips mit einem Prozessor, der externe Chips benötigt, um dieselbe Funktionalität bereitzustellen. Oder ein Chip kann relativ zu einem anderen große Teile gleichzeitig abgeschaltet haben oder einen großen Teil abgeschaltet haben, um den Benchmark abzuschließen, oder einer hat mehr Transistoren, schaltet sie aber seltener um als der andere, der weniger hat. was möglicherweise zu einem unterschiedlichen Stromverbrauch führt.

Intel stellt und verkauft Chips, die zufällig (viele) ihres Materials enthalten. Arm stellt keine Chips her, sie verkaufen IP. Wie schnell dieses Programm in Quellcodeform ausgeführt wird, hängt stark von den Compileroptionen, dem Prozessor usw. ab. Dieselbe IP kann je nach Gießerei und Zellbibliothek und Prozess, der zu ihrer Implementierung verwendet wird, sehr unterschiedliche Mengen an Strom verbrauchen. Gleiche Architektur, gleiche Taktrate, unterschiedlicher Stromverbrauch. Sie vergleichen also gleich auf eine andere Weise Äpfel mit Birnen. Ich kann mir keinen echten Fall vorstellen, in dem ein Armkern alles ist, was sich im Chip befindet. Im Allgemeinen wickeln Sie den Arm mit einer Menge Zeug in den Chip ein, Zeug, das mit dem anderen Prozessor vom Chip entfernt wäre. Der richtige Vergleich wäre das gesamte System, nicht nur die Leistung des Prozessors.

Dies führt Sie zu Taktunterschieden, ein Prozessor kann viel effizienter sein als ein anderer und kann den gleichen Benchmark mit einer anderen Taktrate durchführen oder auf andere Weise weniger Hardware oder Strom oder was auch immer verbrauchen. Es ist sehr einfach, einen Benchmark zu schreiben, der auf einem kleinen batteriebetriebenen Mikrocontroller-Board läuft, das weniger Strom verbraucht als ein x86-Computer, selbst wenn der x86 stark untertaktet ist oder sein könnte. Genauso einfach ist es, einen Benchmark zu schreiben, der auf einem x86 blitzschnell läuft und für dessen Fertigstellung dieser Mikrocontroller eine Ewigkeit braucht. Auch wenn Sie sie gleich getaktet haben oder könnten.

Nur Compiler allein sorgen dafür, dass auf demselben Computer derselbe Quellcode und sehr unterschiedliche Geschwindigkeiten ausgeführt werden. Es ist einfach nicht möglich, zwei Systeme auf diese Weise zu vergleichen, außer dass der Benchmark genau angegeben wird. Dieser spezielle Code, der mit diesem Compiler auf Geschwindigkeit kompiliert wurde, der von Hand überprüft wurde, um diese Qualität von optimiertem Code zu erzeugen, lief auf diesem speziellen System, wobei das System so viel Strom verbrauchte. Dieses andere System, das diesen Compiler verwendet, der von Hand geprüft wurde, um eine ähnliche Optimierung bereitzustellen, erforderte diese Taktrate und so viel Leistung, um in etwa der gleichen Zeit ausgeführt zu werden. Wiederholen Sie dies für jede der unendlich vielen möglichen Benchmark-Anwendungen, an denen Benutzer interessiert sein könnten.

Der Mips/MHz-Vergleich hängt stark vom Compiler und der Anwendung ab, große Variationen von Mips auf demselben System ohne Hardwareänderungen. Auf keinen Fall können Sie mit dieser Methode zwei Prozessoren wirklich vergleichen. Veröffentlichte Mips in MHz sind nur Marketing-Flausch, ignorieren Sie es. Ebenso können Sie genauso viel Vertrauen in den veröffentlichten Stromverbrauch setzen wie in die Mips/MHz-Zahlen, er basiert auf einem Benchmark, wenn Ihre Anwendung nicht derselbe Benchmark ist, was nützt es?

Sie müssen eine Reihe von Systemen bauen (jedes Board-Design für den Benchmark spezifisch auslegen) und versuchen, die Anzahl der Variablen zu reduzieren, oder idealerweise den Ansatz wählen, das absolute Minimumsystem, maximale Optimierung, in der Lage zu machen, den Benchmark auszuführen genau X Zeit. Wiederholen Sie dies für das andere System und vergleichen Sie dann den Stromverbrauch des gesamten Systems für die Dauer der Ausführung dieses Benchmarks. Wiederholen Sie dies für die Millionen verschiedener Benchmarks, um einen fairen und allgemeinen Vergleich zu erhalten, ist es möglicherweise nicht möglich, die Ergebnisse auf schlüssige Weise zu reduzieren.

Für einen Architekturunterschied möchten Sie idealerweise, dass die Prozessoren in derselben Gießerei mit derselben Zellbibliothek und demselben Prozess usw. gebaut werden. Wenn Sie bereit und in der Lage sind, konkurrierende Kerne zu lizenzieren, bestücken Sie die Chips auf derselben Ebene und verwenden Sie ähnliche Busraten und so viel ähnliche externe Hardware (die Systembusse sind zweifellos unterschiedlich, einen gemeinsamen Bus daraus zu machen, könnte einem einen unfairen Vorteil verschaffen). Gleiche Anzahl an Caches mit gleichen Vorteilen usw. Vielleicht hast du bessere Chancen auf einen echt aussehenden Vergleich. Dies wäre die einzige Möglichkeit, etwas Plausibles zu finden, derselbe Benchmark-Lauf auf verschiedenen Architekturen, die in derselben Gießerei, derselben Zellbibliothek, demselben Prozess, derselben Cache-Größe, demselben DRAM usw. ausgeführt wurden. Sie können die Benchmarks immer noch manipulieren, um einen von beiden zu erstellen der schnellste oder niedrigste Stromverbraucher.

Interessanter wäre ein empirischer Vergleich. Nehmen oder erstellen Sie Benchmarks einzeln, sehen Sie sich die verschiedenen Möglichkeiten an, Code vom Compiler zu generieren. Untersuchen Sie die Busse, die Sie untersuchen können, und bekommen Sie ein Gefühl für die Fetch-Größen. Wenn möglich, können Sie mit den Anweisungen mit fester oder variabler Wortlänge an den Bussen erkennen, wo die Entscheidungen mit variabler Länge getroffen werden. Das erste Byte sagt, dass Sie möglicherweise das zweite Byte untersuchen müssen, das zweite Byte lässt Sie möglicherweise erkennen, dass Sie sofort 4 weitere Bytes benötigen , jetzt können Sie ausführen. Wie viel muss in der Nähe des Decoders eingeklemmt werden, um dies effizient zu machen? Wie viel muss man bei einem Ast wegwerfen und holen, wie schnell geht das? Sie müssen sich die Menge des Codes ansehen, um ähnliche Aufgaben auszuführen, aufgrund der unterschiedlichen Anzahl von Registern (real oder virtuell) (x86 ist mikrocodiert oder viele sind es, arm ist nicht mikrokodiert), wie oft muss der Code Register auf dem Stack austauschen (sehr einfach zu schreibende Benchmarks, die dafür eine Architektur relativ zu einer anderen bestrafen). x86 kann mehr Programme in einem Cache gleicher Größe speichern als ein Arm, aber der Arm ist beim Decodieren dieses Codes deterministischer. x86 führt zu mehr Ausrichtungsstrafen als Arm, da es sich anbietet, nicht ausgerichtet zu werden, wenn Arm entweder gefördert oder erzwungen wird. Können Sie Benchmarks erstellen, die einen Vorteil für jeden Befehlssatz zeigen, sollte es sehr einfach sein, eine Schleife zu erstellen, die x86-Anweisungen in einen Cache einer bestimmten Größe passt, aber keine Arm-Anweisungen in den Cache derselben Größe passt. Es könnte einfach sein, einen stark verzweigten Benchmark zu haben, der Waffenvorteile zeigt oder zumindest einen Verzweigungsprädiktor gegenüber einem anderen hervorhebt. Uhren und Strom sind immer noch aus dem Bild,

Wie auch immer, das war eine Tangente, Sie können nicht zwei Prozessoren auf diese Weise vergleichen und die Eingeweihten die Ergebnisse als etwas Bedeutsames akzeptieren lassen. Die Massen mögen sich täuschen lassen, aber nicht diejenigen, die wissen, was vor sich geht. Empirisch Vor- und Nachteile aufzeigen, das wäre vielleicht machbarer und für alle interessanter. Der Vergleich von Opencores im selben FPGA könnte auch interessant sein, aber ein kommerzieller Prozessorchip auf einem kommerziellen Board im Vergleich zu IP, das auf vielen verschiedenen Boards auf viele verschiedene Arten implementiert werden kann, ist einfach nicht plausibel.