LINPACK-Benchmark für 68030 + FPU

[Thorsten Otto]

Nicht übel. Gemulator hat soviel ich weiss keinen JIT-Compiler, oder?

[Ektus]

CT63@95MHz unter MiNT:

Code: [Auswählen]

LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
       4   0.78  89.81%   3.18%   7.01%   7525.114
       8   1.57  90.10%   2.56%   7.35%   7577.011
      16   3.13  89.78%   2.56%   7.67%   7603.230
      32   6.25  89.76%   2.48%   7.76%   7623.012
      64  12.51  89.85%   2.72%   7.43%   7590.098


[czietz]

Vampire V4 Standalone (unter EmuTOS, "pre-release" Core): 10912 kFLOPS.

[1ST1]

Ich kann Ektus seine Werte mit einer 060 mit 95 Mhz (Falcon im 640x480 VGA-Modus unter normalem TOS) etwa bestätigen.

7373,602
7398,429
7435,984
7429,699
7429,699

[Thorsten Otto]

Ohne jetzt genau zu wissen welche floating-instructionen linpack tatsächlich benutzt, wäre es doch vlt mal angebracht das mit einer 060 Version zu testen, sonst kann der Vergleich ganz schön hinken wenn die Hälfte der Befehle erstmal ne exception auslöst. Die Coldfire Version wurde ja auch entsprechend übersetzt.

[czietz]

LINPACK löst, wie der Name schon sagt, lineare Gleichungssysteme. Genauer gesagt während des Benchmarks mithilfe einer LR-Zerlegung durch den Gaußalgorithmus mit Pivotisierung (dgefa) mit anschließendem Vorwärtseinsetzen (dgesl): https://de.wikipedia.org/wiki/Gau%C3%9Fsches_Eliminationsverfahren#LR-Zerlegung.

Das beschränkt sich auf die vier Grundrechenarten. Es kommen im Code keine transzendenten Funktionen vor, die für die FPU des 68060 aufwändig emuliert werden müssten. Insofern ist Deine Annahme, dass "die Hälfte der Befehle erstmal ne exception auslöst" hier falsch.

[Thorsten Otto]

Ah ok, wie gesagt, ich hatte nicht nachgeschaut was linpack macht, insofern war das nicht mal ne Annahme, sondern eher Spekulation.

Trotzdem wäre es vlt. mal interessant zu wissen, ob eine für 060 kompilierte Version hier spürbare Unterschiede bringt (kann ja dann als solche markiert werden).

[czietz]

Trotzdem wäre es vlt. mal interessant zu wissen, ob eine für 060 kompilierte Version hier spürbare Unterschiede bringt (kann ja dann als solche markiert werden).

Ich bin diese Tage nicht an meinem Entwicklungsrechner. Also entweder irgendwann später -- oder jemand anders compiliert's. Link zum Quelltext ist in Posting #1 angegeben.

[mfro]

bitteschön.

Ich konnte das nur mit Aranym testen (das das 060er Binary lustigerweise ausführen kann). Das ist tatsächlich auch nahezu 30% schneller.

[Thorsten Otto]

Überraschend ist das eigentlich nicht, weil ja beim 060 lediglich ein paar Instruktionen wegfallen, die dann gar nicht benutzt werden wenn du es für 060 kompilierst.

Trotzdem ist Aranym als Vergleich da eher nicht so geeignet, weil a) auch die weggefallenen Instruktionen trotzdem emuliert würden und b) egal ob 040 oder 060, ja immer der Host eigentlich die FPU instruktionen ausführt.

Hatari für 060 würde gehen, aber ich denke da ist ab 030 die CPU-Emulation noch nicht wirklich cycle-exact. Spätetens bei 060 mit parallel execution dürfte das auch horrende aufwendig sein.

[1ST1]

AUf meinem Falcon 060 laufen beide neue Programme endlos, ohne ein Ergebnis auszuspucken. Die Version von oben ist relativ zügig durch.

[czietz]

Ich kann mich dunkel daran erinnern, dass ich bei diesem Benchmark irgendwelche Probleme mit libcmini hatte, weshalb meine Version mit MiNTlib gebaut ist. Bei den Versionen von @mfro ist das evtl. schon das Problem?

