Zeitverzögerungen

  • Zeitverzögerungen

    Also so, wie ich das sehe stehen hier verschiedene Fragen im Raum, die nie geklärt wurden:

    Und zwar, wieviel Zeitverzögerung bringt ein Doppelpunkt für ein Basic-Programm.
    Die gleiche Frage stellt sich natürlich für eine leere Zeile mit Doppelpunkt.
    Und natürlich auch für ein Leerzeichen.

    Wer kann die Frage beantworten ?

    Schönen Gruß.
  • Quellcode

    1. 10 a=ti
    2. 20 for i=0to10000
    3. 30 b=b+1
    4. 40 next
    5. 50 print ti-a
    vs.

    Quellcode

    1. 10 :a=ti
    2. 20 :for i=0to10000
    3. 30 :b=b+1
    4. 40 :next
    5. 50 :print ti-a

    Ersteres braucht bei mir 2608 Ticks, letzteres 2779. (Ein Tick entspricht einer 60.el Sekunde)
    Die für die Schleife relevanten Doppelpunkte führen also schon zu einer Verlängerung von 171 Ticks, oder knapp 3 Sekunden.
    Auf ein größeres Programm mit vielen Schleifen gerechnet wird es da recht schnell imposant was an Zeit verschleudert wird.

    Wenn man die Schleife Auf eine Zeile eindampft bleibt die Zeit für beides (wegen der Kürze des restlichen Programmes und weil der Zeilenkopf nur einmal interpretiert wird) gleich: 2548 Ticks.
    Allerdings ist das Schönrechnerei, denn im Alltag wird man oft Konstrukte haben die nicht auf eine Zeile zusammenzufassen sind, und wenn, dann nicht ohne massiven Verlust an Übersichtlichkeit, was ja laut Threadersteller einer der Hauptpunkte für die Doppelpunkte sei.

    Führt man zB b=b+1 in 11 anstatt einer Zeile aus ergibt das 21824 vs. 22851 Ticks, sprich, hier werden schon allein wegen der führenden Doppelpunkte 17(!) Sekunden zusätzlich benötigt.

    Das B=B+1 steht dabei einfach stellvertretend für beliebige Operationen die jeweils ansonsten eine Zeile verschlingen, es ist also ein Dummy.

    Es ist sicher sinnig Operationen zusammenzufassen und *innerhalb* einer Zeile Doppelpunkte zu nutzen um Befehle zu trennen- eine neue Zeile zu interpretieren verschlingt mehr Zeit als ein Doppelpunkt zum trennen zweier Befehle.

    Beispiel:

    Quellcode

    1. 5 a=ti
    2. 10 for i=0to10000
    3. 30 b=b+1
    4. 31 b=b+1
    5. 32 b=b+1
    6. 33 b=b+1
    7. 40 next
    8. 45 print ti-a
    '8551 Ticks'

    Quellcode

    1. lI
    2. 5 a=ti
    3. 10 for i=0to10000
    4. 30 b=b+1:b=b+1:b=b+1:b=b+1
    5. 40 next
    6. 45 print ti-a
    '8439 Ticks'
    Aber Auch hier ist der führende Doppelpunkt wieder ein zusätzlicher Killer:
    Alles zusammengefasst auf eine Zeile und nur ein führender Doppelpunkt dabei:

    Quellcode

    1. 30:b=b+1:b=b+1:b=b+1:b=b+1
    benötigt 8938 Ticks, ist also immer noch 6 Sekunden langsamer als der komplett ausgerollte Code im ersten Beispiel, und sogar mehr als 8 Sekunden langsamer als der kompakte Code.

    QED.

    Wer also von sich behauptet schnellen Code mit Basic erstellen zu wollen, der ja Maschinensprache fast ebenbürtig ist und dann alles mit den doppelten Pünktchen ausbremst disqualifiziert sich selbst.
    (Ach ja, einen hab ich noch:
    Ersetzt man for i = 0 to... mit for i = .to ändert das am Ergebnis ... nichts. Es werden gleich viele Ticks verbraten. Diese Änderung macht also nur Sinn wenn sie zB in einer Loop eingesetzt wird, der Einzelfall ist quasi nicht messbar.
    )
    Also mit . auf Gas und mit : auf Bremse treten - da bremst man mehr als dass man Gas gibt.

    Das lässt sich dann zeigen wenn man obige Additionen ersetzt:

    b=b+.:b=b+.:b=b+.:b=b+.

    Dann werden aus ~8900 ticks nämlich plötzlich nur noch rund 6200, was auch ein Beweis dafür wäre dass Optimierungen nicht blind durchgeführt werden müssen, sondern man beim Optimieren schon vorher einen Blick auf's Potential werfen sollte.
    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?
  • CommieSurfer schrieb:

    Kostet ein ":" gar mehr Zeit als für den nachfolgenden Befehl eine neue Basic-Zeile anzufangen ? (Ist gleich oder eher weniger, oder ?)


    BladeRunner schrieb:

    Es ist sicher sinnig Operationen zusammenzufassen und *innerhalb* einer Zeile Doppelpunkte zu nutzen um Befehle zu trennen- eine neue Zeile zu interpretieren verschlingt mehr Zeit als ein Doppelpunkt zum trennen zweier Befehle.

    All zu groß ist der Unterschied allerdings nicht. Dennoch ist es sinnvoll mehrere Operationen zusammenzufassen.
    Allerdings würde ich - wenn ich schon Basic nutze - nur dort viele Befehle in eine Zeile packen wo es absolut Zeitkritisch ist. Ansonsten wäre mir Übersichtlichkeit wichtiger. Das muß ja aber jeder für sich entscheiden. Einzig der führende Doppelpunkt disqualifiziert sich in jedem Belang. Trägt nichts zur Lesbarkeit des Codes bei und frisst Zeit.
    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?
  • Laut ADAC verzögert ein Doppelpunkt das Programm also um ca. 2.75/10000 ,also aufgerundet drei.zehntausendstel Sekunden.

    Das macht also
    bei 10000 Schleifendurchläufen 2,75 Sekunden: im Sekundenbereich.
    bei 1000 Schleifendurchläufen 0,275 Sekunden: im Zehntelsekundenbereich
    bei 100 Schleifendurchläufen 0,0275 Sekunden: im Hundertstelsekundenbereich
    bei 10 Schleifendurchläufen 0,00275 Sekunden: im Tausendstesekundenbereich
    bei 1 Durchlauf 0,000275 Sekunden: im Zehntauselstelsekundenbereich.

    Schönen Gruß.
  • und diese zehntausendstel Sekunden summieren sich, und das ganz gewaltig.
    Jeder einzelne bremst, und bei der Geschwindigkeit mit der der Interpreter den code abarbeitet hast du also für 3k abgearbeitete Befehle eine Sekunde Verzögerung. Die wenigsten Programme laufen ein einziges mal von oben nach unten durch, nahezu immer gibt es schleifen, und da sind 3k schnell erreicht.
    Es bringt also auch nichts es sich schön zu reden dass es nur 3 zehntausendstel sind.
    Die Summe macht es.
    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?
  • Das stimmt natürlich, daß ebentuell Summationseffekte auftreten können.

    Verzögerung kann natürlich vermieden werden oder erwünscht sein, oder eben unerheblich klein sein.

    Das muß eben jeder Programmierer selbst entscheiden, ob er sich die Verzögerung eines Doppelpunktes leisten kann will oder nicht.

    Schönen Gruß.
  • Der Threadtitel heißt "Zeitverzögerung", aber diskutiert wird nur "wie schnell sind Doppelpunkte". Ich dachte, hier kommt mal eine Betrachtung "wie genau kann man Zeitverzögerungen in Basic hinbekommen?" - ich habe damals immer eine leere Schleife zählen lassen, und grob tausend Durchläufe als eine Sekunde verwendet.

    Das ist natürlich beliebig unpräzise, denn es wird schon langsamer, wenn man die Shift-Taste drückt oder mit dem Joystick herum fuchtelt.

    Um mal das Thema Präzision anzugehen, würde ich auf einem PAL-System Frames zählen um eine halbwegs präzise Verzögerung zu bekommen:

    Quellcode

    1. 10 Z=53266:REM aktuelle Rasterzeile, untere 8 Bits
    2. 20 FOR I=0 to 50
    3. 30 WAIT Z,255
    4. 40 NEXT
    5. 50 ?"Eine Sekunde vergangen."
    Bleibt zu prüfen, ob der 60Hz-CIA-IRQ da 'reinhaut, oder ob man besser einen Rasterzeilen-IRQ startet, der gleich noch ne Musik spielen kann, die aber trotzdem keinen Einfluss auf die Präzision hat.

    Jens
    icomp.de/shop-icomp - Online einkaufen und offline bei Rewe, Penny, DM und Weiteren im Laden bezahlen.
  • Es gab mal eine Taschenrechnergeneration die auch Basic konnten.
    Da wurde der : am Anfang dazu benutzt damit der Rechner wusste, es ist ein ''Basic Listing!

    Und der kleine Bif stammt wohl noch aus dieser Zeit! denn beim 64'er bringt der : überhaupt nichts!

    Am TI99/4A sehr wohl!


    Edit: Ich hole mal ein oder zwei 'Eimer Fische
    Gerald ( gh23 )

    ________________________________________
    Stur lächeln und winken Männer

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von gh23 ()

  • @Wiesel:
    Keine schlechte Idee.

    :sys65374: wartet ebenfalls auf den Rasterstrahl.
    Und etwa 1/60 Sekunde.

    10 i=50:fori=-ito-1:sys65374:next

    Schönen Gruß.

    Ansonsten sag ich mal vom TI99/ hab ich leider keine Ahnung.

    Bei mir war´s eher so, je schneller meine Programme wurden, je mehr Doppelpunkte standen plötzlich an erster Stelle.

    Man kann es Schicksal nennen.

    Schönen Gruß.

    Grundsätzlich ist es natürlich der Fall, daß zu langsame Programme tendenziell beschleunigt werden müssen.
    Und schnelle oder zu schnelle Programme verzögert.

    Schönen Gruß.

    Beim Thema Zeitverzögerung sollte vielleich das Thema Zeitverzögerung mit ti nicht fehlen.


    Quellcode:
    1 :i=2:print ti:gosub10:print ti:end
    9 :
    10 :fori=ti+i*60toi:i=ti:next:return:--wart sekunden(i)

    Schönen Gruß.
  • Früher wurde übrigens die strukturierte Programmierung empfohlen.
    Da hat man zur Veranschaulichung der Verschieden Ebenen Doppelpunkte verwendet und noch mit Leerzeichen eingerückt.



    Quellcode:
    1 :i=2:print ti:gosub10:print ti:end
    9 :
    10 :fori=ti+i*60toi:i=ti:next:return:--wart sekunden(i)

    Quellcode:
    0 :rem---demo fuer zeitverzoegerung mit ti
    1 :i=2
    2 :print ti
    3 : gosub10
    4 :print ti
    5 :end
    9 :
    10 :rem---wart sekunden(i)
    11 :fori=ti+60*i
    12 : i=ti
    13 :next
    14 :return


    Schönen Gruß.
  • Huch? :gruebel




    Wenn man schon Leerzeichen fuer bessere Struktur propagiert und damit auch die Lesbarkeit, dann bitte auch konsequent einsetzen:



    Aber dazu gibt's sicher wieder einen biffigen Grund, warum das so sein muss... :D
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • Bin zwar nicht der große Coder, aber kleine Bugfixes bekomme ich hin:

    Quellcode

    1. 0 :rem---demo fuer zeitverzoegerung mit ti
    2. 1 :i=2
    3. 2 :print ti
    4. 3 : gosub10
    5. 4 :print ti
    6. 5 :end
    7. 9 :
    8. 10 :rem---wart sekunden(i)
    9. 11 :forx=.toti+60*i
    10. 12 : x=ti
    11. 13 :next
    12. 14 :return
    Alles anzeigen
    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!