Software > Software (16-/32-Bit)

Coremark für 68000

<< < (7/27) > >>

czietz:
@tuxie, Du kannst dann aber nicht mehr trennen, ob der Codegenerator im Compiler für diese CPU einfach besser optimiert (= Compiler ist besser) oder ob die CPU wirklich von ihrem erweiterten Befehlssatz profitiert (= CPU ist besser). Siehe KarlMüllers Kritik an der Compiler-Abhängigkeit in https://forum.atari-home.de/index.php/topic,15025.msg237452.html#msg237452.

czietz:

--- Zitat von: KarlMüller am So 24.02.2019, 09:59:03 ---Unter MagiC mit VT52 knallt es auch.

--- Ende Zitat ---

Das muss dann ein spezielles Problem mit MagiC auf dem 68060 sein, auf dem 68000 und dem 68030 läuft mein COREMARK.TOS (inkl. !RUNME.TOS) auch unter MagiC einwandfrei. Da ich MagiC in der 68060-Emulation von Hatari nicht einmal gestartet bekomme und auch keine passende echte Hardware besitze, weiß ich nicht wie ich das debuggen sollte.

1ST1:

--- Zitat von: tuxie am So 24.02.2019, 10:21:23 ---Ich meine bei einem Autorennen schaltet man ja auch nicht zwei Cylinder ab nur weil der andere zwei weniger hat ?

--- Ende Zitat ---

Der Motorsport ist sogar sehr reglementiert, deswegen gibt es da verschiedene Rennklassen. Z.B. in der Formel 1 ist sehr genau festgelegt, was darf und was nicht, z.B. ob und wieviele Turbolader oder nicht.

Ich denke, bei Benchmarks muss es beides geben, die Variante, die überall läuft, weil ja auch nicht von jeder Software eine auf bestimmte CPU optimierte Variante existiert, und eine möglichst optimierte Version, die zeigt, was unter Ausnutzung aller CPU-Features zeigt, was möglich wäre. Letzteres vor allem als Anreiz, solch CPU-spezialisierte Software zu erstellen, wenn die Anwendung von den erweiterten CPU-Features profitiert. (Eine Textverarbeitung wartet auf der moderneren CPU nur schneller auf die Eingaben des Autors.)

mfro:

--- Zitat von: czietz am So 24.02.2019, 10:07:19 ---
--- Zitat von: KarlMüller am So 24.02.2019, 09:59:03 ---Würde das Ergebnis nochmal steigen, wenn man eine Version für den 060 nutzen hätte?

--- Ende Zitat ---

Mutmaßlich ja, denn ich sehe den Effekt auch auf dem TT, wenn ich Coremark speziell für den 68030 compiliere. Aber es würde imho die Vergleichbarkeit senken, wenn jeder eine speziell für seine Maschine optimierte Version nutzte.

--- Ende Zitat ---

Möglicherweise wäre der Unterschied sogar erheblich. Dem 060 fehlen ein paar FPU-Instruktionen der 68881/2 Coprozessoren. Falls gcc auf die Idee gekommen ist, die im Code zu verwenden (unwahrscheinlich, aber nicht ausgeschlossen), muß der Prozessor über einen Illegal Instruction TRAP durch die Motorola Emulations-Library und wird richtig lahm.

Wahrscheinlich liegt die (im Vergleich zur sonstigen 060 Performance) eher niedrige Geschwindigkeit aber eher daran, daß Motorola das ganze Superskalar-Zeug nur den Integer-Befehlen angedeihen ließ. Effektiv läuft die FPU im 060 nur mit etwa einem Drittel der Geschwindigkeit vom Rest.

Ist die 060-FPU-Emulationslibrary bei Magic überhaupt vorhanden/aktiv? Vielleicht ist das ja schon der ganze Grund.

czietz:

--- Zitat von: mfro am So 24.02.2019, 11:13:03 ---Möglicherweise wäre der Unterschied sogar erheblich. Dem 060 fehlen ein paar FPU-Instruktionen der 68881/2 Coprozessoren. Falls gcc auf die Idee gekommen ist, die im Code zu verwenden (unwahrscheinlich, aber nicht ausgeschlossen), muß der Prozessor über einen Illegal Instruction TRAP durch die Motorola Emulations-Library und wird richtig lahm.

--- Ende Zitat ---

Hinweis: Das ist der Coremark-Thread. Coremark nutzt keine Floating-Point-Operationen im Benchmark-Kern. Nur zur Berechnung der Iterationen / Sekunde bei der Ausgabe, natürlich -- aber da das Binary für 68000 compiliert ist, werden diese Rechnung per Software-Floating-Point-Bibliothek erledigt.

Im LINPACK-Thread würde ich Dir hingegen recht geben.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete