RunCPM Speed-Vergleich auf verschiedenen Plattformen

  • Für das MBASIC gibt es auch einen Compiler. Allerdings wird ein LINKer dazu gebraucht, im Handbuch ein LINK80.COM. Erzeugt wird eine .REL-File.


    Mittels verschiedener Optionen kann entschieden werden, ob ein BRUN.COM benötigt wird oder nicht.

    basiccompiler.zip


    Problem, das ganze ist für Robotron installiert, also 80*24 auf PC1715 und andere. Das müsste man probieren. Was fehlt ist das BCLOAD.COM.

  • push

    bitte mal probieren

    die Zeilen:

    POWA:=A*A;

    POWB:=B*B;


    ändern in:

    POWA:=sqr(A);

    POWB:=sqr(B);


    wenn die sqr() funktion ordentlich programmiert ist, sollte das ordentlich beschleunigen

  • einsparung von 2 integer additionen sowie einem goto sollte ein bißchen was bringen


  • noch eine ersparnis zum obigen code


    statt:

    T:= POWA - POWB + CA;

    B:= 2 * A*B + CB;

    A:= T;


    geht es kürzer mit:

    B:= 2 * A*B + CB;

    A:= POWA - POWB + CA;


    die variable T ist unnötig.

  • geht es kürzer mit:

    B:= 2 * A*B + CB;

    A:= POWA - POWB + CA;


    die variable T ist unnötig.

    Hmm - auch mit den zusaetzlichen Einsparungen waren es jetzt 43 Sekunden....
    Gegen die 33-35 Sekunden vom BASCOM-compile scheint der Hase woanders im Pfeffer zu liegen...

  • seltsam ... das ist ja langsamer als die 41 die wir schon hatten


    wurden da jetzt alle änderungen vorgenommen, also auch die verlegung der write() anweisung in die innere schleife oder ist das nur das weglassen der variable T ?

  • seltsam ... das ist ja langsamer als die 41 die wir schon hatten


    wurden da jetzt alle änderungen vorgenommen, also auch die verlegung der write() anweisung in die innere schleife oder ist das nur das weglassen der variable T ?

    ich hatte den kompletten Code aus Deinem Beitrag #186 genommen und die Aenderung von #187

  • so, letzter versuch heute abend

    ein bißchen was sollte sich jetzt aber schon bewegen: das auszugebende zeichen wird jetzt vorinitialisiert in einem array.

    dadurch braucht es kein if i > 9 ... sowie kein else und keine indexaditionen mehr.

    damit sollte man jetzt endlich die schallmauer 40 durchbrechen ....


  • so, letzter versuch heute abend

    ein bißchen was sollte sich jetzt aber schon bewegen: das auszugebende zeichen wird jetzt vorinitialisiert in einem array.

    dadurch braucht es kein if i > 9 ... sowie kein else und keine indexaditionen mehr.

    damit sollte man jetzt endlich die schallmauer 40 durchbrechen ....

    Nope :(
    sind immer noch 41-43 Sekunden. Die ASCII-Zeichen haben sich etwas geaendert (Keine grossen A-F mehr) dafuer mehr Satzzeichen etc.

  • Ich habe ein wenig mit den binomischen Formeln herumgespielt, im Versuch eine Multiplikation zu sparen. Leider ohne Erfolg. Es sieht zwar vielversprechend aus mit (A+B)² = A²+B²+2AB und (A+B)(A-B)=A²-B², aber leider bleiben am Ende gleich viele Multiplikationen übrig. Eine Kleinigkeit kann man aber noch optimieren: Für Interpreter und sicher auch alle Pascal Compiler ist T:=A*B; B:=T+T+CB ziemlich sicher etwas schneller als 2*A*B+CB.


    Eine noch kleinere Optimierung könnte ein manuelles Loop-Enrolling der innersten Schleife sein. Zumindest für i < 3, was ja einen ordentlichen Anteil der Ausgabe betrifft. Viel mehr als den "Overhead" der For-Loop und den Array Zugriff beim write() kann man so aber nicht sparen.

  • Zum Fehler bei den ausgegebenen Zeichen:

    es müssen in den beiden initialisierungs fori i:= ... schleifen die beiden werte 48 und 55 vertauscht werden.


    Lauft das benchprogramm eigentlich auf einem Originalrechner oder in einer simulations-maschine?


    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.

  • Zum Fehler bei den ausgegebenen Zeichen:

    es müssen in den beiden initialisierungs fori i:= ... schleifen die beiden werte 48 und 55 vertauscht werden.

    Lauft das benchprogramm eigentlich auf einem Originalrechner oder in einer simulations-maschine?

    Ja - vertauscht passt die Anzeige wieder ;)
    Das Programm wuerde auch auf einem original Z80-Rechner laufen, aber wie in Post #154 geschrieben, hatte ich das .BAS nach .PAS umgesetzt zum Einstand eines ESP-C3-32S mit RunCPM :)



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

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

  • 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