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:
route audio A.jpg
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:
route audio B.jpg
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:
route audio C.jpg
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