Coremark für 68000

[mfro]

Was ich "regelgerecht" liefern kann, sind die Ergebnisse vom MiST im "STEroids"/68020 Modus (MiNT + 1280x960x1):

Code: [Auswählen]

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 2313
Total time (secs): 11.565000
Iterations/Sec   : 17.293558
Iterations       : 200
Compiler version : GCC4.6.4 (MiNT 20130415)
Compiler flags   : -O2 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1
Memory location  : Code and data in RAM
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x382f
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 17.293558 / GCC4.6.4 (MiNT 20130415) -O2 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1  / Code and data in RAM


[czietz]

Was passiert mit dem Coremark auf der Vampire-Karte, wenn Du ihn für 040 oder 060 compilierst?

Das wäre ein Äpfel-mit-Birnen-Vergleich, denn Sinn dieses Threads ist es ja, dass alle dasselbe Programm benutzen. Auch gibt es keinen gcc (als Crosscompiler für TOS-Binaries, jedenfalls), der den Instruktionssatz des Apollo-Cores voll ausnutzt: SIMD, etc.

Jedenfalls entspricht das Coremark-Ergebnis einem 68060 mit ca. 115 MHz Takt, laut Datenblatt (für Vampire V2) entspricht der Kern einem 68060 mit ca. 130 MHz Takt und das Ergebnis des CPU-Benchmarks von Kronos (wiederum auf der V4SA) entspricht einem 68060 mit ca. 140 MHz Takt. Die Größenordnung ist überall gleich; die Details hängen sicherlich davon ab, wie gut der Apollo-Core die Instruktionen des jeweiligen Benchmarks parallelisieren kann.

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.

Baust Du mir so eine Version? Dann mache ich das. (Aber es bleibt dabei: das sind Äpfel mit Birnen.)

[1ST1]

Das mit den Äpfeln und Birnen ist schon klar, eigentlich wäre es sogar Äpfel gegen Birnen gegen Pflaumen (68000 vs Coldfire vs 68080). Leider kann ich das nicht machen. Aber mit @Thorsten Otto haben wir doch hier jemand, der den gcc weiter entwickelt. Vielleicht muss man ja mal nur in der Amiga-Community fragen, ob die den gcc schon für 68080 entsprechend weiterentwickelt haben, und diese Änderungen als weitere Compiler-Option in die Atari-Version einbauen?

[Thorsten Otto]

"weiterentwickeln"  wäre übertrieben Aber beppo hatte schon mal was in Richtung 68080 angefangen, auf Basis von gcc 6.5 oder so, zu finden auf https://github.com/bebbo/gcc . Benutzt allerdings als  Assembler dann vasm. Ich weiss auch nicht wie einfach sich die Änderungen auf neuere Compiler-Versionen übertragen lassen.

[czietz]

ST mit Alt-RAM und 68010-CPU: 2,07 Iterations/s.
ST mit 68010-CPU (ohne Alt-RAM): 1,97 Iterations/s.

[czietz]

ST mit PAK/2 68020 @ 25 MHz: 4,03 Iterations/s.

[czietz]

TT mit 48-MHz-Beschleuniger: 19,42 Iterations/s (+40% gegenüber 13,92 vorher). Storm mit EDO-RAM, Coremark läuft im TT-RAM.

[czietz]

STE mit 32-MHz-Beschleuniger (68000 CPU): 2.575 Iterations/s (Quelle: Facebook-Post).

[czietz]

Außer Konkurrenz, weil andere Architektur, anderer Compiler und anderes OS:

Die PC-Speed mit einem NEC V30 @ 8 MHz unter MS-DOS:
CoreMark 1.0 : 0.858811 / Open Watcom Version 1.9 -0 -ms -ox / Code and data in RAM

Erheblich langsamer als der 68000er bei 8 MHz, wobei ein Teil davon auch am Compiler liegen könnte. Der m68k-gcc optimiert schon recht gut.

Da ich weiß, dass @Gaga förmlich darauf brennt, seine x86-Addons demselben Test zu unterziehen, ist auch meine 8086-Version von CoreMark angehängt.

PS: Es war gar nicht so einfach, einen C-Compiler zu finden, der Code für einen 8086 (d.h. Real-Mode und eingeschränkter Befehlssatz) unter DOS baut und der nicht aus dem letzten Jahrtausend ist.

[Thorsten Otto]