[1ST1]

Wenn die mit unterschiedlichen Libs gebaut werden, hat das vielleicht auch einen Einfluss auf das Ergebnis des Benchmarks?

[mfro]

AUf meinem Falcon 060 laufen beide neue Programme endlos, ohne ein Ergebnis auszuspucken. Die Version von oben ist relativ zügig durch.

Spassig. Ich habe nach dem Compilieren erst mal mit Hatari getestet und dabei genau dasselbe festgestellt.

Dann noch mal mir Aranym probiert und da hat's problemlos funktioniert - für mich war dann klar, dass das an Hatari lag und natürlich nicht an libcmini

Ich werd's mir heue abend noch mal anschauen. Sorry.

[mfro]

... klar, dass das nicht an Hatari lag und natürlich an libcmini

Da rechnet nix, das Programm hängt in der Eingaberoutine fest.

Die macht nämlich kein gets() oder scanf(), sondern ein

Code: [Auswählen]

fread(xxx, xxx, stdin);


und sucht dann nach einem Line Feed für das Zeilenende in der Eingabe. Dummerweise kommt aber von der VT52-Konsole nur ein Carriage Return, das heisst, die Eingabe wird nicht akzeptiert.

Da muss in libcmini noch was passieren, damit es diese  Situation beherrscht. Bis dahin müsste anstatt 'Enter' auch CNTRL-J gehen. Trotzdem hier die beiden Dateien mit der mintlib compiliert.

[1ST1]

030

8078,431
8019,465
8063,609
8071,214

060

7961,353
8048.840
8034,126
8019,465
8037,799

Übrigens, wenn man mehrere Durchläufe macht, schanken die Ergebnisse so um die +/- 50 um diese Angaben.

[Thorsten Otto]

Das liegt u.a. an der Auflösung des timers (200Hz). Wenn du z.B. den Startwert holst, kann es sein daß er sich eine Nanosekunde später ändert, oder aber er hat sich  gerade erst geändert und ändert sich dann erst wieder 5ms später. Genauer geht's halt nicht. Sprich auf weniger als 5ms genau lässt sich die Laufzeit eines Programms kaum bestimmen. Das würde höchstens gehen wenn man z.B. einen der nicht benutzten MFP timer selber programmiert. Was aber auch wieder das Ergebnis verfälschen würde, weil dann ein nicht unerheblicher Teil der Rechenzeit im Timer-Interrupt verbracht wird.

[czietz]

Ich finde, die Ergebnisse von @1ST1 zeigen gut, dass LINPACK im Wesentlichen keine speziellen, auf dem 68060 zu emulierenden FPU-Operationen nutzt.

[Thorsten Otto]

Ja, wäre auch seltsam wenn da nur basis-operationen benutzt werden. Ich kann bei den zuletzt geposteten binaries auf Aranym auch keine wesentlichen Unterschiede feststellen:

Code: [Auswählen]

030:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
      64   0.73  87.67%   2.74%   9.59%  133171.717
     128   1.45  92.41%   0.00%   7.59%  131184.080
     256   2.92  90.41%   1.71%   7.88%  130696.406
     512   5.78  90.48%   2.77%   6.75%  130453.927
    1024  11.64  90.72%   2.66%   6.62%  129373.812

060:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
      64   0.73  87.67%   4.11%   8.22%  131184.080
     128   1.47  91.84%   2.72%   5.44%  126465.228
     256   2.92  89.04%   3.08%   7.88%  130696.406
     512   5.78  90.31%   2.42%   7.27%  131184.080
    1024  11.64  90.03%   3.09%   6.87%  129731.857


[mfro]

Was man m.E. hier im wesentlichen sieht (abgesehen davon, dass der TOP500-führende etwa 18 Millionen mal schneller ist  ), ist, dass die gcc-Optimierung für den 060er (zumindest beim linpack) keine Wunder bewirkt (natürlich vorausgesetzt, die Maschine, mit der der '000 Code lief, ist einigermassen vergleichbar).