RunCPM Speed-Vergleich auf verschiedenen Plattformen

  • hab mal das BASIC für den Moppel (CPU 8085 mit 3Mhz) reaktiviert und die paar Zeilen eingetippt.

    Das Ergebnis sieht auf dem Bildschirm nicht schön aus, zwischen jedem Leerzeichen fügt er noch ein § hinzu ???


    Für den Durchlauf benötigt er 7:38

    Gemessen an der Hardware gar nicht so übel, finde ich...

    LG Werner


    Peter z80.eu : Laut Conitec klappt er auch mit 24Mhz, aber nur mit externem Oszilator und den Umbau möchte ich mir ersparen...

  • Ich habe mal mit DRI CBasic Compiler verglichen.


    CBasic80 V1 erstellte COM Datei: 1min 28 sek

    CBasic80 V2 erstellte INT Datei mit CRUN ... gestartet: 2min 55sek


    Bascom habe ich jetzt nicht probiert.


    Interessant dass der MBASIC Interpreter (0:58min) schneller ist.


    Mit freundlichen Grüßen


    fritz

    • Offizieller Beitrag

    Auf dem SC126 per Hand gestoppt: 58 Sekunden.


    Hardware features

    • 1 x Z180 processor (33 MHz rated) clocked at 18.432 MHz, with the possibility of software selectable overclocking to 36.864 MHz.

    Mit der gleichen Taktfrequenz war mein Z180 doppelt so schnell (Post #7).

    Hast du Memory WAITs ?

  • Auf dem SC126 per Hand gestoppt: 58 Sekunden.


    Hardware features

    • 1 x Z180 processor (33 MHz rated) clocked at 18.432 MHz, with the possibility of software selectable overclocking to 36.864 MHz.

    Der SC126 gefällt mir auch. Aber er scheint kein CP/M 3.0 (mit banked memory) zu unterstützen - das RomWBW unterstützt wohl nur CP/M 2.2 ...

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

    • Offizieller Beitrag

    funkenzupfer


    Keine Ahnung aber ...

    .

    Z180_CLKDIV = 1

    Ich vermute der Z180 laeuft "nur" mit 18,432MHz.

    Halber Takt -> doppelte Zeit. Passt!

  • Hier noch 2 Programme von Horst Völz zum Thema in HC-BASIC (KC85/3-4 und KC87, könnte auch am Z1013 funktionieren)


    Das ganze ist im Urania Basic für Fortgeschrittene erschienen, das Heft liegt als PDF vor.

  • Zitat

    Weshalb - der Z80 ist eingebaut.

    Genau, der Z80 und vieles andere ist on Board (Kuchenblechgröße) :thumbup:


    Aber jetzt habt ihr mich angefixt, hier noch zwei Kandidaten (handgestoppt):


    MC-CP/M SYS1 Z80A 4-MHz = 4:45

    BASIC-85 Rev. 5.29 (19200 Baud)


    Prof80 Z80B 6MHz = 3:30

    BASIC-80 Rev. 5.21 (9600 Baud)


    Gruß

    Alfred

    Einmal editiert, zuletzt von Kupferbesen () aus folgendem Grund: Falscher Wert beim Prof80 ;-)!

  • Hier die mit bascom5.3 und der Option /Z compilierte Ausgabe:


    CPU: T80

    Clock: 25MHz

    Laufzeit: 19.768s (mit interner Stopuhr gemessen)

    Ausgabe: 115.2kBd.


    Hätte nicht gedacht, dass das so viel bringt. Ich habe den Eindruck, als wenn die serielle Ausgabe bereits zum Nadelöhr wird, aber bei 115.2kBd. ist halt Schluß.


    Cheers

    Kurt

  • funkenzupfer

    SC126 mit 36 MHz - Zeit fuer die Fractale = 38sec

    RomWBW HBIOS v3.1.1-pre.24, 2021-01-13


    SC126 Z8S180-N § 36.860MHz IO=0xC0

    1 MEM W/S, 2 I/O W/S, INT MODE 2 waitstates wie empfohlen

    512KB ROM, 512KB RAM



    Das 'ROM' kann intern geflasht werden - wollte ich auch mal testen damit ich nicht in den Keller muss.



    A>z3plus


    --- Z3PLUS ---

    The Z-System for CP/M PLUS (CP/M 3)

    Vers. 1.02 (c) 1988 Bridger Mitchell

    Ä TPA: 0100 - D405 53.00k Ü




    --- Z3PLUS ---

    The Z-System for CP/M PLUS (CP/M 3)

    Vers. 1.02 (c) 1988 Bridger Mitchell

    Ä TPA: 0100 - D405 53.00k Ü


    TERMINAL: DEC VT100

    -------------------



    Z33 Error And Shell Editor, Vers. 1.6z

    Shell: A0:EASE

    Error Handler: A0:EASE

    AUSKOMMENTIERT PATH A0 $ A A0


    A0:COMMANDS>>mbasic

    BASIC-80 Rev. 5.21

    ÄCP/M VersionÜ

    Copyright 1977-1981 (C) by Microsoft

    Created: 28-Jul-81

    28728 Bytes free

    Ok

    load "FRACT.BAS"

    Ok

    run

    Mit freundlichen Grüßen


    fritz

    Einmal editiert, zuletzt von fritzeflink ()

    • Offizieller Beitrag

    Ziemlich genau 6m30s auf einem NCR DMV mit 16 bit Erweiterung unter basic86.


    Wenn der andere dran ist teste ich unter CP/M80

    Weshalb - der Z80 ist eingebaut.

    Wegen dem Gotek, wollte das erst unter CPM80 testen.

  • noch ein Klassiker der "PC-Reihe" ein OLPC-XO1 mit AMD Geode 433Mhz, 256MB Ram, Fedora-remix (Sugar)

    Laut Werbung sollte der AMD Geode eine Leistung eines PII 700Mhz bringen :)

    Nun ja....


    Interesant fand ich

    per SSH-Terminal von einem anderen Rechner: 17 Sekunden

    per Gnome-Terminal direkt auf dem XO1: 29 Sekunden


    Der Kleine ist aber auch schon ueber 12 Jahre alt und Linux mit 256MB bei der CPU ist anstrengend fuer ihn ;)



  • Der Test krankt aber ein bißchen daran, daß da evtl. das PRINT CHR$() mehr Zeit braucht als die ganzen Berechnungen zusammen. Sollte man evtl. zumindest mal Ausprobieren, welchen Einfluß das bei verschiedenen Plattformen so haben mag - also mal mit und nochmal ohne Ausgabe messen - und dann mit einem anderen Gerät vergleichen.


    Bißchen optimieren geht wohl auch noch. Dann werden aus 11 Minuten max. vielleicht "nur" 9:50.


    Interessant ist ja auch, daß man da eigentlich "immer" FLOPS mißt, dabei waren da MIPS noch nichtmal erfunden, als das Zeugs aktuell war.

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

  • Wenn ich die Laufzeiten einmal mit und ohne PRINT-Ausgabe für den Interpreter und das Kompilat messe, erhalte ich folgendes:


    Diff compiliert 19.768s - 18.410s = 1,358s

    Diff interpreter 46.710s - 45.351s = 1,359s


    Zumindest bei meiner Kiste scheinen die PRINTs nicht die Spaßbremse zu sein. Die meiste Zeit wird wirklich mit der Berechnung verschleudert...


    Cheers

    Kurt

    • Offizieller Beitrag

    Wenn ich die Laufzeiten einmal mit und ohne PRINT-Ausgabe

    Was hast du geändert?

    Hast du die Zeilen 200 und 205 gelöscht? (Listing aus Post #2)


    Ist interessant, das der Zeitunterschied (im Rahmen der Messtoleranz) gleich ist.


    BTW: Nachträglich Glückwunsch zum Geburtstag! Und dann auch noch eine Schnapszahl.

  • ...Zeitunterschied (im Rahmen der Messtoleranz)...

    Keine Meßtoleranz, die gestoppten Zeiten haben eine Auflösung von 1ms. Die Stoppuhr ist ein 1ms-Zähler mit Zwischenzeitenregister, die über OUT-Befehle gesetzt werden. Die PRINT-Anweisungen im Programm sind lediglich auskommentiert. Zumindest der Interpreter muß dann immer noch das REM erkennen und zur nächsten Zeile gehen, aber der dafür notwendige Zeitaufwand ist recht gering. Der Compiler erzeugt dafür keinen Assemblercode. Basic-Prog mit Compiler-PRN hier:


    ASCIIART_bas_und_PRN.txt


    >> BTW: Nachträglich Glückwunsch zum Geburtstag!


    Danke !



    Cheers

    Kurt

    Einmal editiert, zuletzt von kmg ()

    • Offizieller Beitrag

    Keine Meßtoleranz, die gestoppten Zeiten haben eine Auflösung von 1ms. Die Stoppuhr ist ein 1ms-Zähler mit Zwischenzeitenregister, die über OUT-Befehle gesetzt werden.

    Doch Messtoleranz.

    Die Differenz der Differenzen ist 1 ms. Mit einer Tick von 1 ms kannst du nie besser als 1ms messen.

    Startest du die Uhr bei 0,001ms und stoppst bei 0,999ms hast du 0,998ms gebraucht, bekommst aber 0ms angezeigt.

    Umgekehrt, Start bei 0,9, Stopp bei 1,1, den Rest darfst du selber rechnen.


    Die PRINT-Anweisungen im Programm sind lediglich auskommentiert.

    Genau das wollte ich wissen.

  • Die Differenz der Differenzen ist 1 ms. Mit einer Tick von 1 ms

    In dem Punkt reden wir aneinander vorbei. Ich hatte dich so verstanden, das die geringe Differenz der Runs mit/ohne PRINT auf Toleranzen vonf handgestoppten Zeiten zurückzuführen ist (was gut hätte sein können, da man selbst nicht immer so exakt reagiert, deshalb der Hinweis 'Stoppuhr'). Das Du die Differenz der Differenzen meintest, ist mir entgangen... :nixwiss:


    Ansonsten hast Du recht. Überrascht hat mich schon eher die nahezu identischen Werte. Ich werd' mir jetzt jedoch nicht die Mühe machen, heraus zu finden, warum dem so ist. Soo wichtig ist das Apfelmännchen nun auch wieder nicht :tüdeldü:


    Cheers

    Kurt

    Einmal editiert, zuletzt von kmg ()

    • Offizieller Beitrag

    Ich hatte dich so verstanden, das die geringe Differenz der Runs mit/ohne PRINT auf Toleranzen vonf handgestoppten Zeiten zurückzuführen ist

    Wer handgestoppte Zeiten mit 1ms dokumentiert, hat fuer mich einen :wand:


    ob kurz vor dem nächsten Tick oder kurz nach den erfolgten Tick

    Das meine ich mit Messtoleranz.

  • hat fuer mich einen :wand:

    Danke !, wie ich schon weiter oben schrieb "(mit interner Stopuhr gemessen)", also per Hardware-Zähler u. nicht von Hand. Im Übrigen ist das meine Meßroutine für Laufzeitmessungen, die ist halt der Einfachheit wegen so eingestellt (s. Screenshots). Es ist also keine Erbsenzählerei, eher banaler Pragmatismus um nicht für jeden Sonderfall die Software anpassen zu müssen, deswegen ja auch die Meßzeit von Tagen bis herunter zu ms !


    Cheers

    Kurt

    • Offizieller Beitrag

    Danke !

    Beziehst du das jetzt auf dich?

    Ich hab gelesen, dass du das einem Timer gestoppt hast. Hast du gelesen, das ich ueber "handgestoppten Zeiten" geschrieben habe?



    Ich schreib's mal anders:

    Ich hatte dich so verstanden, das die geringe Differenz der Runs mit/ohne PRINT auf Toleranzen vonf handgestoppten Zeiten zurückzuführen ist

    Wer bei einer handgestoppten Zeit die Millisekunde angibt, hat fuer mich einen :wand:

  • Beziehst du das jetzt auf dich?

    Ja, das ist eben die Krux mit den Zitaten, Laß uns das nicht weiter vertiefen... Für mich sind diese Zeitmessungen interessante Infos zu den Systemen, denn CPU und Clockfreq. sind allzu häufig nur marketing. Abgesehen davon geht mitunter auch der Spaß am eigenen System mit einem durch...


    Cheers

    Kurt

  • mit RunCPM auf OpenWRT (Router-Plattform: LinkIt Smart Duo MT7688 = 580Mhz MIPS CPU mit 128MB Ram)

    dauert das Fractal 12 Sekunden ;)


    Fuers compilieren der RunCPM-Version mit DR-CCP brauchte ich (komischerweise) noch extra Swap-Ram.

    (eingestellt hatte ich dafuer auf dem Filesystem der SDCard als File nochmal 128MB)

    Code
    MT7688 Swapfile for compile RunCPM:
    dd if=/dev/zero of=/swapfile bs=1024 count=128000
    mkswap /swapfile
    swapon /swapfile

    Das compilieren mit dem internal-CCP klappte auch ohne extra Swap-Ram.

  • Ich vermisse hier noch ein paar Rechner.. :)


    zB. Kaypro II und Commodore 128 im CP/M Modus.. Hat die jemand startbereit oder muß ich ins Archiv klettern ? :D



    Gruß Jan