Deutsches Reaktor Forum

ziemlich basic und klar in der Funktion.

Man ließt jedoch oft in Foren und auch im Coremanual, dass den Routern grosse Wichtigkeit zukommt was CPU Auslastung betrifft.
Dazu kommt, dass die Boolean Verbindung zwischen dem Compare und dem Router wenig dokumentiert ist. Dazu meine Frage:

folgender Fall:
USER:ON/OFF ist hier eine Eventleitung prozessiert das Comparemodul hier jedes mal wenn ein "event" am Eingang des Routers anliegt? hier also zu jeder Audioclock.

früher dachte ich Nein, denn im Router selber passiert ja nichts wenn kein Userbefehl kommt, dass heisst er muss ja nicht "umschalten"

doch nun bin ich da eher anderer meinung. Dazu müsste man genau wissen was in der Boolean Leitung passiert. Ferner kann man das Compare Modul auch nicht als normales Modul bezeichnen da es keinen Ausgang besitzt welcher von einem anderen ausser dem Router verwertet werden kann.

Meine Vermutung: Jedes mal, wenn ein Event am Routereingang anliegt "fragt" die Boolean Leitung das Compare was da loß ist. Das Compare prozessiert daraufhin den Vergleich. d.h. beide Module haben ihren vollen Job zu jeder SR.C

in grossen Corezellen wird das dann wichtig wenn man entscheidet wie "zentralistisch" man solche Abfragungen in die Atuktur integriert. Aber wie gesagt, alles nur Vermutung.
kann das irgendwer bestätigen oder verneinen?

Das Compare-Modul wird tatsächlich nur on-demand ausgeführt.
D.h.: nur wenn am Signal-Eingang des Routers etwas reinkommt was geroutet werden muss, wird wird das Comparison-Modul ausgeführt um die Entscheidung zu fällen.

Das trifft allerdings nur auf das Comparison Modul selbst zu. Wenn vor dem Vergleich Berechnungen notwendig sind, werden die arithmetischen Module immer dann ausgeführt, wenn sie ein eingangssignal bekommen (das ist ja das normale Verhalten von Reaktor Core).

Allgemein sollte man aber bedenken, dass der primäre Runtime-Overhead eines Routers aus der Branch-Misprediction stammt. Im Vergleich dazu sind die Kosten eines Vergleiches absolut vernachlässigbar. Das Thema sprengt aber hier den Rahmen. Es ist überhaupt nicht Reaktor-spezifisch und im Internet umfassend dokumentiert.

NNemec hat geschrieben:Das Compare-Modul wird tatsächlich nur on-demand ausgeführt.
D.h.: nur wenn am Signal-Eingang des Routers etwas reinkommt was geroutet werden muss, wird wird das Comparison-Modul ausgeführt um die Entscheidung zu fällen.

Das trifft allerdings nur auf das Comparison Modul selbst zu. Wenn vor dem Vergleich Berechnungen notwendig sind, werden die arithmetischen Module immer dann ausgeführt, wenn sie ein eingangssignal bekommen (das ist ja das normale Verhalten von Reaktor Core).

Allgemein sollte man aber bedenken, dass der primäre Runtime-Overhead eines Routers aus der Branch-Misprediction stammt. Im Vergleich dazu sind die Kosten eines Vergleiches absolut vernachlässigbar. Das Thema sprengt aber hier den Rahmen. Es ist überhaupt nicht Reaktor-spezifisch und im Internet umfassend dokumentiert.

Vielen Dank Norbert für die schnelle und direkte Antwort.
(Norbert Nemec leitet das Software Developer-Team bei NI). Das war also Information aus erster Hand.
ciao herw

klasse!

vielen Dank für die Antwort, das bringt mich einige Schritte weiter!

Eine ähnlich wichtige Frage stellt sich mir bei der Gestaltung meiner Stukturen und deren Gliederung. Es geht um "die eine grosse" Corezelle die alles macht.
Inwieweit bestimmt die Stuktur und Hierarchie der Zelle wie sie bei Reaktor erstellt wird den Compilierungsvorgang? Wird alles entsprechend der Graphischen Ordnung berechnet oder werden die Karten komplett neu gemischt?
Folgendes hat mich auf die Frage gebracht: Der clock eingang des "Read" modules ist float und der Wert wird ignoriert. Daher vermute ich (oder hab irgendwo gelesen), dass die Umrechnung von INT zu float nicht stattfindet falls ein Integersignal als clock verwendet wird. Angenommen dieser Clockeingang wird wie beim Latch nach aussen geführt wird (float) und wiederum mit einem Integersignal verbunden; "Weiss" der Clockeingang des Latches, dass es dem enthaltenen "Read" egal ist ob float oder integer? Oder wird unabhängig davon das signal gewandelt? Ich glaub die grundlegende Frage ist: Behandelt der Compiler Zellenein- und ausgänge als Module oder sind diese nur für die Optische Ordnung für uns da?

Vielen, vielen Dank auch von mir an Norbert!

Hallo MVKeinen,
du stellst ja genau die richtigen, quälenden Fragen, die auch mich schon länger beschäftigen (die ich mich aber nie getraut habe zu stellen...).
Was ich jetzt schreibe hat mit Fachwissen absolut nichts zu tun! Ich denke einfach nur mal laut. Bitte mit Vorsicht genießen.
Aus dem Handbuch und den Foren habe ich mir schon gedacht, daß das Compare Modul (leider) mit jedem Event am Router-Eingang abgefragt wird. Aber warum die Länge der Verzweigungen so eine große Rolle spielt war mir echt ein Rätsel. Und vorallem: Wie kann man lange "Branches" verhindern? Oder wie kann man lange Branches in den Griff kriegen? Nehmen wir mal als einfaches Beispiel ein Audiosignal, das verdammt lange arithmetische Berechnungen plus einige Reads und Writes in Arrays durchführen muß. Und zwar in beiden Verzweigungen des Routers.
Die einfachste Variante würde doch so aussehen: Nach kurzem Überfliegen des deutschen und englischen Wikipediaartikels dazu, drängt sich natürlich die Frage auf, wie in Reaktor die branch prediction (also die Sprungvorhersage) getroffen wird. Statisch oder dynamisch oder sonst wie? Hallo Norbert, bist du noch bei uns?
http://de.wikipedia.org/wiki/Sprungvorhersage
Vielleicht würde auch so oder so folgende Variante weiterhelfen: Eine Verzweigung führt jeweils ins Nichts und die andere in die Berechnungen. Wenn in diesem Fall IMMER die Verzweigung mit den arithmetischen Berechnungen in die Pipeline geladen würde, müßten dann lediglich die nicht "gebrauchten", also die des verworfenen Pfades, wieder aus der Pipeline geschmissen werden. Ein Nachladen von Instruktionen entfiele. Und ich denke mal löschen, bzw. überspringen geht schneller als nachladen.

Wenn man nun wirklich ganz genau bescheid wüßte, also die Wahrscheinlichkeit der Sprungvorhersage, sämtliche CPU-Cycles der Berechnungen, und was sonst noch alles dazugehört, wäre diese Variante mit sehr kurzen Branches vielleicht auch noch eine Lösung: Dabei müßte man dann also die Kosten für die zusätzlichen, aber unnötigen, arithmetischen Berechnungen gegen die Wahrscheinlichkeit der falschen Verzweigung und des Nachladens in die Pipeline aufwiegen können...


Was die Macrogrenzen angeht, kann ich auch nur mutmaßen.
Soweit ich gelesen habe, ist es wohl tatsächlich so, daß ein Integer an einem InPort NICHT nach float gewandelt wird, wenn darauf ein READ folgt (also ein rein Event-sensitiver Eingang). Frag mich nicht warum ich trotzdem noch alle Latch Triggereingänge bei INT auch auf INT stelle

Das Z-1 funktioniert nur dann als Feedback-Unterbrecher, wenn es nicht auf "Solid" gestellt ist. Das ist gleichbedeutend mit einer einfachen READ-WRITE OBC Verbindung die nicht in ein Macro verpackt ist. Stellt man das z-1 auf "Solid", mußt du das Makro von außen als BlackBox betrachten: Es geht was rein und im selben Zyklus auch was raus! Eine Feedbackschleife wird also nicht unterbrochen. Das Makro wird als ganzer Kloß an entsprechender Stelle in den Programmablauf eingebunden. Oder andersherum ausgedrückt denke ich, daß man "nicht solid Makros" als rein optische Behälter betrachten kann. Ob dann die Art der In- und OutPorts (INT-float) auch nur optischer Natur ist, bezweifle ich aber mal.
Gruß, Mark

Noch was zu den Routern:
Laut Max Zagler´s Beschreibungen zu den Partials Frameworks ist es auf jeden Fall ratsam mehrere Linien, die derselben Compare Funktion unterliegen, über Latches zu triggern anstatt mehrere Router zu verwenden:

Vielen Dank Quietschboy für die Ausführungen! Das ist sehr hilfreich Auch wenn es wieder mehr Fragen aufwirft

Es ist vielleicht schwierig das Ganze auf eine einfache Lösung runterzubrechen. Wenn jetzt wie in Deinem letzten Beispiel ein schon gerouteter Eventstream einen anderen "Latcht" kann es sein, dass dadurch die Ladezeit der Corezelle ansteigt, je nachdem wie oft das passiert. Ich habe da aber noch nicht genügend Versuche gemacht, auch in verbindung mit dem Editmode. Wenn es jedoch CPU spart bin ich gerne bereit etwas mehr Ladezeit zu haben.

MvKeinen hat geschrieben:Vielen Dank Quietschboy für die Ausführungen! Das ist sehr hilfreich Auch wenn es wieder mehr Fragen aufwirft

Es ist vielleicht schwierig das Ganze auf eine einfache Lösung runterzubrechen. Wenn jetzt wie in Deinem letzten Beispiel ein schon gerouteter Eventstream einen anderen "Latcht" kann es sein, dass dadurch die Ladezeit der Corezelle ansteigt, je nachdem wie oft das passiert. Ich habe da aber noch nicht genügend Versuche gemacht, auch in verbindung mit dem Editmode. Wenn es jedoch CPU spart bin ich gerne bereit etwas mehr Ladezeit zu haben.

meine Güte, ihr geht aber an's Eingemachte!
Jetzt fehlen nur noch richtige Testprotokolle

Ich konnte jetzt einige Versuche machen. Allerdings handelt es sich um eine Eventzelle. Diese ist relativ komplex und beinhaltet mehrere Chain Iterationen von M.Zaglers Partial Framework.

hier geht es ausschließlich um die Ladezeit bei Initialisierung.

Behauptung hat geschrieben: Vor der Zusammenführung von Zweigen deren Trennung weit flussaufwärts stattgefunden hat ist es wichtig diese miteinander zu synchronisieren.

so konnte ich bei einer Funktion die bei schneller Mausbetätigung Werte interpoliert (was ähnliches gab es schon länger irgendwo in der UL) die Ladezeit bei Initialisierung von 14 auf 3.5 Sekunden senken. Edit-modus

dazu kommt, dass die Ordung die sich einem dadurch "aufzwängt" ziemlich effizient sein kann.