CORE optimieren (CPU Last)

[Quietschboy]

Hi,
ich eröffne mal diesen Thread, da ich denke, daß das Thema CPU-Optimierung nicht nur bei mir auf interresse stößt. Klar steht schon viel geschrieben, aber ihr wisst ja wie es ist: Wer suchet findet nicht...
Und nicht nur Live ist jeder CPU Cycle einer zu viel.
Man kann sich mit diversen Modul-Benchmarks ein Loch ins Knie bohren, aber ob das einem in der Praxis hilft ist natürlich wieder ein anderes Blatt. Auch ich mußte nun mit den ersten Versuchen feststellen, daß sich nicht immer feste Aussagen treffen lassen (z.B. ES CONTROL, ROUTER). Es kommmt scheinbar auch darauf an, wie etwas mit etwas anderem Verknüpft ist. Hier sollten also optimierte Lösungen zu praxisnahen Beispielen erläutert werden.

Ich mache hier mal einen Anfang mit dem Thema "Asynchrone Events in einer Audio Cell". Also über nicht zur Sample Clock synchronisierte Events, welche nunmal zwangsweise über Event Ins hereinpurzeln. Wobei natürlich folgende Frage auftaucht: Gibt es auch Fälle, in denen ein Event über ein Event In schon synchron zur SR.C eintrifft? Außer dem Zufall? Kann es diesen Zufall überhaupt geben? Oder sind in PRIMARY SR.C getriggerte Events (z.B. mittels SINGLE DELAY) automatisch auch synchron zur Clock in einer CoreAudioCell?
Grund für mein Thema war, daß ich das Gefühl hatte, daß die Berechnerei asynchroner Events in einer AudioCell mehr CPU kostet. Das scheint so nicht der Fall zu sein.
Aber dafür stelle ich mal folgende Behauptungen auf:

1. EVENT INs sollten VOR der ersten Berührung (incl. OBC) mit einem SR.C getakteten Part innerhalb der AudioCell synchronisiert werden um CPU Last zu sparen. Also spätestens vor dem Audioausgang.
2. Die Kombination READ(int)/COMPARE [Integer>0] schlägt Kombination READ(float)/WRITE(float) (siehe Modul "LATCH ONCE" im Testensemble).

Aber schaut es euch selbst an.
Der eigentliche Knackpunkt des "besser vorher syncen" ist in Bench 2 und 3 recht anschaulich nachzuvollziehen.
Viele Grüße, Mark

[herw]

Ich kann leider den Benchmarktest nicht verwerten, da sich mein Laptop vorgestern verabschiedet hat.
Ohne dass ich das ensemble gesehen habe, kannst du etwas über deine Testmethode schreiben?

Ciao herw

[Quietschboy]

Ja klar, gerne!
Gemessen habe ich mit 1024 Voices bei 88,2kHz.
Jede Benchmarkversion und die einzelnen Testzellen sind mit Switches getrennt /anwählbar. Als Eingangsquelle dient die CR.C des System Info Modul.

Async vs Sync - leere Audiozelle.jpg

Wird der CR.C Eingang ausserhalb der CoreZellen unterbrochen (Router), oder sogar ganz abgekabelt, ist das Bild bis auf ein klein wenig gesunkene CPU Last fast identisch:
Die unsynchronisierte Variante verbrät mehr Strom.

Im folgenden Beispiel trifft der Eventeingang auf eine "Audioleitung":

Async vs Sync - Event trifft Audio - Bench3.jpg

Hier noch mein Sync Macro von innen:

Latch Once.jpg

Nunja, ganz euphorisch hatte ich gestern in meinem Projekt noch versucht die ganzen Event Eingänge (15 Stück) in der Haupt-CoreAudioCell direkt am Anfang zur SR.C zu syncen. Das ganze ging voll nach hinten los, wobei ich weniger auf den CPU Verbrauch geachtet hatte. Das Problem war viel mehr, daß die CoreCompilierung/Vorinitialisierung (?) mit steigender Anzahl gesyncter Eingänge immer endloser ratterte (roter Balken unter der CPU Last Anzeige). Die Struktur innerhalb der Zelle ist recht verzweigt und alles hängt irgendwie mit allem zusammen. Neulich hatte ich schon einmal dieses Problem und hatte es dadurch gelöst, daß ich an einer Stelle eine Addition mit nem Latch erweitert habe (also Modulationsaddition). Scheint wohl so ein Problem nach der Art zu sein: "A hängt von B ab, hängt von A ab...".
Wenn das jemand von euch in konkretere Worte fassen könnte wäre ich dafür sehr, sehr dankbar. Irgendein Hinweis wonach ich suchen muß...

