RunCPM Speed-Vergleich auf verschiedenen Plattformen

  • Letztlich glaube ich daß tofro Recht hat: der bascom compiler rechnet die real-Zahlen mit 4 Bytes, während turbo3 dies mit 6 Bytes macht. Das könnte den Laufzeitunterschied ausmachen.

    Letztlich glaube ich auch, dass ich Recht habe ;)


    50% mehr Genauigkeit ergibt eben ~50% mehr Laufzeit. Da könnt ihr noch so lange optimieren ;)

  • BASCOM (wie BASIC-80) verwendet "Single precision" (4 Byte) als Standard für alle numerische Werte (auch Integer). "Double precision" (8 Byte) gibt es aber auch: wenn dafür in FRACTAL.BAS hinter die Variablen A, B, CA, CB und T ein # gesetzt wird, sollte es einen Unterschied geben ...

    In Double-Precision braucht das BASCOM-Compilat sogar 2 Minuten und 45 Sekunden.


    Allerdings konnte ich in Turbo-Pacal nicht einfach von REAL auf SINGLE umstellen, dass ergab dann einen Compile-Error 36 :(


  • In Double-Precision braucht das BASCOM-Compilat sogar 2 Minuten und 45 Sekunden.

    Die Variablen I, X und Y bitte mit % am Ende als "Integer" markieren, sonst sind die auch "Single precision" ...

    Allerdings konnte ich in Turbo-Pacal nicht einfach von REAL auf SINGLE umstellen, dass ergab dann einen Compile-Error 36 :(

    REAL mit "Single precision" (4 Bytes) gibt es z.B. bei "Turbo Modula-2" ... aber dafür fehlt da GOTO ... ;)

  • Die Variablen I, X und Y bitte mit % am Ende als "Integer" markieren, sonst sind die auch "Single precision" ...

    Das scheint nichts an der Zeit zu aendern, die 2 Minuten 43 Sekunden sind nah an den 2 Minuten 45 Sekunden, dass zaehl ich mal als Messtoleranz (Taste druecken beim Start / Laden des File und am Ende schauen nach der Schlusssekunde) :)

  • Das scheint nichts an der Zeit zu aendern, die 2 Minuten 43 Sekunden sind nah an den 2 Minuten 45 Sekunden, dass zaehl ich mal als Messtoleranz (Taste druecken beim Start / Laden des File und am Ende schauen nach der Schlusssekunde) :)

    OK, dafür ist "Turbo Modula-2" unter CP/M 2.2 etwas schneller (39 Sekunden) als "Turbo Pascal 3.01A" (1 Minute, 7 Sekunden): :)

    ... mein erstes Programm in "Modula-2" ... geht sicher "eleganter" ... ;)

  • OK, dafür ist "Turbo Modula-2" unter CP/M 2.2 etwas schneller (39 Sekunden) als "Turbo Pascal 3.01A" (1 Minute, 7 Sekunden): :)

    ... mein erstes Programm in "Modula-2" ... geht sicher "eleganter" ... ;)

    Cool ;)
    Auf welchem "System" hattest Du die Zeiten?
    Auf dem ESP-C2-32S braucht die Turbo-Modula-2 Version 24 Sekunden :)
    JenGun Danke fuers Compilat- aber den "Spass" des selbst-compilierens mit Borlands Turbo-Modula-2
    habe ich mir dann selbst nochmal gegeben :) Musste allerdings erst die Installation auf ANSI umstellen.


  • Keine "richtige Hardware": TCS Genie IIIs (7,2 MHz) in der Emulation ... ;)

    JenGun Ahh ja :)
    Als erstes habe ich mir mal die Win64bit-Version angesehen/gestartet.

    Leider kann man das SDL2-Fenster nicht verschieben und mein Monitor reicht nicht fuer 2x Scale (hab nur 1280x1024)


    Auf meinem Industrie-PC 600Mhz mit debian bullseye habe ich dann auch mal die SDL2-Version selbst compiliert, weil der das i386-deb nicht wollte - er wollte libreadline7 aber hier gibts nur noch libreadline8.

    Beim compile hat er sich dann nicht mehr beschwert ;)


    Der 600Mhz Celeron hat xfce als Desktop und der Emulator brint ihn im Idle nur auf 25% und bis zu 39% beim DIR-command :)


    Kann man die .dmk-Floppy-Images mit .dsk im Betrieb "mischen"? (die aus dem diskdef fuer den Emulator?)
    (damit ich da mal auch andere Software starten kann....)

  • Die Version in C (compiliert mit HI-TECH C V3.09 und -lf) braucht 35 Sekunden, allerdings ist das "Binary" mit 4224 Bytes kleiner als das von Modula-2 mit 16896 Bytes und lädt daher natürlich auch schneller ...

    Einmal editiert, zuletzt von JenGun ()

  • Als erstes habe ich mir mal die Win64bit-Version angesehen/gestartet.

    Leider kann man das SDL2-Fenster nicht verschieben und mein Monitor reicht nicht fuer 2x Scale (hab nur 1280x1024)

    Natürlich ist in dieser Version noch ein "Bug": bitte ALT-Pos1 drücken, dann wird das Fenster zentriert ... ;)

    Die Version für SDL 1.2 läuft auch noch recht schnell auf einem Pentium II mit 300 MHz und einem AMD K6-II mit 500 MHz ... :)

    Für das compilieren der SDL2-Version bitte mit git checkout sdl2 in den SDL2-Branch wechseln, sonst wird die alte Software-Skalierung verwendet und die Fenstergröße kann nicht mit der Maus entsprechend geändert werden ...

    Im Verzeichnis diskimages sind nur die Disk-Images mit den Programmen aus utilities ... alles andere findet man bei https://oldcomputers-ddns.org/public/pub/rechner/eaca/ ... :)

    Einmal editiert, zuletzt von JenGun ()

  • Die Version in C (compiliert mit HI-TECH C V3.09 und -lf) braucht 35 Sekunden, allerdings ist das "Binary" mit 4224 Bytes kleiner als das von Modula-2 mit 16896 Bytes und lädt daher natürlich auch schneller ...

    Gleich mal den Compiler "geholt" und kurz im PDF-Handbuch (Z80-Version) nachgelesen wie man compiliert.
    (nachdem ich schauen musste, wie man das .LBR entpackt :) )

    Hier braucht die C-Version 22 Sekunden zur Ausfuehrung auf dem ESP-C3-32S ;)

  • Wer macht jetzt die Konvertierung nach Fortran ... und Forth ... ? ;)

    https://groups.google.com/g/comp.os.cpm/c/aApTP1saZSg



    Laufzeit unter CP/M-68K auf MC68020 (20 MHz) ca. 5 Sekunden

  • 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 ...

  • Quellcode und "Binaries".

    Damit die Sache möglichst "fair" bleibt, ist der Aufbau der Programme ziemlich gleich

    ..aber Du scheinst die Zeichen erst am Ende der Zeile auszugeben?
    Hat mich erst gewundert gegen die BAS/PAS-Version bei mir.

  • ..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