RunCPM Speed-Vergleich auf verschiedenen Plattformen

  • So ;) mit der RC2014-Emulation - namentlich RC2040  auf dem RPi Pico braucht das FRACTAL doch mal etwas laenger
    8 Minuten und 7 Sekunden

    Das war die Version, die ohne Overclock (=125Mhz) compiliert war.

    Mit Overclock auf 250Mhz (ist safe beim Pico) laeuft er so gut wie doppelt so schnell und schafft das FRACTAL nun in
    4 Minuten und 7 Sekunden :)

  • Zum "Einstand" von RunCPM auf dem RISC-V ESP-C3-32S

    der den FRACTAL.BAS-Test unter MBASIC in 1 Minute und 25 Sekunden geschafft hat,

    habe ich - mit meinen NICHT-exitenten Turbo-Pascal-Kenntnissen - mal das Programm umgesetzt

    von FRACTAL.BAS ==> FRACTAL.PAS ;)
    (ist bestimmt nicht schoen - weil nicht eingerueckt - aber selten :) )

    Das compilierte FRACTAL.PAS als FRACTAL.COM laeuft dann auf dem ESP-C3-32S in 55 Sekunden durch,
    also 30 Sekunden schneller als im MBASIC Interpreter :)


  • Ich war mal so frei. Man könnte probieren, ob man A*A und B*B noch je einer Hilfvariablen zuweist und diese dann benutzt. Spart potentiell 2 Multiplikationen und kitzelt mit bißchen Glück nochmal 2 Sekunden raus.


    Dieses Label-Anspringen ist natürlich, und gerade unter Pascal, absolut daneben. Das geht so nicht und verletzt zutiefst das Ehrempfinden jedes Pascal Fetischisten. Möglicherweise ist es noch nichtmal die schnellste Lösung. Aber solange es tut, ist ja alles erlaubt.


    Der Vergleich mit dem Interpreter ist natürlich etwas sinnfrei, da müßte man schon das BASIC auch mal compilen. Wird aber sicher nicht viel besser werden als die 55 Sekunden.



    Ansonsten: Wie heißt den der Font im Bild in #153 ?? Der würde mir auch gut gefallen.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Ansonsten: Wie heißt den der Font im Bild in #153 ?? Der würde mir auch gut gefallen.

    Ich habe gerade mal fuer dies "Terminal" in kiTTY nachgesehen...

    Dies ist Cousine in 14pt (14pt nur fuer den Screenshot damit mehr drauf passt).
    Normal nutze ich 16 oder 18pt fuer Linux-Terminals


    Alternativ kann ich auch empfehlen (ich wechsle im Moment da noch ein wenig je nach Terminalverbindung):
    - IBM Plex Mono (Standard-Dicke 16pt) - eher quadratisch - mag ich fuer Retro und C/M

    - JetBrains Mono (Standard-Dicke 16pt) - etwas hoeher als IBM Plex Mono

    und

    - Vio converted to TTF aus IBM OS/2 - hat aber einen groesseren Zeilenabstand

    Vio war eine Empfehlung hier aus dem Forum und kommt normal als - glaub ich - .otf Font


    PS: Deinen Source habe ich auch nochmal compiliert, aber der ergab dann keinen Geschwindigkeitsvorteil mehr :)

    Einmal editiert, zuletzt von guidol ()

  • Der Vergleich mit dem Interpreter ist natürlich etwas sinnfrei, da müßte man schon das BASIC auch mal compilen. Wird aber sicher nicht viel besser werden als die 55 Sekunden.

    Da staunt der Laie und der Experte wundert sich ;)
    Deinen Pascal-Source hatte ich als FRAC2 compiliert und der lief auf dem ESP-C3-32S in 56 Sekunden durch
    (also vorher wie mein Pascal-Code mit 55 Sekunden - ist nur eine Hand/Augen-Messung)


    Um jetzt nicht "sinnfrei" zu sein :) habe ich mich kurz eingelesen und das FRACTAL.BAS mit BASCOM/L80 von Microsoft in ein FRACTAL.COM verwandelt (welches natuerlich das BRUN.COM als Runtime braucht)


    Aber da war ich echt erstaunt!
    Auf dem ESP-C3-32S braucht das BASCOM/L80 FRACTAL.COM nur 33 Sekunden!


    BASCOM v5.3 ging immer nur auf den Prompt zurueck, aber die alternative Version tat dann ihren Dienst :)


    Im Anhang als .ZIP Source & Binary von FRACTAL (inkl. BRUN.COM-Runtime) und FRAC2


    PS: Klar - Spruenge/GOTOs in Pascal sollten ein No-Go sein, aber wie geschrieben habe ich eigentlich keine Pascal-Kenntnisse, so blieb mir nichts anderes als das BASIC-Programm 1:1 umzusetzen ;)

  • Dank für die Fonts.

    Sowas ist ja immer schön, wenn das schick ausssieht. Und es gibt irgendwie nicht wirklich viele, die sich als nicht-proportional Charfont eigenen.



    PS: Deinen Source habe ich auch nochmal compiliert, aber der ergab dann keinen Geschwindigkeitsvorteil mehr :)


    Der war auch unverändert. Ich will doch nicht in Deine Schöpfung eingreifen ... :) . Ich hatte nur eingerückt und zwei remarks ergänzt.


    Das mit den vorgeschlagenen gesparten Multiplikationen bringt aber auch nix, habe das mittlerweile mal probiert. Wird anscheindend identisch überkompensiert durch das Belegen und Auslesen der Variablen für A*A und B*B.

    Außerdem hatte ich mal getestet, ob man nicht die eine Startvariable, die ja in jeder Bildzeile identisch ist (X), in einem Array unterbringen kann und dann jeweile eine Multiplikation pro Durchlauf spart. Brachte aber auch nichts. Evtl. sieht das aber auf einer kleinen Hardware ohne Floatingpoint doch anders aus.

    Dabei habe ich aber festgestellt, daß man bei Pascal auf ein Array von [-39..39] definieren kann, was ja mal eine sehr witzige Sache ist.


    Ein sehr schönes Buch dazu gibt es übrigens hier

    https://archive.org/details/the-byte-book-of-pascal/mode/2up

    taugt natürlich nicht als Bastelbuch am Rechner, wenn man selbst was bauen mag.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Auf dem ESP-C3-32S braucht das BASCOM/L80 FRACTAL.COM nur 33 Sekunden!


    Dann nimm mal einen anderen Pascal Compiler. Das MUSS in die gleiche Richtung kommen können.


    Ist aber natürlich eine Ansage, die Zeitmessung, das ist ja dann doppelter Speed. Da muß der BASIC Compiler evtl. noch irgendwas anderes machen, vielleicht sowas, wie die richtigen Daten in den Registern halten. Bei C kann man das ja zumindest als Wunsch bei der Variablendefinition ansagen, bei Pascal geht das evtl auch.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries


  • hier, zum Probieren


    evtl. muß man den Abbruch ( IF ... >4 ) noch anpassen, damit es identisch wird, der kommt ja jetzt potentiell eine Runde zu früh

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    • Offizieller Beitrag

    evtl. muß man den Abbruch ( IF ... >4 ) noch anpassen, damit es identisch wird, der kommt ja jetzt potentiell eine Runde zu früh

    Nee, der kommt hier genau richtig!

    Der Test muss richtigerweise auch mit dem initialen A und B erfolgen.


    Du kannst aber das CB vor dem FOR X berechnen, da sich Y erst wieder bei der naechsten FOR Y aendert.

    Code
    CB:= Y*0.08333;
    FOR X:=-39 TO 39 DO BEGIN


    Aber das geht jetzt Richtung Klugscheisser-Modus. ;)

  • hier, zum Probieren

    Deinen neuen Code & den mit den 2 Zeilen abgewandelt von funkenzupfer habe ich compiliert und da sind wir bei Turbo-Pascal von ca. 55 Sekunden nun runter auf 40-41 Sekunden - bei gleicher Hardware.

  • Interessant - bitte in Zeile 20 die 2 auf 2.0 ausbessern, ebenso in Zeile 22 die 4 auf 4.0

    In Turbo3 jedenfalls muß sonst eine Typumwandlung "gerechnet" werden ...

  • ok, weiterer versuch: wieso nicht wie schon zuvor bei xlinx das gleiche auch für Y*0.08333 machen. auch hier kann man ein array vorab ausrechnen ...


    ich verstehe die Bemerkung nciht:

    Evtl. sieht das aber auf einer kleinen Hardware ohne Floatingpoint doch anders aus.

    Einmal editiert, zuletzt von DoPe ()

  • ich verstehe die Bemerkung nciht:


    Das sollte nur heißen, daß ich das hier auf einem mehrere Gigahertz Quadcore mal allen möglichen Hardwarecoprozessoren inklusive ausprobiert habe und dann eben einfach 5000 Durchläufe gemacht habe, um überhaupt kleine Unterschiede zu sehen. Wenn man das nun aber auf einem Gerät laufen läßt, was keine Floating Point Hardware hat, passiert da ja nochmal was ganz anderes, weil das dort dann ja langsamst emuliert wird (6502 Pet, Z80 CPC oder sowas).



    Zu dem Y*0.08333 : das läuft ja wohl jedesmal nur einmal durch die Schleife, daher bringt das wohl nix da ein Array zu benutzen. Man macht damit dann nichts gut, wenn bereits gilt: Es vor die Schleife zu stellen, der Vorschlag von funkenzupfer, sollte dagegen schon was bringen. Vielleicht ist das ja sogar der Haupteffekt der die 14 Sekunden Beschleunigung hauptsächlich ausmacht.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Einmal editiert, zuletzt von ThoralfAsmussen ()

    • Offizieller Beitrag

    wieso nicht wie schon zuvor bei xlinx das gleiche auch für Y*0.08333 machen. auch hier kann man ein array vorab ausrechnen ...

    Weil jedes Y nur ein mal vorkommt.

    Bei X werden alle Werte Y mal durchlaufen.

  • Ja, richtig.

    Insgesamt ist es aber sehr verwunderlich wo bascom die Zeit gewinnt.

    Könnte es nicht sein, daß bascom für die ausgaben "write( ...)" den bios int 10H benutzt?

    wenn das so ist, dann wundert es mich nicht, denn der hier verwendete turbo3 compiler ist eine compiler für ein ANSI-Terminal. D.h., er ruft den dos int 21H auf, der die Ausgabe auf ANSI ESCacpe Sequenzen hin überprüft. Das kostet enorm viel Zeit .... habe eine NCR DMV mit Turbo3 für ANSI-Terminal als auch (gepatched damit er läuft) den Turbo3 für PC-DOS (IBM). Der Unterschied in der Bidlschirmausgabe ist enorm. Ob das allerdings den großen Zeitvorsprung des bascom compilers wettmachen kann ...

  • Das ist ja generell das große Problem an den Tests. Gerade auch über verschiedene System hinweg. Trotzdem ist es natürlich lustig zu sehen und so bißchen ein Anhaltspunkt ergibt sich schon auch - etwa wenn es 40 sec vs 2:58 min steht.


    Da kann der guidol ja einfach mal die Ausgabe abschalten. Dann klärt sich das ja evtl.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Noch eine Idee:


    die Zeilen:

    POWA:=A*A;

    POWB:=B*B;


    ändern in:

    POWA:=sqr(A);

    POWB:=sqr(B);


    Ich könnte mir vorstellen, daß dies der Schlüssel ist, weil die funktion sqr() "weiß" daß sie 2 mal den gleichen wert vor sich hat, der in Real-Zahlendarstellung vorliegt. D.h., Basis/Hochzahl. Eine derartige Zahl mit sich selbst multiplizieren bedeutet immer, daß man nur die Hochzahlen summieren muß.

    2 Mal editiert, zuletzt von DoPe ()

  • An sich kein großes Wunder, das compiliertes MBASIC schneller ist als Turbo-Pascal:


    MBASIC rechnet mit 32-Bit-Fließkommazahlen, Turbo-Pascal mit 16 Bit mehr.


    Dass MBASIC aber annähernd doppelt so schnell ist, wundert mich schon ein bißchen.

    • Offizieller Beitrag

    Wir sind ja hier im CPM Land unterwegs ....

    Ja, aber auch da gibt es ein BIOS bzw BDOS mit dem man Zeichen ausgeben kann.

    Je nach System muss das BIOS dann auch eine Terminal-Emulation vornehmen oder sendet das Zeichen einfach über eine serielle Schnittstelle raus. Alleine deshalb wird es große Unterschiede bei solchen Benchmarks geben. Selbst wenn ich das gleiche Programm bei gleichem Prozessor und gleicher Taktfrequenz und und und benutze.

    Damals war es wichtiger, das gleiche Programm läuft mit gleichem Ergebnis auf vielen Rechnern. Aber das nur nebenbei.


    Die Benchmarks und deren Ausführungszeiten seh ich Vergleichskriterium auch sehr kritisch. Aber es ist einfach sehr interessant.

    Ich weiss ja auch gerne auf meine eigene Ergebnisse hin. RE: RunCPM Speed-Vergleich auf verschiedenen Plattformen ;)

  • Da kann der guidol ja einfach mal die Ausgabe abschalten. Dann klärt sich das ja evtl.

    Hab ich mal getan, bringt keinen Speedgewinn - beim ESP-C3-32S

    denn - wo ich drueber nachdenke ist mir es klar, dass es nichts bringen kann -

    denn die Ausgabe erfolgt hier ueber die serielle USB-Schnittstelle mit 115.200 Baud :)


    Ich hatte das FRAC2/FRAC3 nochmal ohne Ausgabe compiliert und genau die gleichen Zeiten.


    Bei einem C=128 unter CP/M koennte dies natuerlich GANZ anders aussehen, der mueht sich bei der Ausgabe doch sehr ab ;)

  • Na ja, das testet aber eher die Qualität des Basic Interpreters - und versucht noch nichtmal eine irgendwie geartete Aussage über die "Rechenpower" des Geräts zu finden. Jetzt vom "MATH:" Test ( LET Y=(TAN(ATN(SQR(Y*Y)))+1)/Y ) mal abgesehen. AUßerdem kann man natürlich auch da trefflich diskutieren, was z.B. ein StringRoutinen Test soll, der MID$ nicht benutzt. LEFT$ und RIGHT$ sind ja wohl relativ easy zu machen. Und der "ARRAY:" Test, testet evtl. in erster Linie die Division aus der Funktion von FNM() und dem /3. (habe nur das BBC Basic angeschaut).


    Prinzipiell aber schon eine schöne Idee.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Dass das nur auf BASIC sich bezieht, ist bei "FRACTAL.BAS" doch ähnlich. Da es meist als Hochsprache bei Heimcomputern nur ein BASIC-Interpreter gibt, ist das, wenn nicht Äpfel mit Birnen (Interpreter mit Compiler) verglichen wird, aber trotzdem aussagekräftig.

    Außerdem würde uns keiner daran hindern, da einfach die Tests zu verfeinern/zu ergänzen ;)

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.