LINPACK-Benchmark für 68030 + FPU

[Thorsten Otto]

Wenn mir jemand den aktuellen GNU Fortran Compiler für TOS geben kann, teste ich auch das Fortran-Original.

Habs gerade mal unter linux probiert und bekomme:

Code: [Auswählen]

linpack-1000d.f:96:25:

             a(i,j) = ran(init) - .5
                         1
Error: ‘i’ argument of ‘ran’ intrinsic at (1) must be a scalar

(schon mit dem Native-Compiler). Da ich keine Ahnung von Fortran habe, kann ich nicht sagen was da falsch läuft, evtl. Unterschiede zwischen fortran-77/fortran-95?

Ansonsten kann ich dir höchstens einen cross-compiler anbieten.

[Thorsten Otto]

Update: gerade mal versucht andere Programme zu übersetzen. Kompilieren geht, aber beim linken kommt dann:

Code: [Auswählen]

undefined reference to `_gfortran_st_write_done'
undefined reference to `_gfortran_st_write'
undefined reference to `_gfortran_transfer_real_write'
...

Scheint da fehlt noch was an support.

Edit: hat sich erledigt. Beim linken muss man da wohl tatsächlich gfortran nehmen, nicht gcc, ähnlich wie beim c++ Frontend, damit er die fortran runtime library mit linkt.

[czietz]

RAN ist eine eingebaute Funktion in GNU Fortran: https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gfortran/RAN.html#RAN. Der Quelltext will aber die eigene RAN-Funktion aufrufen. Workaround: Umbenennung, wie im Anhang. Auf einem Atari wird eine 1000x1000-Matrix einiges an Lösungszeit benötigen.

[Thorsten Otto]

Ok, das krieg ich unter linux übersetzt, und läuft auch. Wenn ich das allerdings mit dem cross-compiler übersetze und starte, bekomme ich:

Code: [Auswählen]

Fortran runtime error: End of record

Noch irgendwelche Ideen?

[Lukas Frank]

Atari Mega ST4 / PAK68/3 mit 68882/50Mhz / FRAK/2 64MB Fastram


406.914 KFLOPS

[czietz]

Noch irgendwelche Ideen?

Sorry, ich kann gerade genug Fortran, um Programme zu compilieren oder einfache Subroutinen zu verstehen. Mit der Laufzeitbibliothek kenne ich mich nicht aus. Funktioniert denn ein "Hallo World" mit dem Crosscompiler? Falls Du kleine Programme zum Testen brauchst: http://rosettacode.org/wiki/Category:Fortran

[Thorsten Otto]

Funktioniert denn ein "Hallo World" mit dem Crosscompiler?

Nein, gibt den gleichen Laufzeitfehler. Da scheint noch irgendwas im argen zu sein mit der Runtime-Bibliothek. Möglicherweise ist es nicht vorgesehen, die mit einem cross-compiler zu erzeugen.

[ari.tao]

Mit Prospero-F77 auf dem Atari keine Chance?

-------

Mit welchem Editor kriegt man denn die richtige Formatierung wieder hin in 1000d.f.txt ?
Ist ja nicht ganz unwichtig in Fortran.

[KarlMüller]

Milan060 unter TOS:

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                                       
----------------------------------------------------                                     
       2   0.72  89.58%   2.78%   8.33%   4161.616                                       
       4   1.45  89.27%   2.77%   7.96%   4130.326                                       
       8   2.89  88.93%   2.77%   8.30%   4145.912                                       
      16   5.55  89.18%   2.51%   8.31%   4149.827                                       
      32  11.55  89.26%   2.55%   8.18%   4143.957                                       

Mit MagiC sinkt die Leistung auf ca. 3700 KFLOPS

Mit -O3 kommen noch mal ungefähr 100 KFLOPS obendrauf.

Also wenn der Benchmark Compiler abhängig ist, dann ist das Ergebnis nicht unbedingt aussagekräftig.

In wieweit fragt der Benchmark den Typ der FPU ab?

[czietz]

Also wenn der Benchmark Compiler abhängig ist, dann ist das Ergebnis nicht unbedingt aussagekräftig.

Jeder Benchmark ist naturgemäß compiler-abhängig. Irgendwo im Forum findest Du Resultate, in denen ich verschiedene Compiler (PureC, gcc 4, gcc 8) mittels Coremark verglichen habe. Deshalb soll ja nicht jeder den Quellcode selbst compilieren, sondern alle sollen das existierende Binary verwenden.

In wieweit fragt der Benchmark den Typ der FPU ab?

Das Binary in #1 ist für 68030 + 68881/68882 compiliert. Es darf Instruktionen nutzen, die auf dem 68060 emuliert werden müssen, falls Du das fragen wolltest.

[KarlMüller]

Das Binary in #1 ist für 68030 + 68881/68882 compiliert. Es darf Instruktionen nutzen, die auf dem 68060 emuliert werden müssen, falls Du das fragen wolltest.

Ne, das war nicht meine Frage, aber Du hast sie mit 68030 + 68881/68882 beantwortet. Mir ist beim Testen mal wieder eingefallen das das MilanTOS im FPU-Cookie ein 040 zurück gibt auch, wenn eine 060 installiert ist.

[mfro]

Also wenn der Benchmark Compiler abhängig ist, dann ist das Ergebnis nicht unbedingt aussagekräftig.

Das stimmt, liegt aber in der Natur der Sache. Der Linpack-Benchmark ist die Basis für die TOP500-Liste und da sind kaum zwei Systeme drin, auf denen er unverändert laufen könnte.

Der ist dafür gedacht, daß er für jedes System individuell compiliert werden kann (und muß). Das Ergebnis ist dann halt nur für die Kombination aus Hardware + Compiler + Laufzeitumgebung gültig.

[Ektus]

Neuer Test auf dem CT2A Falcon, diesmal mit "nacktem" System (Reines TOS, keine AUTO-Ordner Programm, Standartdauflösung):

Code: [Auswählen]

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS                                       
----------------------------------------------------
       4  14.25  90.18%   2.74%   7.09%    414.904


[KarlMüller]

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

Es gibt für den Milan ein leicht angepasste Version des FPU-Emulators, wie er auch im Hades zur Anwendung kommt.

fpu_2m.prg

[Ektus]

Nächster Test auf dem Milan040, mit MagiC und Allem:

Code: [Auswählen]

Enter array size (q to quit) [200]:
Memory required:  315K.


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 
----------------------------------------------------
       1   0.88  87.57%   2.26%  10.17%   1727.463
       2   1.81  88.09%   2.49%   9.42%   1679.918
       4   3.57  87.94%   2.38%   9.68%   1706.004
       8   7.16  87.93%   2.72%   9.35%   1691.558
      16  14.32  87.92%   2.62%   9.46%   1694.819

Ohne AUTO-Ordner: 1795, 1807, 1789, 1793, 1794

MfG
Ektus.

[ari.tao]

LinPack ist offensichtlich so gemacht, daß es auch "in realer Umgebung" mißt. Will man tatsächlich NumberCrunching betreiben, dann kann man für die Dauer der Aktion sicherlich auf eine MultiTasking-Umgebung verzichten.
Will mir niemand meine Fragen beantworten?

Mit Prospero-F77 auf dem Atari keine Chance?
-------
Mit welchem Editor kriegt man denn die richtige Formatierung wieder hin in 1000d.f.txt ?
Ist ja nicht ganz unwichtig in Fortran.

[Thorsten Otto]

Möglicherweise ist es nicht vorgesehen, die mit einem cross-compiler zu erzeugen.

--> mache mal nen neuen Thread dafür auf

[ari.tao]

Habe mal versucht, die Formatierung im Quelltext von #22 wiederherzustellen -> Anhang. Könnte aber sein, daß er noch drei Fehler enthält...
Leider kriege ich von meinem Prospero-F77 nur die Shell in Gang, der Compiler verweigert in beiden Maschinen und unter allen Umgebungen die Arbeit mit der Meldung "Can´t execute profor1.ovl" und unter MAGX stürzt das Teil sogar mit ´zerstörtem Speicherblock´ ab.

[Thorsten Otto]

Habe mal versucht, die Formatierung im Quelltext von #22 wiederherzustellen

Für gfortran musste ich da nix wiederherstellen. Ist halt kein Fortran 95, also einfach Datei-Endung .f lassen und gut ist.

[czietz]

Gemulator (68030+FPU-Emulation) mit EmuTOS auf aktuellem Windows-PC: 15160 kFLOPS.