Nochwas gefunden, das macht sprachlos...
CPU MHz CARD MIPS
68020 14 A1200 2
TG68 Mist 4
68020 28 Blizzard 1220 4
68030 26 ACA1233 4.2
68030 50 6
Coldfire 266 Firebee 8
68040 28 19
68040 40 27
68060 50 32
68060 80 A1200+Apollo1260 46
68080 78 Vampire GOLD 86
68080 92 Vampire GOLD2 165
Die 8 Mips der Firebee sind natürlich bescheiden. Das liegt daran, dass in dem MIPS Benchmark der DBRA Befehl benutzt wird, den Coldfire nicht kann, und emuliert werden muss. Ansonsten stünde die Firebee deutlich besser da,
Ich habe mir den bewussten "Benchmark" mal angeschaut, der diese Werte liefert. Leider gibt's keine Quellen dazu, also musste der Disassembler ran. Die innere Schleife, die da gemessen wird, macht folgendes:
addil #16,%d0
addil #16,%d1
addil #16,%d2
addil #16,%d3
addal #16,%a0
addal #16,%a1
addal #16,%a2
dbf %d6,0x486
Gemessen wird da also letztendlich nichts anderes als wieviele (in dieser Kombination in der Realität nicht auftretende) add-Instruktionen die CPU pro Sekunde ausführen kann. Praktisch werden tatsächlich die "MIPS" (Millionen Instruktionen Pro Sekunde) gemessen.
Und "natürlich" mit Befehlen, die der Apollo-Core tatsächlich parallel ausführen kann. Die Schleife ist sozusagen auf den Core "maßgeschneidert". Da ist nix gegen einzuwenden, aber keiner sollte glauben, daß das Ergebnis die reale Performance widerspiegelt.
Die Tatsache, daß die Firebee bei diesem Benchmark so miserabel abschneidet, liegt nicht *nur* an dem dbf-Befehl, den der ColdFire emulieren muß. adda.l gibt's auf dem Coldfire auch nicht. Gemessen wird hier also im wesentlichen die Geschwindigkeit der m68k-Emulation der cf68klib.
Jetzt bin ich einfach mal frech und baue den synthetischen Benchmark, der zu nix nütze ist, einfach mal so um, daß die Firebee den "Coldfire-native" ausführen kann:
move.l %[loops],d6
add.l #1,d6
1: addi.l #16,d0
addi.l #16,d1
addi.l #16,d2
addi.l #16,d3
lea 16(a0),a0
lea 16(a1),a1
lea 16(a2),a2
subq.l #1,d6
bne.s 1b
Der Code macht im Effekt genau dasselbe, ist immer noch zu nix nütze, aber eben mit Befehlen, die der ColdFire-Prozessor direkt (und in einem Taktzyklus) ausführen kann. Dann sieht's plötzlich ganz anders aus:
ran 7.595000 seconds, MIPS: 210.664917
Daß da nicht 264 steht - entsprechend der FireBee-Taktfrequenz von 264 MHz - liegt daran, daß ich der Fairness halber nicht durch 9, sondern noch immer durch 8 geteilt habe, Coldfire muß die dbf-Entsprechung in zwei Befehle/Taktzyklen aufteilen. Die Interrupts habe ich im übrigen auch nicht abgeschaltet, weil ich nicht weiß, ob das Original das tut.
Aber das ist noch nicht das Ende der Fahnenstange. Schließlich geht's hier nur darum, (ansonsten sinnlose) Befehle so schnell wie möglich auszuführen...
Also noch ein bißchen frecher:
move.l %[loops],d6
add.l #1,d6
1: addi.l #16,d0
mac.l d0,d1,acc0
addi.l #16,d1
mac.l d0,d1,acc0
addi.l #16,d2
mac.l d0,d1,acc0
addi.l #16,d3
mac.l d0,d1,acc0
lea 16(a0),a0
mac.l d0,d1,acc0
lea 16(a0),a1
mac.l d0,d1,acc0
lea 16(a0),a2
mac.l d0,d1,acc0
subq.l #1,d6
bne.s 1b
Auch der Coldfire-Prozessor kann (manchmal) zwei (in diesem Fall ebenso unnütze) Befehle gleichzeitig ausführen, wenn man seine EMAC Units ein wenig beschäftigt. Die Befehle sind alles andere als trivial (eine Multiplikation und eine Addition in einem Befehl), trotzdem werden sie in einem Taktzyklus abgearbeitet (im besten Fall, den ich nicht hinbekommen habe, auch in einem halben).
ran 12.935000 seconds, MIPS: 262.852717
Warum hier keine besseren Werte rauskommen (also "echtes" superskalar x 2), weiß ich (noch) nicht. Die EMAC Units sind ein bißchen zimperlich, was die Registernutzung angeht und ich habe noch zu wenig damit gemacht um wirklich dahintergekommen zu sein, welches Register man wann "ungestraft" anfassen darf.
Die Werte des Apollo-Cores sind selbstverständlich beeindruckend. Einen so komplexen CPU-Core wie den des 060ers mit der Taktfrequenz ans Rennen zu bekommen, ist alles andere als trivial. Ich betone, ich will den hier absolut nicht schlechtreden, mir geht's nur darum, die Sinnlosigkeit solcher Benchmarks aufzuzeigen.