CORE optimieren (CPU Last)
Verfasst: 13. Februar 2012, 09:47
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
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