Langer CC...

[CapSeb]

Der Maker arbeitet anscheinend in einem Rechentakt immer einen Befehl pro parallel Event (wartet also wahrscheinlich diesen Takt lang bis alle Events einen Schritt weiter sind).

...

Deine erste Fehlvermutung ist das ein Makerbefehl lediglich einen Rechentakt benötigt. Wenn wir nun von der maschinennahen Sprache Assembler ausgehen, dann sieht man hier das für gewisse Operationen mehr als ein simpler Rechentakt benötigt wird. Und wir reden von eher "simplen" Dingen wie bspw. zwei Register voneinander abzuziehen.

...

Gut, ich meinte auch nicht die Prozessortaktung oder sowas, sondern eine vom Maker erzeugte Taktung. Wie ein Echtzeitkampf, der intern rundebasierend ist. Sonst wäre ein "Warten" auch nicht möglich (Switchänderungen, Variablen... dauernd gleich lang).

Das ganze passiert auf jeden Fall schnell genug um eine gewisse parallele Verarbeitung vorzutäuschen. Man sieht diesen Effekt recht gut wenn man versucht zu große PPs laufen zu lassen. Schon hat man den berühmten Ruckeleffekt wegen dem die Leute manchmal Wait 0.0 an ihre PPs hängen.

...

Der Maker ruckelt weil zwischen den Events hin- und hergeschaltet wird? Und warum nur bei großen PPs - bei kleineren muss er dann doch auch hin- und her schalten?!

Augenscheinlich scheint der Maker alles Zeile für Zeile einzulesen. Ergo wird wohl markiert sein welche Teile zum ELSE CASE gehören und welche eben nicht. Diese werden zwar kurz gelesen, aber dann wohl einfach übersprungen. Immerhin ist die Funktion des Zweiges das eben dies geschehen soll.

...

Hm, aber warum benötigt er dann für dieses Überprüfen des Elses so lange? Schließlich wartet er bei anderen Befehlen den besagten Takt.

Aber schonmal gut zu wissen, dass er springt.


CapSeb

[makenshi]

Der Maker ruckelt weil zwischen den Events hin- und hergeschaltet wird? Und warum nur bei großen PPs - bei kleineren muss er dann doch auch hin- und her schalten?!

...

Nein. Der Maker ruckelt nicht weil er zwischen Events hin- und herschalten muss. Jedenfalls nicht im Normalfall. Wenn zu viele performanceträchtige Befehle hintereinander ausgeführt werden müssen (wie z.B. Show Picture), dann braucht der Maker logischerweise länger um diese Befehle zu verarbeiten. Ergo kann er den Befehl nicht schnell genug zuende bearbeiten und zum nächsten Event schalten. Da trotzdem alles in seinen geordneten Wegen laufen muss, werden die Befehle trotzdem weiter bearbeitet. Es dauert nun länger bis "normal" weiter gearbeitet werden kann. Und halt auch bis zum nächsten Befehl umgeschaltet wird. Und schon bemerkst du diese Arbeit. Eben als Verzögerung.

Hm, aber warum benötigt er dann für dieses Überprüfen des Elses so lange? Schließlich wartet er bei anderen Befehlen den besagten Takt.

...

Das es für dich so lange dauert, liegt an deiner Messmethode.
Die für so etwas simpel nicht geeignet ist. Die einzige wirklich ernst zunehmende Möglichkeit um so etwas zu messen, ist es ein zweites Programm nebenbei mitlaufen zu lassen. Dieser kann dann genau im internen messen wie lange die Anwendung für bestimmte Vorgänge benötigt. Aber bestimmt nicht dadurch das du solche Messungen versuchst im Programm selbst vorzunehmen.
Bei den makerinternen Dingen wie bspw. den Bewegungsgeschwindigkeiten geht das wunderbar. Aber nicht bei so etwas. Das sieht man ja an deinen Messergebnissen.

Aber schonmal gut zu wissen, dass er springt.

...

Wie schon gesagt, es gibt ohne einen zweiten CPU Kern der andere Befehle bearbeiten kann kein echtes paralleles arbeiten. Das wird vom PC nur vorgetäuscht. An sich eher vom OS um genauer zu werden. Wenn dich diese Thematik so interessiert, dann solltest du dich einmal mit der Thread programmierung auseinandersetzen. Da erfährst du mehr über dieses Prinzip.

An sich aber brauchst du so etwas nicht wirklich für den Maker imo.
Da reicht an sich das grobe Wissen das parallele Prozesse "gleichzeitig"
arbeiten. Und natürlich wie die Eventaktivierung von statten geht.
Wer so etwas versteht, wird mit dem ganzen Eventsystem kein Problem haben.