So mit der RC2014-Emulation - namentlich RC2040 auf dem RPi Pico braucht das FRACTAL doch mal etwas laenger
8 Minuten und 7 Sekunden
So mit der RC2014-Emulation - namentlich RC2040 auf dem RPi Pico braucht das FRACTAL doch mal etwas laenger
8 Minuten und 7 Sekunden
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
Der ESP32-Z80-Emulator-Jr (mein Kleiner Cutdown-compile mit option -O3) bringt es auf den normalen ESP32-Wert von 42 Sekunden (andere Z80 / CP/M Emulationen brauchen auch 46 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
PROGRAM Fractal;
VAR A, B, CA, CB, T : Real;
X, Y, I : Integer;
LABEL ZH, ZHZ;
BEGIN
FOR Y:=-12 TO 12 DO BEGIN
FOR X:=-39 TO 39 DO BEGIN
CA:= X*0.0458;
CB:= Y*0.08333;
A := CA;
B := CB;
FOR I:=0 TO 15 DO BEGIN
T:= A*A - B*B + CA;
B:= 2 * A*B + CB;
A:= T;
IF ( A*A + B*B ) > 4 THEN GOTO ZH;
END; (* Ende FOR I *)
WRITE (' ');
GOTO ZHZ;
ZH:
IF I>9 THEN I:= I+7;
WRITE (Chr(48+I));
ZHZ:
END; (* Ende FOR X *)
WRITELN('');
END; (* Ende FOR Y *)
END.
Alles anzeigen
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.
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
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.
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.
PROGRAM Fractal;
VAR A, B, CA, CB, T : Real;
POWA, POWB : Real;
X, Y, I : Integer;
XLIN : ARRAY [-39..39] OF Real;
LABEL ZH, ZHZ;
BEGIN
FOR X:=-39 TO 39 DO BEGIN
XLIN[X]:= X*0.0458;
END;
FOR Y:=-12 TO 12 DO BEGIN
FOR X:=-39 TO 39 DO BEGIN
CA:= XLIN[X];
CB:= Y*0.08333;
A := CA;
B := CB;
FOR I:=0 TO 15 DO BEGIN
POWA:=A*A;
POWB:=B*B;
IF ( POWA + POWB ) > 4 THEN GOTO ZH;
T:= POWA - POWB + CA;
B:= 2 * A*B + CB;
A:= T;
END; (* Ende FOR I *)
WRITE (' ');
GOTO ZHZ;
ZH:
IF I>9 THEN I:= I+7;
WRITE (Chr(48+I));
ZHZ:
END; (* Ende FOR X *)
WRITELN('');
END; (* Ende FOR Y *)
END.
Alles anzeigen
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
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.
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 ...
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 ...
bringt leider keinen Geschwindigkeitsvorteil
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.
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.
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.
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ß.
Alles anzeigenNoch 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.
ist sqr(a) nicht Quadratwurzel von A (also nicht A*A)?
ne, das ist sqrT (with a "T")
Habe übrigens gerade meinen vorigen post noch mal erweitert mit der Ekrlägung, warum sqr(a) schneller ist als a*a.
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.
Meinen Hinweis auf den bios int10h vs dos int21h nehme ich zurück. Wir sind ja hier im CPM Land unterwegs ....
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
Vielleicht wäre mal der Ansatz besser (weil die Bildschirmausgabe fast keine Rolle spielt): https://github.com/scruss/bench64
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.
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
MID$ nicht benutzt
MID$ ist aber auch recht trivial, du machst erst LEFT$, dann RIGHT$, dann bist du schon fertig.