RunCPM Speed-Vergleich auf verschiedenen Plattformen

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:

Zitat von ThoralfAsmussen

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

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

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

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

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

Zitat von ThoralfAsmussen

MID$ nicht benutzt

MID$ ist aber auch recht trivial, du machst erst LEFT$, dann RIGHT$, dann bist du schon fertig.

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

Warum willst Du eine Wurzel ziehen , wenn da ein Quadrat benötigt wird ... ?

Zitat von ThoralfAsmussen

Warum willst Du eine Wurzel ziehen , wenn da ein Quadrat benötigt wird ... ?

Wieso? SQR steht typischerweise für SQuaRe, während SQRT für SQuareRooT steht. Passt also.

Edit: Und das hatten wir doch auch schon vorgestern hier im Thread.

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

PROGRAM Fractal;

VAR A, B, CA, CB, T : Real;
    POWA, POWB      : Real;
    X, Y, I : Integer;

    XLIN : ARRAY [-39..39] OF Real;

LABEL nextX;

BEGIN

FOR X:=-39 TO 39 DO BEGIN
    XLIN[X]:= X*0.0458;
END;


FOR Y:=-12 TO 12 DO BEGIN

  CB:= Y*0.08333;
   
  FOR X:=-39 TO 39 DO BEGIN
    CA:= XLIN[X];
    A := CA;
    B := CB;

    FOR I:=0 TO 15 DO BEGIN
      POWA:=A*A;
      POWB:=B*B;
      IF ( POWA + POWB ) > 4 THEN begin
        if i > 9 then
          write(chr(55+i))
        else
          write(chr(48+i));
        GOTO nextX;
      end;
      T:= POWA - POWB + CA;
      B:= 2 * A*B + CB;
      A:= T;
    END; (* Ende FOR I *)

    WRITE (' ');

 nextX:
  END; (* Ende FOR X *)

  WRITELN('');
END; (* Ende FOR Y *)

END.

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.

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 ?

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

PROGRAM Fractal;
{$R-} (* range checking off *)

VAR A, B, CA, CB, T : Real;
    POWA, POWB      : Real;
    X, Y, I : Integer;

    XLIN : ARRAY [-39..39] OF Real;
    zeichen : array [0..15] of char;
    
LABEL nextX;

BEGIN

FOR X:=-39 TO 39 DO BEGIN
    XLIN[X]:= X*0.0458;
END;
for i:=0 to 9 do begin
    zeichen[i]:=char(55+i);
end;
for i:=10 to 15 do begin
    zeichen[i]:=char(48+i);
end;

FOR Y:=-12 TO 12 DO BEGIN

  CB:= Y*0.08333;
   
  FOR X:=-39 TO 39 DO BEGIN
    CA:= XLIN[X];
    A := CA;
    B := CB;

    FOR I:=0 TO 15 DO BEGIN
      POWA:=A*A;
      POWB:=B*B;
      IF ( POWA + POWB ) > 4 THEN begin
        write(zeichen[i]);
        GOTO nextX;
      end;
      B := 2 * A*B + CB;
      A := POWA - POWB + CA;
    END; (* Ende FOR I *)

    WRITE (' ');

 nextX:
  END; (* Ende FOR X *)

  WRITELN('');
END; (* Ende FOR Y *)

END.

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.