RunCPM Speed-Vergleich auf verschiedenen Plattformen

  • Dieser MC68000 Fortran77 Compiler akzepiert mandel.for, obwohl der eigentliche Code nicht ab Spalte 7 anfängt? GNU Fortran f77 macht das nicht ... mit F80.COM unter CP/M 2.2 gibt es trotz geänderter Formatierung noch Fehlermeldungen ... :/

    Da fehlen Blanks !


    So funktioniert es mit SVS Fortran unter CP/M-68k:

    Einmal editiert, zuletzt von ngc224 ()

  • Da fehlen Blanks !

    Die hatte ich auch eingefügt und GNU Fortran f77 compiliert ohne Fehlermeldungen und das Programm läuft unter Linux. Mit MicroSoft FORTRAN-80 V3.44 unter CP/M 2.2 funktioniert es jedoch nicht:

  • ... ist die formatierte Quelldatei von ngc224 oben ... wird auch in VDE korrekt angezeigt ...

  • Mittlerweile ist auch mir klar geworden, daß die beiden obigen FORTRAN-Compiler unter CP/M-80 nur "FORTRAN 66" unterstützen und nicht "FORTRAN 77" ... :fp: Laut einem "Tweet" soll es das Programm auch als MANDLBRT.FOR für den F80 geben, habe es allerdings noch nicht gefunden ...

  • ... anstelle des Stern muss vermutlich eine "Unit Number" in der WRITE Anweisung angegeben werden.

    Ich weiß jetzt nicht auswendig ob das bei MS-FORTRAN damals 1 oder 2 oder 3 für die Konsole war.

    Ich meine, das steht im Manual ;) (ich glaube, 1, 2, 3 waren beim CP/M MS-FORTRAN für CON, RDR, LST vorbelegt, ist jetzt aber schon wieder 2 Jahre her, dass ich damit was richtiges gemacht habe).



    Also mal

    WRITE(1,9000) OUT

    probieren.


    Und

    %Line: 25 Zero Format Value:FORMAT(1X,79A)

    ist tatsächlich falsch - würde ich in (1X,79A1)

    also 79 mal 1 Buchstabe oder in (1X,A79) also ein 79 Zeichen breites Feld

    ändern.

  • So funktioniert es auch mit F80:

    ... die Optimierung mit POWA und POWB verfälscht die originale Darstellung des ursprünglichen BASIC-Programms ...

    Einmal editiert, zuletzt von JenGun ()

  • In FRAC66 fehlte die letzte Ausgabezeile: es muß dort überall 25 stehen, nicht 24 ... im ZIP-Archiv sind die korrigierten Versionen für HI-TECH C, MS-FORTRAN, Turbo Modula-2 und Turbo Pascal mit Quellcode und "Binaries". Damit die Sache möglichst "fair" bleibt, ist der Aufbau der Programme ziemlich gleich: HI-TECH C und Turbo Modula-2 liegen hier mit 45 und 47 Sekunden vorne, gefolgt von MS-FORTRAN mit 59 Sekunden. Turbo Pascal (wegen 24 Bit REAL-Typ) braucht dafür 1:20 Minute ...

  • ..aber Du scheinst die Zeichen erst am Ende der Zeile auszugeben?

    Die obige Version für SVS FORTRAN-77 macht das ja auch so ... :) Im ZIP-Archiv sind jetzt auch Versionen für NEVADA FORTRAN 3.0(FRUN FRACNEV braucht knapp 3 Minuten) und für Modula-2 System for Z80 CP/M von Peter Hochstrasser, welches ähnlich schnell wie HI-TECH C und Turbo Modula-2 ist ...


  • Auf einem DELL FX160 (1.6GHz ATOM)

    unter MS-DOS 6.22 mit NNANSI 5/93 und CWSDPMI als Extender


    Zum Vergleich FRACTAL gegen sich selbst auf dem FX160 mit den verschiedenen Optimierungs-Optionen beim compilieren:


    - Option -O0 (Minimierung der Compile-Zeit)

    FRACTAL.BAS interpretiert 18 Sekunden

    FRACTAL.BAS compiliert 12 Sekunden


    - Option -Os (optimiert auf Binary Size - ist aber doch groesser als -O0)

    FRACTAL.BAS interpretiert 6 Sekunden

    FRACTAL.BAS compiliert 4 Sekunden


    - Option -O3 (auf Speed optimiert)

    FRACTAL.BAS interpretiert 4 Sekunden

    FRACTAL.BAS compiliert 4 Sekunden


    Spannend finde ich, dass bei -O3 sich die Zeitspanne zwischen interpretierter und

    compilierter Version (handgemessen) nicht mehr unterscheidet ;)

    3 Mal editiert, zuletzt von guidol ()

  • Hallo, ich kapere mal den Thread (weil kein CP/M)


    auf einem Commodore CBM 8032 mit Basic 4.0 läuft das Programm mit leichter Anpassung (für den Zeichensatz):



    Das Resultat passt gerade so auf den Bildschirm:



    Die Zeit ist nicht berauschend:



    500 s, naja, mehr gibt die alte Hardware nicht her, oder ?


    Jetzt schalten wir den Turbo ein:



    und das Resultat ist...



    .. fast 100 mal schneller !! Und das ist kein Fehler am Timer, habe mit der Hand mit gestoppt, die Zeit ist echt !


    Über die Ursache hatte ich schon mal berichtet: ein FPGA-Chip steckt im Steckplatz des 6502, mit der Kraft dieses Herzens schafft der CBM den Faktor 100



    Roland

  • Und der Rest der Pereferie?

    Der Chip schaltet bei zeitkritischen Zugriffen auf die Peripherie ( Bildschirmspeicher, Floppyzugriff etc) auf 1MHz zurück. In dem Mandel-Programm machen die 25•80 Zugriffe zu einem Byte auf den Bildschirmspeicher einen vernachlässigbaren Anteil an Rechenzeit im Vergleich zu den Rechnungen aus, deshalb kommt hier wirklich ein Faktor von fast 100 an Beschleunigung raus.

    Bei einem LIST von einem grossen Programm ist der Geschwindigkeitsgewinn immer noch mehr als Faktor 10.


    Roland

  • und jetzt nochmal ein richtiger Oldie: ein Heathkit H89, Markteinführung 1979, meiner ist von 1981. Z80 CPU 2 MHz




    getestet mit HDOS 2.0 und MBasic Rev 4.82 für HDOS



    Dauer; 11 min 4 sec


    dann noch Benton Harbor Extended Basic #110.06.00 ausprobiert, ebenfalls auf HDOS 2.0



    hier muss man 17 min 55 sec Geduld haben.


    Ich habe auch ein CPM 2.2.0 für den H89, bekomme aber z. Zt das MBasic auf CP/M noch nicht zum Laufen


    Gruß

    Roland

  • Ein 900Mhz Celeron eeePC 701/4G scheint mit dem -O3 RunCPM fuer DOS fast genauso schnell wie der 1.6GHz Atom...


    DOS wurde ueber eine SD Karte gebootet.

    Die Karte habe ich mit dem DELL FX160 erstellt (Drive 2 in FDISK) aber die Boot-Partition konnte ich nur im Linux FDISK aktivieren, da DOS dies sonst nur auf Platte 1 macht...



  • Eine pdp11/40-Emulation auf einem RPi Pico braucht unter BASIC-11/RT-11 dafuer 1 Minute 54 Sekunden ;)


    Ich musste die Variablen CA und CB gegen C und D tauschen, da wohl keine Variablen mit 2 Buchstaben erkannt wurden.

    Fuer die richtige Darstellung musste ich auch die Breite (X) verringern von 39 auf 35, da ansonsten die Zeile zu lang war.



  • Business-BASIC auf der pdp8 (simh) mag den Source nicht :(

    Das Basic ist etwas eingeschränkt. Hier steht unter "Description" warum's nicht läuft:

    BASIC-8 - Wikipedia


    Entweder IF ... THEN zeilennummer oder IF ... GO TO zeilennummer.

    Kommandos nach IF gehen gar nicht.

    Das Leerzeichen im GO TO ist Pflicht.

    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Entweder IF ... THEN zeilennummer oder IF ... GO TO zeilennummer.

    Kommandos nach IF gehen gar nicht.

    Das Leerzeichen im GO TO ist Pflicht.

    Danke fuer die Info! ;)


    So gehts dann:


  • Eine pdp11/40-Emulation auf einem RPi Pico braucht unter BASIC-11/RT-11 dafuer 1 Minute 54 Sekunden ;)

    Der original pdp11/40-E,ution-Source setzt den Pico auf 200Mhz,
    aber man kann a "safe" auf 250Mhz "overclocken" (wie bei RunCPM)


    So braucht der Pico bei 250Mz nur noch 1 Minute 29 Sekunden, d.h. von 114 auf 89 Sekunden,
    dass passt auch ca. zu dem 1/5 Anstieg an Mhz ;)

  • Kompiliert? Runtergeladen, installiert, und ausgeführt. Das ist ein GW-Basic-(kompatibler)-Interpreter.

    Ich weess. Kann man aber ja trotzdem kompilieren und dann mal laufen lassen. Der Unterschied waer schon mal ganz interessant. Compiler ? PDS 7.1 z. Bsp.
    Aber mhhhh, ist ja Windows 11. Dann nimmste halt VB 6 und kompilierst den Code.
    Weitgehend sollte der Code eigentlich funktionieren......

    Alles geht - Nichts muß