Coremark für 68000

[Ektus]

Auf dem Milan 040 mit MagiC, Ausführung im VT52: Crash.
Ohne Auto-Ordner, ohne FPU-Emulation: Total ticks 3568, Total Time 17,84s, 33,63 Iterations/s.

Nach Start von FPU__2M.PRG: Werte praktisch unverändert (3567, 17,83499, 33,64)


MfG
Ektus.

[czietz]

Auf dem Milan 040 mit MagiC, Ausführung im VT52: Crash.

Siehe meine Fragen in https://forum.atari-home.de/index.php/topic,15024.msg237402.html#msg237402.

Ohne Auto-Ordner, ohne FPU-Emulation: Total ticks 3568, Total Time 17,84s, 33,63 Iterations/s.
Nach Start von FPU__2M.PRG: Werte praktisch unverändert (3567, 17,83499, 33,64)

Was kein Wunder ist, Coremark nutzt keine FPU.

[1ST1]

Langsam wäre mal eine strukturierte Tabelle für all die Ergebnisse beider Benchmarks interesant, vielleicht auch mit Vergleichen aus der Intel/ARM/PPC-Welt, um die Ergebisse einzunorden.

[ari.tao]

^^-- Ja, mach mal.

[Ektus]

CT2A unter MagiC, gestartet aus Konsole von Gemini: Absturz mit "Speicherblock durch Benutzerprogramm zerstört" nach der Zeile "(s)COREMARK.TOS 0x0 0x0 0x66 0 7 1 2000"

Daten des MCB: $004E442 $00008A78 $00000000 $003B85F4

Kannst Du bitte COREMARK.TOS mal direkt aus der Gemini-Konsole starten, einmal ohne Parameter und einmal mit den o.g. Parametern, d.h.
COREMARK.TOS 0x0 0x0 0x66 0 7 1 2000

Gibt es den gleichen Fehler?

Auf dem Milan,unter MagiC, Start ohne Parameter und Ausführung im VT52: Kein crash, 32,33 Iterations/s.

Mupfel in VT52, Start mit Parametern: Kein Crash, 32,19 Iterations/s.

Mupfel in VT52, Start von !runme.tos: Kein Crash, 32,18 Iterations/s.

Start von !runme.tos per Doppelclick aus Jinnee: crash.
Daten des MCB: $004E4452 $000069B0 $00000000 $003FD964

Mit freundlichem Gruß aus Bubenreuth
Ektus.

[czietz]

Gemulator mit EmuTOS auf aktuellem Windows-PC: 861 Iterations/Sekunde.

[czietz]

Auf dem Milan,unter MagiC, Start ohne Parameter und Ausführung im VT52: Kein crash, 32,33 Iterations/s.
Mupfel in VT52, Start mit Parametern: Kein Crash, 32,19 Iterations/s.
Mupfel in VT52, Start von !runme.tos: Kein Crash, 32,18 Iterations/s.
Start von !runme.tos per Doppelclick aus Jinnee: crash.

Sorry, so richtig ist mir immer noch nicht klar, wann es bei Dir läuft und wann es abstürzt. Weiter oben schriebst Du ja noch "Auf dem Milan 040 mit MagiC, Ausführung im VT52: Crash." Gilt das also nur beim Start von Jinnee aus? Was passiert, wenn Du COREMARK.TOS per Doppelclick aus Jinnee startest?

Jedenfalls kann ich das nicht nachvollziehen: unter Hataris 68040-Emulation, mit MagiC 6.2 und (Demoversion von) Jinnee stürzt nichts ab. Und Fehler, die ich nicht nachvollziehen kann, kann ich auch nicht beheben.

[Nervengift]

Ich habe auf meinem Milan040 (25 MHz/48 MB RAM) auch mal ein wenig rumprobiert mit Coremark. Hier meine Ergebnisse:

MiNT 1.19.x/XaAES/Thing 1.29: Per Doppelklick klappt's vom Desktop aus nicht. Ruft man in TOSWIN2 runme.tos auf passiert nichts. Ruft man stattdessen coremark.tos auf und übergibt die Parameter aus der Batch-Datei manuell, dann geht's. Allerdings produziert das Programm dann meistens eine Fehlermeldung. (Siehe angehängten Screenshot)

MiNT 1.18.0/MyAES 0.97/Teradesk 4.08: Ausführen von runme.tos per Doppelklick vom Desktop aus klappt ohne Probleme. Allerdings kommt es beim Ausführen des Programms meistens zu dem 10 Sekunden Fehler. (Siehe Screenshots)

MiNT 1.18.0/N.AES 2.0/Thing 1.29: Läuft ohne Probleme und ohne Fehlermeldungen! (Siehe Screenshot)

Cripple MiNT 1.15.x/AES 4.1/Newdesk: Ausführung ist kein Problem aber es kommt IMMER zum 10 Sekunden Fehler. (Siehe Screenshot)

Magic Milan 6.1/Jinnee 2.5/VT 52: Auch hier ist das Ausführen kein Problem. Keine Crashs. Nur kommt es auch unter Magic oft zum 10 Sekunden Fehler. (Siehe Screenshots)

Die Interpretation der Messwerte überlasse ich mal lieber geschultem Personal. Leider sagen die mir rein gar nichts. Vielleicht helfen sie ja auch @czietz weiter?

[Ektus]

Auf dem Milan,unter MagiC, Start ohne Parameter und Ausführung im VT52: Kein crash, 32,33 Iterations/s.
Mupfel in VT52, Start mit Parametern: Kein Crash, 32,19 Iterations/s.
Mupfel in VT52, Start von !runme.tos: Kein Crash, 32,18 Iterations/s.
Start von !runme.tos per Doppelclick aus Jinnee: crash.

Sorry, so richtig ist mir immer noch nicht klar, wann es bei Dir läuft und wann es abstürzt. Weiter oben schriebst Du ja noch "Auf dem Milan 040 mit MagiC, Ausführung im VT52: Crash." Gilt das also nur beim Start von Jinnee aus? Was passiert, wenn Du COREMARK.TOS per Doppelclick aus Jinnee startest?

Jedenfalls kann ich das nicht nachvollziehen: unter Hataris 68040-Emulation, mit MagiC 6.2 und (Demoversion von) Jinnee stürzt nichts ab. Und Fehler, die ich nicht nachvollziehen kann, kann ich auch nicht beheben.

Crash passiert dann, wenn ich !runme.tos unter MagiC 6.2 per Doppelclick vom Desktop starte. Die Ausgaben landen dann in VT52 (wenn der Desktop Jinnee ist) oder der Konsole von Gemini.

Das gilt auf dem Milan und dem CT2A Falcon. Auf der CT63 läuft es seltsamerweise, wobei da die Ausgaben im VT52 landen, obwohl Gemini der Desktop ist. Wahrscheinlich in der magx.inf so konfiguriert.

Total time 13.960s, 214,899719 Iterations/s, 3000 Iterations (CT63 mit CTPCI, CPU bei 95MHz).
Total time 12.915s, 232,288040 Iterations/s, 3000 Iterations (CT63 mit CTPCI, CPU bei 105MHz).

Mit freundlichem Gruß aus Ahornberg
Ektus.

[czietz]

Allerdings produziert das Programm dann meistens eine Fehlermeldung. (Siehe angehängten Screenshot)

Wie schon einmal erwähnt, ist testen unter einem Multitasking-OS immer problematisch. Coremark testet zunächst eine Sekunde lang, um die Geschwindigkeit des Systems einzuschätzen und die Anzahl der Testdurchläufe für einen 10-Sekunden-Test festzulegen. Wenn in der ersten Sekunde aber ein OS "dazwischengrätscht", schätzt Coremark das System initial zu langsam ein und rechnet zu wenige Iterationen aus.

Du kannst mit dem vierten Parameter (COREMARK.TOS 0x0 0x0 0x66 0 7 1 2000) eine Anzahl von Iterationen vorgeben, z.B. 400; aber generell würde ich immer unter TOS testen.

[ama]

Standard Falcon030

