atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: czietz am Do 21.02.2019, 22:24:19
-
Und für Euch FPU-Übertakter hier der LINPACK-Benchmark, der seit jeher für die Bewertung von Fließkommarechenleistung verwendet wird. Damit könnt Ihr sehen, wo Euer Atari in der Supercomputer-Liste so stehen würde. ;)
Braucht 68030 und 68881/68882 FPU. Nach dem Start einfach Enter drücken.
Mein TT mit 68882: 217 KiloFLOPS. (Platz 1 der Supercomputer hat übrigens PetaFLOPS.)
Sammlung der Ergebnisse mit atari-kompatibler Hardware in diesem Thread. In Klammern jeweils, wer sie beigetragen hat und die Nummer des Posts für weitere Details.
- Fpu @48mhz: 285.072 kFLOPS (tuxie, #13)
- CT2A Falcon (unter TOS): 414.9 KFLOPS (Ektus, #32)
- Firebee: 14679 kFLOPS (mfro, #19, Hinweis: Benchmark compiliert für Coldfire, nicht das Programm aus diesem Post)
- Atari Mega ST4 / PAK68/3 mit 68882/50Mhz / FRAK/2 64MB Fastram: 406.914 KFLOPS (Lukas Frank, #24)
- Milan060 unter TOS: 4143.957 kFLOPS (KarlMüller, #28)
- Milan040, mit MagiC und Allem: 1694.819 kFLOPS (Ektus, #34)
- CT63@95MHz unter MiNT: 7590.098 kFLOPS (Ektus, #41)
Link zum Sourcecode: http://www.netlib.org/benchmark/linpackc.new
-
Rabäh! Warum habe ich nur 135?!
-
Steht der FPU-Takt-Jumper W101 in Deinem TT vielleicht auf 16 MHz?
EDIT: Centbench bestimmt FPU-(und CPU-)Takt: http://centek.online.fr/atari/softs/s_centbe.htm
-
Laut Centurbo 32MHz.
Vorhin 135 unter MAGX,
jetzt 147 unter MiNT.
Muß man für LinPack auch auf kleine Auflösung gehen?
-
Auflösung sollte egal sein. Aber ich habe unter TOS getestet. Wenn ständig ein Multitasking-OS dazwischenfunkt, bremst das evtl. den Benchmark. Weiterhin war die Storm inkl. EDO-RAM installiert und die PRGFLAGS von LINPACK.TOS sind derart, dass es im Fast-RAM läuft. Auch ist ein 68881 meines Wissens langsamer als ein 68882. Welche FPU hast Du?
-
Lt. SysInfo5 eine 68882.
Werde jetzt mal unter TOS testen.
-
Unter SoloMiNT: 165.
Unter TOS_3.06: 167
Unter TOS_4.04 (F32 mit ST-Hi, FPU 40MHz): 166
Edit.:
Die restliche Differenz zu 217 dürfte nun durch die höhere Taktung der FPU erklärlich sein.
Für den Falcon habe ich eine Anleitung zum Umbau. Wie taktet man die FPU im TT höher?
-
Der Atari TT hat einen Clock Jumper für die FPU mit drei Pins. Jeweils aussen liegen 16 oder 32Mhz und in der Mitte der FPU ist der Clock Eingang der FPU. Also dort den neuen Takt einspeisen. Den neuen Quarz irgendwo (über ein 14poliges IC ?) einlöten und kabel zum Jumper Pin in der Mitte verlegen.
-
Danke.
Werde ich bei Gelegenheit mal 50MHz reintun.
Die Abwärme dürfte ja im TT nicht so kritisch sein wie im Falcon, wo die FPU in der WärmeFalle unter der PSU sitzt.
-
Warum denken alle das durchs höher Takten wesentlich mehr Wärme entsteht? Die Mehrwärme kann man gerade bei der FPU vernachlässigen. Meine mit 48Mhz wird gerade Handwarm. Selbst meine 54Mhz wird zwar Wärmer aber der Unterschied zu 32Mhz ist unwesentlich mehr. Es würde eine rolle Spielen wenn man eine höhere Spannung anlegt so wie es beim PC Overclocking gemacht wird.
-
Auf 167 KiloFLOPS komme ich in meinem TT (FPU @ 32 MHz) nur, wenn ich die Storm deaktiviere. Das ist also der Einfluss, ob die von LINPACK gelösten Matrizen im ST-RAM oder im TT-RAM liegen.
-
Ich habe LinPack.TOS so laufen lassen, wie Du es angehängt hast.
Werde jetzt mal die Flags setzen...
Ah, jetzt deutlich mehr!
Und jetzt bingo: 215 kFlops (unter TOS_3.06).
Unter MAGX jetzt 192.
-
Ich habe das LINPACK.TOS auch so laufen lassen, wie ich es angehängt habe. Die Flags sind bereits korrekt gesetzt.
ari.tao, lade doch mal die von Dir letztlich verwendete Version hoch (die, mit der Du 215 kFLOPS erreichst); ich möchte sehen, was Du geändert hast.
-
Fpu @48mhz 285.072
-
Hab´s noch 2x laufen lassen unter TOS_3.06 (genauer: ThunderTOS):
1) 215,9
2) 219,2
ari.tao, lade doch mal die von Dir letztlich verwendete Version hoch (die, mit der Du 215 kFLOPS erreichst); ich möchte sehen, was Du geändert hast.
? ? ?
Also: Exakt dieselbe kann ich Dir nicht mehr anhängen - da ich sofort, nachdem die 215 erreicht waren, das Dingele in meinen Bestand integriert, also ibs. mit PFX komprimiert habe. Im Anhang also die kompr. Version (mit der die obigen Werte erzielt wurden).
-
Warum denken alle das durchs höher Takten wesentlich mehr Wärme entsteht? Die Mehrwärme kann man gerade bei der FPU vernachlässigen. Meine mit 48Mhz wird gerade Handwarm. Selbst meine 54Mhz wird zwar Wärmer aber der Unterschied zu 32Mhz ist unwesentlich mehr. Es würde eine rolle Spielen wenn man eine höhere Spannung anlegt so wie es beim PC Overclocking gemacht wird.
Irgendwann hab´ ich nmE. mal gelernt, daß die (Verlust-) Leistung mit dem Quadrat der Frequenz geht - habe ich das falsch eingeloggt?
Du würdest also auch für den Falcon 50MHz unbedenklich finden?
Was könnte kaputtgehen?
-
CT2A unter MagiC, gestartet aus Konsole von Gemini:
396KFLOPS
-
Und für Euch FPU-Übertakter hier der LINPACK-Benchmark, der seit jeher für die Bewertung von Fließkommarechenleistung verwendet wird. Damit könnt Ihr sehen, wo Euer Atari in der Supercomputer-Liste so stehen würde. ;)
Braucht 68030 und 68881/68882 FPU. Nach dem Start einfach Enter drücken.
Mein TT mit 68882: 217 KiloFLOPS. (Platz 1 der Supercomputer hat übrigens PetaFLOPS.)
Welche LinPack-Quellen hast Du dafür benutzt?
-
Welche LinPack-Quellen hast Du dafür benutzt?
http://www.netlib.org/benchmark/linpackc.new
Aber http://www.netlib.org/benchmark/linpackc lieferte ähnliche Ergebnisse. Wenn mir jemand den aktuellen GNU Fortran Compiler für TOS geben kann, teste ich auch das Fortran-Original.
-
Welche LinPack-Quellen hast Du dafür benutzt?
http://www.netlib.org/benchmark/linpackc.new
Aber http://www.netlib.org/benchmark/linpackc lieferte ähnliche Ergebnisse. Wenn mir jemand den aktuellen GNU Fortran Compiler für TOS geben kann, teste ich auch das Fortran-Original.
Firebee (native compiliert mit gcc -O2 -o linpack linpack.c :
firebee:~/Development/linpack#./linpack
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
----------------------------------------------------
8 0.81 88.89% 2.47% 8.64% 14846.847
16 1.63 89.57% 3.07% 7.36% 14551.876
32 3.25 89.52% 3.08% 7.40% 14624.515
64 6.49 89.29% 3.00% 7.70% 14673.344
128 12.99 89.45% 2.77% 7.78% 14679.471
Mit -O3 kommen noch mal ungefähr 100 KFLOPS obendrauf.
-
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:
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.
-
Update: gerade mal versucht andere Programme zu übersetzen. Kompilieren geht, aber beim linken kommt dann:
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.
-
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.
-
Ok, das krieg ich unter linux übersetzt, und läuft auch. Wenn ich das allerdings mit dem cross-compiler übersetze und starte, bekomme ich:
Fortran runtime error: End of record
Noch irgendwelche Ideen? ;)
-
Atari Mega ST4 / PAK68/3 mit 68882/50Mhz / FRAK/2 64MB Fastram
406.914 KFLOPS
-
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
-
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.
-
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.
-
Milan060 unter TOS:
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?
-
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.
-
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.
-
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.
-
Neuer Test auf dem CT2A Falcon, diesmal mit "nacktem" System (Reines TOS, keine AUTO-Ordner Programm, Standartdauflösung):
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
4 14.25 90.18% 2.74% 7.09% 414.904
-
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 (https://www.schwingen.org/files/milan/tools/)
-
Nächster Test auf dem Milan040, mit MagiC und Allem:
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.
-
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.
-
Möglicherweise ist es nicht vorgesehen, die mit einem cross-compiler zu erzeugen.
--> mache mal nen neuen Thread dafür auf
-
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.
-
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.
-
Gemulator (68030+FPU-Emulation) mit EmuTOS auf aktuellem Windows-PC: 15160 kFLOPS.
-
Nicht übel. Gemulator hat soviel ich weiss keinen JIT-Compiler, oder?
-
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
-
Vampire V4 Standalone (unter EmuTOS, "pre-release" Core): 10912 kFLOPS.
-
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
-
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.
-
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.
-
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).
-
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.
-
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.
-
Ü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.
-
AUf meinem Falcon 060 laufen beide neue Programme endlos, ohne ein Ergebnis auszuspucken. Die Version von oben ist relativ zügig durch.
-
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?
-
Wenn die mit unterschiedlichen Libs gebaut werden, hat das vielleicht auch einen Einfluss auf das Ergebnis des Benchmarks?
-
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.
-
... 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.
-
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.
-
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.
-
Ich finde, die Ergebnisse von @1ST1 zeigen gut, dass LINPACK im Wesentlichen keine speziellen, auf dem 68060 zu emulierenden FPU-Operationen nutzt.
-
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
-
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).
-
Thorstens Ergebnis zeigt vor allem, wer einen schnellen Atari haben will, dass er weder eine Vampire noch eine Firebee (oder irgendeine Turbokarte für Originalhardeare) nehmen soll, sondern Aranym auf nem gescheiten PC. Das ist überschlagsmäßig um den Faktor 15 schneller als mein Falcon.
-
Auch hier hinkt der Vergleich ziemlich, wenn man es unter Aranym ausführt. Die Optimierungen die gcc macht beziehen sich zu einem nicht unerheblichen Teil darauf, die Instruktionen in die "richtige" Reihenfolge zu bringen. Das interessiert aber sowohl die Software-Emulation als auch den JIT-Compiler von Aranym herzlich wenig. Auf echter hardware kann das aber sehr wohl einen ziemlichen Unterschied machen.
-
Auch hier hinkt der Vergleich ziemlich, wenn man es unter Aranym ausführt. Die Optimierungen die gcc macht beziehen sich zu einem nicht unerheblichen Teil darauf, die Instruktionen in die "richtige" Reihenfolge zu bringen. Das interessiert aber sowohl die Software-Emulation als auch den JIT-Compiler von Aranym herzlich wenig. Auf echter hardware kann das aber sehr wohl einen ziemlichen Unterschied machen.
Ich bezog mich hier nicht auf die Aranym-Messung. Die Unterschiede bei den CTxx-Ergebnissen liegen im Bereich <6%.
-
ST mit PAK/2 68020 und 68881 FPU @ 25 MHz: 85 KFLOPS.
-
TT mit CPU und FPU auf 48 MHz: 269 kFlops/s.
-
ST mit PAK/2 68020 und 68881 FPU @ 25 MHz: 85 KFLOPS.
25Mhz. Vielleicht eher 16Mhz CPU und 25Mhz FPU ?
Normalerweise läuft die CPU immer über Taktverdoppler 74F86 mit 16Mhz und der Quarz auf der Karte ist ausschliesslich für die FPU zuständig.
-
25Mhz. Vielleicht eher 16Mhz CPU und 25Mhz FPU ?
So war "FPU @ 25 MHz" auch gemeint, also nur die FPU auf 25 MHz. (Das war Deine PAK/2.)
-
TT mit optimiertem Beschleuniger, CPU & FPU mit 48 MHz: 281 kFLOPS
-
Ich habe mal alles hier abgelegt (Programm, Quellcode, Resultate), damit's nicht irgendwann im Forum untergeht: https://github.com/czietz/linpack-atari/
Just for fun habe ich auch das Original (= die FORTRAN-Version des LINPACK-Benchmarks) dazugepackt und auch für den Atari compiliert (danke an Thorsten für den FORTRAN-Compiler). Erwartungsgemäß liefert es leicht andere Resultate; ein paar Prozent Abweichung auf meinem TT. Zur Sicherstellung der Vergleichbarkeit sollte also weiterhin die bekannten C-Version verwendet werden.
Zur Interpretation der FORTRAN-Version: Interessant ist die Spalte "mflops". D.h. anders als die C-Version gibt diese Version das Resultate in MegaFLOPS (nicht KiloFLOPS) aus, knapp 0,3 MFLOPS = 300 kFLOPS, in meinem Fall:
Please send the results of this run to:
Jack J. Dongarra
Computer Science Department
University of Tennessee
Knoxville, Tennessee 37996-1300
Fax: 865-974-8296
Internet: dongarra@cs.utk.edu
This is version 29.5.04.
norm. resid resid machep x(1) x(n)
1.44779578E+00 1.60735140E-14 2.22044605E-16 1.00000000E+00 1.00000000E+00
times are reported for matrices of order 100
dgefa dgesl total mflops unit ratio b(1)
times for array with leading dimension of 201
2.225E+00 6.500E-02 2.290E+00 2.999E-01 6.670E+00 4.089E+01 -7.836E-15
2.225E+00 7.000E-02 2.295E+00 2.992E-01 6.684E+00 4.098E+01 1.000E+00
2.225E+00 6.500E-02 2.290E+00 2.999E-01 6.670E+00 4.089E+01 1.000E+00
2.223E+00 6.650E-02 2.289E+00 2.999E-01 6.668E+00 4.088E+01 5.298E+02
times for array with leading dimension of 200
2.245E+00 6.500E-02 2.310E+00 2.973E-01 6.728E+00 4.125E+01 1.000E+00
2.240E+00 7.000E-02 2.310E+00 2.973E-01 6.728E+00 4.125E+01 1.000E+00
2.240E+00 6.500E-02 2.305E+00 2.979E-01 6.714E+00 4.116E+01 1.000E+00
2.243E+00 6.700E-02 2.310E+00 2.973E-01 6.728E+00 4.125E+01 5.298E+02
end of tests -- this version dated 05/29/04
-
Standard Falcon mit 68030 CPU @ 16 MHz + 68882 FPU: 111 kFLOPS
-
PAK68/3-020 + MC68881 beide mit 32Mhz
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 8.10 91.35% 2.72% 5.93% 180.346
2 16.19 91.35% 2.72% 5.93% 180.405
Enter array size (q to quit) [200]:
-
PAK68/3-020 diesmal mit 40Mhz CPU und eine MC68882 FPU anstatt der 881
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 4.32 89.92% 2.78% 7.30% 343.333
2 8.62 89.97% 2.61% 7.42% 343.978
4 17.25 90.03% 2.72% 7.25% 343.333
Enter array size (q to quit) [200]: