letzter Beitrag von syshack am
Es wurde auch nie geklärt wieviel Zeitverzögerung ein weiterer Basic-Doppelpunkt-Thread bringt.
Na, das kommt schwer auf das jeweilige Bezugssystem an... Zeit ist ja bekanntlich relativ 
Aber ich würde mal so mit grob 2,75*10-4 sekunden rechnen oder etwa 275 Takte bei gerundeten 1Mhz.
Macht also ca. 137,5 Take pro Punkt. 
vs.
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:
'8551 Ticks'
'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:
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.
Kostet ein ":" gar mehr Zeit als für den nachfolgenden Befehl eine neue Basic-Zeile anzufangen ? (Ist gleich oder eher weniger, oder ?)
Kostet ein ":" gar mehr Zeit als für den nachfolgenden Befehl eine neue Basic-Zeile anzufangen ? (Ist gleich oder eher weniger, oder ?)
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.
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.
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:
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
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
Zeile 9 gefällt mir. Aber sonst...
Huch? 
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...
11 :fori=ti+60*i
12 : i=ti
FOR ohne TO?
i wird immer wieder zugewiesen, so dass NEXT keine vernünftige Zählung macht? Warum dann FOR? Und nicht "if TI>..." ?
Jens
In #13 war die FOR/NEXT--Schleife vermutlich noch lauffähig. Mal schauen, was gegen 04:37 gepostet wird. Da bin ich aber grad kurz Einkaufen...