Gruß Mark

[herw]

Leider habe ich noch nicht mein Laptop zurückbekommen, sonst würde ich im partials framework suchen. Dort gibt es ein Dokument über threadsafeness. Ich meine, ich hätte es schon einmal hier oder im englischen Forum hoch geladen.
Es gibt im pratials framework dazu entsprechende Makros, soweit ich mich erinnern kann im Unterordner "System".

Ciao herw

PS: ich hab's gefunden:
http://www.reaktor.approx.de/phpbb3/vie ... =856#p7183

Das skript ist in englisch geschrieben, aber ich denke, Schulenglisch und eventuell ein Wörterbuch oder LEO ( http://dict.leo.org/ende?lang=de&lp=ende ) reichen aus.

[Quietschboy]

"Any event caused by the control rate clock or midi data will always be processed in the audio thread."
Ich sehe da so erstmal nichts im Gui-Thread verschwinden, falls du darauf hinaus willst, da ja die CR.C triggert. Die Thread Safeness Sachen hatte ich mir schonmal angeschaut, der Text (Thread_Problems.pdf) ist recht anschaulich, aber die Makros habe ich lieber direkt wieder zugeklappt
...erstmal. Sehr kyrillsch, dat Janze. So wie ich es bis jetzt verstanden habe, ist das mit der Thread-Verteilung erst problematisch, wenn Eventstreams auf einer Leitung davon betroffen sind, also z.B. bei Multiplexing. Und zwar dann, wenn ein Event nicht zu ende gerechnet werden kann, bevor der andere Thread auf der selben Strippe aktiv wird.
Dein Link führt übrigens in einen abgeschlossenen Bereich.
{danke, ich hab den Link geändert - herw}

Neues Thema: "Eine CORE Cell logisch gliedern"
Seht ihr das denn auch so, daß eine Core Cell nach jeder Änderung ersteinmal einmalig kompiliert, zusammengebacken wird? BEVOR die eigentliche Initialisierung stattfindet? Vielleicht so, daß sie aus Primary Sicht quasi ein festes Modul darstellt?
Inzwischen hatte ich mich noch weiter mit dem Latching innerhalb einer Core Cell beschäftigt. Eigentlich steht es ja alles im Handbuch, man muß wohl nur erstmal selbst auf die Problematik stoßen um zu schnallen, was der Schreiberling damit sagen will. Core Handbuch 5.6.2 Kapitel 9 "Building optimal structures": "Using latches has to do both with performance optimization and the correctness of your structures."
ALso das Latchen dient nicht nur einfach dazu z.B. herumwildernde Events aufzufangen, sondern auch, und das scheint ein echter Knackpunkt zu sein, die Struktur durch Unterteilung in ABSCHNITTE mittels Latches logisch zu gliedern und somit der CORE KOMPILIERUNG (?) und der ABARBEITUNG im Betrieb die Arbeit zu erleichtern. DAS bringt echten CPU Vorteil. Obwohl keine mathematischen Operationen eingespart werden. Hier ein Latch, da noch ein Latch und schon haste 1/4 weniger CPU Last...
"If you split the event path into two branches using a Router, it’s a good idea to merge the branches generated by the outputs of the Router"
Man kann wohl als Faustregel festhalten: Führe die "Branches", also Verzweigungen, von Routern (oder auch "normale" Verzweigungen?) möglichst bald wieder zusammen. Das ist aber so nicht immer machbar. Aber so wie es mir jetzt scheint, tut dies anstatt eines Mergers, oder einer mathematischen Operation eben auch ein Latch. Genauergenommen die OBC Verbindung (?). Sie unterbricht oder anders gesagt, beendet eine Verzweigung, WENN das Read Modul des Latch mit der Quelle vor der Verzweigung oder der anderen Verzweigung oder einer gemeinsamen Clock verknüpft ist. Oder, oder, oder?!?!?!?!
Ich hoffe ihr könnt mir folgen, worauf ich anspreche. Und ich stelle hier lediglich Behauptungen auf. Ihr könnt auch alles, was ich hier bisher geschrieben habe, sehr gerne als Fragen verstehen!!!

Ich finde, ein paar Faustregeln, zur logischen Unterteilung einer Corestruktur würden diesem Thread aber sehr gut stehen
Nicht jeder Latchtrigger führt zum erwünschten Erfolg, obwohl die Quelle des Triggers und der zu latchenden Verzweigung die Gleiche ist (oder doch nicht?).
Spielen Macrogrenzen (Solid) eine Rolle? Sollte man vor den Ausgängen eines Macros "zusammenlatchen" und oder auch am Anfang des Makro, oder besser noch vor einem Makro in der übergeordneten Struktur?
Sind große Differenzen der Anzahl mathemathischer und logischer Operationen zwischen den Verzweigungen das Problem? Machen "in der Luft hängende" Abschnitte Probleme? Also solche, die irgendwie nicht eindeutig initialisiert oder auch kompiliert werden können(?), z.B. eine Leitung zwischen einem READ und einem WRITE nach einem R/W hinter einem Router? Oder so ähnlich. Hab da so´ne Vermutung.
Fragen über Fragen. Ich belasse es erst mal dabei und werde noch ein bischen rumdoktern.

Mark
P.S. Herw, bez. deinem Schleppi: Welches Ruhr-Preset war´s denn?

[Quietschboy]

Noch ein kurzer Zwischenwurf, "OBC Ketten richtig initialisieren", der zwar mit CPU Optimierung nichts zu hat, aber einen Bug in CORE umgeht und so auch dem Handbuch zu entnehmen ist. Wurde auch schon hier im Forum angesprochen. Hier noch der original Thread ausm englischen, welcher inzwischen leider geschlossen ist, aber das Problem besteht heute mit R5.6.2, fast 6 Jahre später, immer noch. Die Lösung ist dem Thread nicht zu entnehmen (es sei denn ich habs überlesen): http://www.native-instruments.com/forum ... hp?t=36658 - "What the hell does this mean ?"
Die Initialisierungskonstante für eine OBC-Kette muß an einem Write GANZ AM ENDE DER KETTE stattfinden:

OBC Initialisierung.jpg

[herw]

Noch ein kurzer Zwischenwurf, "OBC Ketten richtig initialisieren", der zwar mit CPU Optimierung nichts zu hat, aber einen Bug in CORE umgeht und so auch dem Handbuch zu entnehmen ist. Wurde auch schon hier im Forum angesprochen. Hier noch der original Thread ausm englischen, welcher inzwischen leider geschlossen ist, aber das Problem besteht heute mit R5.6.2, fast 6 Jahre später, immer noch. Die Lösung ist dem Thread nicht zu entnehmen (es sei denn ich habs überlesen): http://www.native-instruments.com/forum ... hp?t=36658 - "What the hell does this mean ?"
Die Initialisierungskonstante für eine OBC-Kette muß an einem Write GANZ AM ENDE DER KETTE stattfinden:

OBC Initialisierung.jpg

Der WhatTheHell-Bug basiert auf einer Idee von Krümelmonster (Gerald List).
Es zeigt eine sehr ungewöhnliche Ausnahmesituation, die aber durchaus gängig ist. Der Bug ist sogar noch komplexer als er allgemein beschrieben wird.
Im Beta- und Alphatester-Team wurde das ausführlich diskutiert und der Fehler ist auch erkannt.
Die Beseitigung ist allerdings wohl nicht so einfach, da dann der Quelltext doch in einiger Tiefe verändert werden muss.
Die Lösung ist aber wohl bekannt. Falls es dich interessiert, kann ich da noch ein etwas genaueres Beispiel hier hochladen. Ein Bugfix wird aber nicht aus den Augen gelassen.

ciao herw

[herw]

P.S. Herw, bez. deinem Schleppi: Welches Ruhr-Preset war´s denn?

Es war das snap pure heavy (unison) in meiner neuen Snapbank.
Jetzt läuft mein Schleppi wieder in alter Frische (neues Motherboard), leider ziemlich teuer eine solche Reparatur, aber immer noch preiswerter als ein neues PowerBook.

alles unnötige Ausgaben
ciao herw

[herw]

[...]
Aber dafür stelle ich mal folgende Behauptungen auf:

1. EVENT INs sollten VOR der ersten Berührung (incl. OBC) mit einem SR.C getakteten Part innerhalb der AudioCell synchronisiert werden um CPU Last zu sparen. Also spätestens vor dem Audioausgang.
2. Die Kombination READ(int)/COMPARE [Integer>0] schlägt Kombination READ(float)/WRITE(float) (siehe Modul "LATCH ONCE" im Testensemble).

Aber schaut es euch selbst an.
Der eigentliche Knackpunkt des "besser vorher syncen" ist in Bench 2 und 3 recht anschaulich nachzuvollziehen.
Viele Grüße, Mark

hmm bei mir kann ich kaum Unterschiede feststellen. Beim 3. Benchmarktest ist der erste asynchrone Fall etwas besser.
Gesicherte Ergebnisse lassen sich nicht machen, da die bloße CPU-Anzeige von REAKTOR nicht besonders aussagekräftig ist; vergleiche Max Zaglers Ausführungen im Dokument über thread-safeness.

Die Testmöglichkeiten, die uns Normalverbraucher zur Verfügung stehen, sind leider nicht eindeutig und zuverlässig.
Trotzdem ein interessanter Test und ich freue mich, dass sich auch mal jemand für die Theorie und den Background interessiert.

ciao herw

[Quietschboy]

Falls es dich interessiert, kann ich da noch ein etwas genaueres Beispiel hier hochladen.

Ja, gerne.

Trotzdem ein interessanter Test und ich freue mich, dass sich auch mal jemand für die Theorie und den Background interessiert.

Also, so wie ich als Kind gerne Kasettenrekorder kaputtrepariert habe, würds mich heute auch echt reizen, den Reaktor mal aufzuschrauben. Aber da hätte ich Angst, daß er hinterher nicht mehr funktioniert...
Aber gerade das Thema mit dem Latching ist bei großen, verzweigten Cells so bedeutend für die Performance, daß man es nicht einfach mißachten kann. Vor allem dann, wenn ohne die richtigen Latches die Kompilierung der CoreCell bei jeder Änderung den Rechner für mehrere Sekunden lahmlegt. Und wenn das bewußte Setzen von Latches nunmal eine tiefere Kenntnis über die Kompilierung des Codes und seines Ablaufs vorraussetzt... ja, dann bitte immer her damit
Schade, daß NI dazu im Handbuch nicht mehr erklärt hat. Wenigstens den einen oder anderen Kniff, oder NO GOs. Ja, ich weiß, haben sie ja im Prinzip, aber es hätte bestimmt mehr dazu zu sagen gegeben.
Alles muß mer aber auch immer selbst machen. Ich kann so nicht arbeiten!

[herw]

Falls es dich interessiert, kann ich da noch ein etwas genaueres Beispiel hier hochladen.

Ja, gerne.

Trotzdem ein interessanter Test und ich freue mich, dass sich auch mal jemand für die Theorie und den Background interessiert.

Also, so wie ich als Kind gerne Kasettenrekorder kaputtrepariert habe, würds mich heute auch echt reizen, den Reaktor mal aufzuschrauben. Aber da hätte ich Angst, daß er hinterher nicht mehr funktioniert...
Aber gerade das Thema mit dem Latching ist bei großen, verzweigten Cells so bedeutend für die Performance, daß man es nicht einfach mißachten kann. Vor allem dann, wenn ohne die richtigen Latches die Kompilierung der CoreCell bei jeder Änderung den Rechner für mehrere Sekunden lahmlegt. Und wenn das bewußte Setzen von Latches nunmal eine tiefere Kenntnis über die Kompilierung des Codes und seines Ablaufs vorraussetzt... ja, dann bitte immer her damit
Schade, daß NI dazu im Handbuch nicht mehr erklärt hat. Wenigstens den einen oder anderen Kniff, oder NO GOs. Ja, ich weiß, haben sie ja im Prinzip, aber es hätte bestimmt mehr dazu zu sagen gegeben.
Alles muß mer aber auch immer selbst machen. Ich kann so nicht arbeiten!

Ich finde das selbstständige Forschen gerade so interessant.
Den WhatTheHell-Bug (er läuft tatsächlich unter diesem Namen) habe ich schon herausgesucht, muss ich aber ein wenig auf- und nacharbeiten, da es schon einige Zeit zurück liegt.

Gerald besucht mich am Wochenende, so dass ich das auch nochmals mit ihm durchsprechen kann.

ciao herw