Der einzige den ich jemals benutzt habe um 16bit-code für x86 zu erzeugen war Borland-C. Dürfte mittlerweile frei erhältlich sein, wobei das andere Problem darin bestehen dürfte eine Umgebung zu bauen in der man ihn überhaupt noch ausführen kann. Andere Alternative ist vlt. Pacific-C, der zum bauen der PC-GEM version benutzt wird. Welchen hast du denn genommen?

PS.: falls zu off-topic, einfach ignorieren

[mfro]

... wobei das andere Problem darin bestehen dürfte eine Umgebung zu bauen in der man ihn überhaupt noch ausführen kann...

Borland-C lief bei mir auf Anhieb und ohne Klimmzüge in einer (Debian-) Standard-DOSEMU-Umgebung

[czietz]

Borlands Turbo C habe ich früher auch genutzt. Und tatsächlich wurde es irgendwann von Borland / Inprise / Embarcadero / Codegear / Wie-auch-immer-diese-Firma-damals-gerade-hieß offiziell freigegeben.

Aber ich habe den Watcom Compiler verwendet, da es ihn in einer Windows-Version gibt (keine DOSBox, keine Probleme mit langen Dateinamen) und da er bis ca. 2010 weiterentwickelt wurde und somit -- ohne dass ich es aber getestet hätte -- besseren Code generieren dürfte als Turbo C.

[gh-baden]

Borlands Turbo C habe ich früher auch genutzt. Und tatsächlich wurde es irgendwann von Borland / Inprise / Embarcadero / Codegear / Wie-auch-immer-diese-Firma-damals-gerade-hieß offiziell freigegeben.

Aber ich habe den Watcom Compiler verwendet, da es ihn in einer Windows-Version gibt (keine DOSBox, keine Probleme mit langen Dateinamen) und da er bis ca. 2010 weiterentwickelt wurde und somit -- ohne dass ich es aber getestet hätte -- besseren Code generieren dürfte als Turbo C.

Ohoh, ich höre die Aufrufe nach einem Compilerexplorer a la Matt Godbolt, für Retro-Compiler …

[czietz]

TT mit verbessertem 48-MHz-Beschleuniger: 21,2 Iterations/s (+50% gegenüber einem Standard-TT mit 13,92 It/s.). Storm mit EDO-RAM, Coremark läuft im TT-RAM.

[Arthur]

TT mit verbessertem 48-MHz-Beschleuniger: 21,2 Iterations/s (+50% gegenüber einem Standard-TT mit 13,92 It/s.). Storm mit EDO-RAM, Coremark läuft im TT-RAM.

+50% ?

[czietz]

TT mit verbessertem 48-MHz-Beschleuniger: 21,2 Iterations/s (+50% gegenüber einem Standard-TT mit 13,92 It/s.). Storm mit EDO-RAM, Coremark läuft im TT-RAM.

+50% ?

Ja, ca. +50%. 21,2 / 13,92 = 1,52.

[Arthur]

Entspricht ziemlich genau der Taktdifferenz, oder?

[czietz]

Entspricht ziemlich genau der Taktdifferenz, oder?

Ja, was an sich eine beeindruckende Leistung ist.

Oftmals skalieren die Werte bei Beschleunigern nämlich nicht mit der Taktfrequenz. Siehe weiter oben in diesem Thread den STE mit 32 MHz (vierfacher Takt), der auf 2,575 Iterations/s (statt auf 1,92 It/s für einen Standard-STE) kommt.

[Arthur]

Entspricht ziemlich genau der Taktdifferenz, oder?

Ja, was an sich eine beeindruckende Leistung ist.

Oftmals skalieren die Werte bei Beschleunigern nämlich nicht mit der Taktfrequenz. Siehe weiter oben in diesem Thread den STE mit 32 MHz (vierfacher Takt), der auf 2,575 Iterations/s (statt auf 1,92 It/s für einen Standard-STE) kommt.

Da stimme ich dir voll zu.

[czietz]

Atari Falcon:
68030 @ 16 MHz (Standardkonfiguration), Videomodus 16 Farben: 6,35 It/s (vgl. auch Post #50)
68030 @ 8 MHz, Videomodus 16 Farben: 3,17 It/s
68030 @ 16 MHz, Videomodus Truecolor: 5,38 It/s.

Man sieht sehr schön, wie sich CPU und Videl die Speicherbandbreite teilen müssen.