Autor Thema: LINPACK-Benchmark für 68030 + FPU  (Gelesen 2835 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 600
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #40 am: Sa 02.03.2019, 01:19:29 »
Nicht übel. Gemulator hat soviel ich weiss keinen JIT-Compiler, oder?

Offline Ektus

  • Benutzer
  • Beiträge: 803
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #41 am: Sa 02.03.2019, 06:36:24 »
CT63@95MHz unter MiNT:

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

Offline czietz

  • Benutzer
  • Beiträge: 2.175
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #42 am: So 01.09.2019, 10:20:10 »
Vampire V4 Standalone (unter EmuTOS, "pre-release" Core): 10912 kFLOPS.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.630
  • Sehr langer Urlaub.
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #43 am: So 01.09.2019, 20:06:19 »
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
Meine Beiträge waren immer "IMHO". Der Urlaub wird deutlich verlängert. Ich KANN wieder schreiben, aber ob ich das noch WILL?

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 600
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #44 am: Mo 02.09.2019, 06:56:16 »
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.

Offline czietz

  • Benutzer
  • Beiträge: 2.175
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #45 am: Mo 02.09.2019, 08:04:16 »
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.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 600
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #46 am: Mo 02.09.2019, 17:13:17 »
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).

Offline czietz

  • Benutzer
  • Beiträge: 2.175
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #47 am: Mo 02.09.2019, 19:27:44 »
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.

Offline mfro

  • Benutzer
  • Beiträge: 1.343
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #48 am: Mo 02.09.2019, 20:17:44 »
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.

And remember: Beethoven wrote his first symphony in C

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 600
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #49 am: Mo 02.09.2019, 20:39:14 »
Ü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.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.630
  • Sehr langer Urlaub.
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #50 am: Mo 02.09.2019, 20:48:42 »
AUf meinem Falcon 060 laufen beide neue Programme endlos, ohne ein Ergebnis auszuspucken. Die Version von oben ist relativ zügig durch.
Meine Beiträge waren immer "IMHO". Der Urlaub wird deutlich verlängert. Ich KANN wieder schreiben, aber ob ich das noch WILL?

Offline czietz

  • Benutzer
  • Beiträge: 2.175
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #51 am: Di 03.09.2019, 10:39:35 »
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?

Offline 1ST1

  • Benutzer
  • Beiträge: 8.630
  • Sehr langer Urlaub.
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #52 am: Di 03.09.2019, 11:56:43 »
Wenn die mit unterschiedlichen Libs gebaut werden, hat das vielleicht auch einen Einfluss auf das Ergebnis des Benchmarks?
Meine Beiträge waren immer "IMHO". Der Urlaub wird deutlich verlängert. Ich KANN wieder schreiben, aber ob ich das noch WILL?

Offline mfro

  • Benutzer
  • Beiträge: 1.343
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #53 am: Di 03.09.2019, 13:18:41 »
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.
« Letzte Änderung: Di 03.09.2019, 13:24:03 von mfro »
And remember: Beethoven wrote his first symphony in C

Offline mfro

  • Benutzer
  • Beiträge: 1.343
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #54 am: Di 03.09.2019, 18:35:37 »
... 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

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.

And remember: Beethoven wrote his first symphony in C

Offline 1ST1

  • Benutzer
  • Beiträge: 8.630
  • Sehr langer Urlaub.
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #55 am: Di 03.09.2019, 19:58:02 »
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.
Meine Beiträge waren immer "IMHO". Der Urlaub wird deutlich verlängert. Ich KANN wieder schreiben, aber ob ich das noch WILL?

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 600
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #56 am: Di 03.09.2019, 21:23:26 »
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.


Offline czietz

  • Benutzer
  • Beiträge: 2.175
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #57 am: Di 03.09.2019, 21:35:32 »
Ich finde, die Ergebnisse von @1ST1 zeigen gut, dass LINPACK im Wesentlichen keine speziellen, auf dem 68060 zu emulierenden FPU-Operationen nutzt.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 600
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #58 am: Mi 04.09.2019, 01:33:31 »
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:

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

Offline mfro

  • Benutzer
  • Beiträge: 1.343
Re: LINPACK-Benchmark für 68030 + FPU
« Antwort #59 am: Mi 04.09.2019, 06:58:33 »
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).


 
« Letzte Änderung: Mi 04.09.2019, 07:03:16 von mfro »
And remember: Beethoven wrote his first symphony in C