• in ST-High: 6,49 Iterations/s
• in 256c:     5.12 Iterations/s

[czietz]

ST mit 68020-Beschleuiniger @ 32 MHz: 4,80 Iterations/s

[Atariosimus]

MegaSTE @ 8 Mhz: 1.448225 Iterations/Sec (Super TOS UK)
MegaSTE @ 8 Mhz: 1.448750 Iterations/Sec (Tos 2.06 DE)
MegaSTE @ 16 Mhz: 3.165809 Iterations/Sec (Tos 2.06 DE, Cache an)
MegaSTE @ 16 Mhz: 1.633986 Iterations/Sec (Tos 2.06 DE, Cache aus)

[Lukas Frank]

ST mit 68020/16Mhz (PAK68/2): 4,016064 Iterations/Sec

[czietz]

Vampire V4 Standalone (unter EmuTOS, "pre-release" Core): 247,8 Iterations/Sec

@Johannes: Leider kann ich das Posting #1 in dem Thread nicht mehr editieren. Bislang hatte ich alle Ergebnisse dort gesammelt.

[mfro]

Vampire V4 Standalone (unter EmuTOS, "pre-release" Core): 247,8 Iterations/Sec

Interessant. Sicher, dass das so stimmt?

Das würde ja bedeuten, dass Vampire - im Gegensatz zu den Aussagen, die man anderswo schon lesen konnte - nicht deutlich schneller als die Firebee, sondern im Gegenteil deutlich langsamer wäre?

[czietz]

Das würde ja bedeuten, dass Vampire - im Gegensatz zu den Aussagen, die man anderswo schon lesen konnte - nicht deutlich schneller als die Firebee, sondern im Gegenteil deutlich langsamer wäre?

Darf ich Dich daran erinnern, dass die Zahl, die Du mir für die Firebee genannt hast, nicht mit den übrigen Zahlen vergleichbar ist!? Du hast bekanntermaßen Coremark für Coldfire optimiert neu compiliert, womit die Firebee einen unfairen Vorteil bekommt. Ich habe mit der 68000-Version (ohne Optimierung für die Vampire) getestet.

[czietz]

Davon abgesehen passt der Wert imho ganz gut zu den offiziellen Benchmark-Resultaten (auf einem Amiga), die die Apollo-Core-Entwickler veröffentlichen: https://www.apollo-accelerators.com/files/Apollo_datasheet.pdf

Nach ihrem Benchmark ist der Apollo-Core (in der Vampire V2) etwa doppelt so schnell wie ein 68060 bei 66 MHz. Nun haben wir in diesem Thread kein Coremark-Resultat für 68060 exakt für 66 MHz, aber die Größenordnung passt, verglichen mit z.B. amas Ergebnissen.

[mfro]

Das würde ja bedeuten, dass Vampire - im Gegensatz zu den Aussagen, die man anderswo schon lesen konnte - nicht deutlich schneller als die Firebee, sondern im Gegenteil deutlich langsamer wäre?

Darf ich Dich daran erinnern, dass die Zahl, die Du mir für die Firebee genannt hast, nicht mit den übrigen Zahlen vergleichbar ist!? Du hast bekanntermaßen Coremark für Coldfire optimiert neu compiliert, womit die Firebee einen unfairen Vorteil bekommt. Ich habe mit der 68000-Version (ohne Optimierung für die Vampire) getestet.

Das ist mir wohl bekannt.

Ich habe mit demselben Compiler Code für einen anderen Prozessor erzeugt (nicht "optimiert" - zumindest nicht anders als für den 68000er) - anders geht das bei mir halt nicht, weil ich kein Firetos mit cf68klib (mehr) benutze.
Was passiert mit dem Coremark auf der Vampire-Karte, wenn Du ihn für 040 oder 060 compilierst?

[1ST1]

Wenn schon die Coldfire-Version vom Coremark gegen Vampire antritt, dann bitte für Vampire eine Version kompilieren, die die speziellen 080 Features (Pipeline, AMMX, etc.) nutzt! Neue Coldfire-Befehle sollen ja (zumindestens teilweise?) auch im 080 unterstützt werden.