DAW - Prozessorkerne und Lastverteilung

[Plasmatron]

Also die Programme machen das unterschiedlich und das zu vergleichen, darum geht es hier gerade.

 

[Klinke]

"pro plug-in" ist also nicht im geringsten besser als "pro mixer kanal" (mit ausnahme des themas "masterbus")

Angenommen dass auf einem Mixer Kanal soviele FXs sind, dass diese nicht in Echtzeit von einem einzigsten Core berechnet werden kann, so ist dies hingegen trotzdem möglich, falls ein Thread pro plug-in erzeugt wird (ohne zusätzliche Latenz hilft das allerdings nur, wenn der Kanal nur aufgenommenes Material abspielt).

eine hochintelligente, dynamische verteilung, die stets die ideallinie findet um den rechner auszunutzen, indem prozesse anhand ihrer cycles um-zugewiesen werden, wäre nicht nur kompliziert zu bauen, sondern das funktioniert vor allem auch nur mit statischen effekten.

Das thread scheduling sollte die DAW auch dem OS überlassen (und ich bin mir ziemlich sicher, dass das alle auch so handhanben), warum das Rad nochmal erfinden? Thread pinning kenne ich eigentlich nur im Bereich von Supercomputern, da kann das vor allem bei einer NUMA Architektur sinnvoll sein. Auf den Nodes läuft dann aber auch tatsächlich nur die Simulation und nicht z.B. mal zwischendurch auch noch irgendein OS-Update(check) und ähnliches im Hintergrund.

 

[Jörg Funkelt]

Wo schalte ich in live 12 Multi Core ein oder aus? Ich finde es beim besten Willen nicht.

 

[Klinke]

Wo schalte ich in live 12 Multi Core ein oder aus? Ich finde es beim besten Willen nicht.

Ich kann mich bei Live nicht an eine entsprechende Einstellung erinnern (ist aber eine Weile her, das ich es benutzt habe).

 

[einseinsnull]

Angenommen dass auf einem Mixer Kanal soviele FXs sind, dass diese nicht in Echtzeit von einem einzigsten Core berechnet werden kann, so ist dies hingegen trotzdem möglich, falls ein Thread pro plug-in erzeugt wird (ohne zusätzliche Latenz hilft das allerdings nur, wenn der Kanal nur aufgenommenes Material abspielt).

ja, das ist klar.

nur wieviele leute haben im echten leben mehr kerne als offene plug-ins?

die frage ist ja immer wohin das anzahlderkerne+1te zugewiesen wird.

bei "pro plug-in" bist du schneller reihum, und das erzeugt wieder neue probleme.

was natürlich in der host logic mist ist sind die fehlenden dedizierten instrument-slots.

Das thread scheduling sollte die DAW auch dem OS überlassen

technisch betrachtet ist das sicher so, nur man muss es halt erst mal überhaupt irgendwie einbauen.

interesssant in dem zusammenhang ist der vergleich von PC prozessen mit den alten 56k beschleunigern wie powercore oder TDM. so wie dort würde der anwender sich das mit der lastverteilung wünschen.

nur läuft dort halt nicht im hintergrund noch ein browser, ein filsharing client, und nebenher noch ein zweites audio programm, dort ist jedes plug-in sein eigener prozess.

 

[einseinsnull]

Also die Programme machen das unterschiedlich und das zu vergleichen, darum geht es hier gerade.

nagut, kommen wir wieder ontopic.

bei "DAWs" dürfte man sich das ergooglen können, aber vorsicht mit den programmversionen.

ich kann nur was unorthodoxes beitragen. in max gibt es zwei grundsätzliche möglichkeiten.

die eine ist, dass bei polyphonischen subcircuits automatisch round robin mit den stimmen/instanzen erfolgt.

die andere ist, dass jedes top level fenster in einem eigenen thread läuft, im regelfall ist das ein kern oder ein doppelkern, je nach architektur.
so kann man einen sehr teuren prozess relativ einfach auf den nächsten kern schieben, indem man ihn in ein kleines (oder unsichtbares, oder außerhalb des monitors befindlichen) fensters verschiebt und seine signale dort hin routet. im falle von plug-in hosting gilt das dann natürlich auch für die.

hyperthreadingfunktionen von plug-ins selbst werden aktuell nicht unterstützt.

 

[Klinke]

ja, das ist klar.

nur wieviele leute haben im echten leben mehr kerne als offene plug-ins?

die frage ist ja immer wohin das anzahlderkerne+1te zugewiesen wird.

bei "pro plug-in" bist du schneller reihum, und das erzeugt wieder neue probleme.

Das ist das Problem des OS, nicht das der DAW. Und je kleiner die Aufgabe des Threads ist, umso besser kann das OS die Verteilen. Hat nur den Tradeoff, dass viele kleine Threads mit entsprechenden Threadwechsel auch wieder Performance kosten. Der Ansatz von Bitwig die Plugins in einzelne Prozesse anstatt in Threads zu stecken ist auch nicht uninteressant, da dann ein Plugin nicht die DAW crashen kann (geht in Reaper übrigens auch optional, sogar einzeln per Plugin einstellbar), kostet aber halt noch mehr Performance. Aber natürlich überläßt auch Bitwig die Zuteilung des Prozesses (bzw. der Threads des Prozesses) dann dem OS.

technisch betrachtet ist das sicher so, nur man muss es halt erst mal überhaupt irgendwie einbauen.

Was bitte schön möchtest Du da einbauen? Du (bzw. die DAW) startest den Thread und dann kümmert sich das OS um den Rest. Und Threads zu erzeugen ist ja nun wirklich keine Raketenwissenschaft.

 

[Plasmatron]

Ich kann mir vorstellen das es im Falle Logic auf das Alter und den Kern der Software hinausläuft, der - wahrscheinlich- immer weiter geschrieben wurde und dadurch alte Zöpfe mitnimmt. Wissen tue ich es nicht

 

[einseinsnull]

Das ist das Problem des OS, nicht das der DAW.

wie die daten verteilt werden ist zunächst mal einfch ein logisches problem.

und es machst absolut sinn, dass von der DAW aus einzustellen genau wie man ja auch das audio und midi IO von der DAW aus einstellt, obwohl es bestadneteile des betriebssystems sind.

Und je kleiner die Aufgabe des Threads ist, umso besser kann das OS die Verteilen. Hat nur den Tradeoff, dass viele kleine Threads mit entsprechenden Threadwechsel auch wieder Performance kosten.

klein genug sind wir mit unseren audio zum glück.

aber 100 plug-ins auf 100 kernen laufen lassen will man echt nicht, dann geht wohl das allermeiste schon nur fürs verteilen drauf.

ansonsten wäre die aufgabe für die hersteller ja supereinfach zu lösen.

Aber natürlich überläßt auch Bitwig die Zuteilung des Prozesses (bzw. der Threads des Prozesses) dann dem OS.

Was bitte schön möchtest Du da einbauen? Du (bzw. die DAW) startest den Thread und dann kümmert sich das OS um den Rest. Und Threads zu erzeugen ist ja nun wirklich keine Raketenwissenschaft.

das "wie" muss schon die software selbst machen. und das plug-in. siehe oben, die meisten plug-ins unterstützen nur 4 oder 5 kerne, und das aus gutem grund.

das ist genau wie auch eine software selbst festlegen muss, wie groß ein fenster ist oder wann ein warnton erklingt, auch wenn das nachher alles das OS macht.

und die host muss es auch unterstützen. protools war bis 2004 in den dreh z.b. nicht in der lage, auch nur einen zweiten prozessor zu benutzen, geschweige denn 128.

wenn es so einfach wäre, dass man in XCode nur den kleinen bunten GDC knopf drückt und schon läuft das programm auf allen kernen, dann würden gewisse hersteller das so machen. es geht heute bei fast allem sehr einfach, nur eben nicht bei programmen mit echtzeitplug-ins. ich habe es aber auch schon von spielen gehört, de ren architektur das wohl irgendwie nicht erlaubt und/oder es schwer ist, die entscheidung darüber zu treffen wie man es macht.

dass das eine aufgabe der applikation ist erkennst du schon daran, dass die programme in den letzten jahren immer wieder verbesserungen bei der multithreadin gleistung bekommen haben und auch z.b. die anzahl der maximalen kerne unterschiedlich ist. oder auch an dem vom TE beschriebenen problem mit dem masterbus...

 

[Klinke]

wie die daten verteilt werden ist zunächst mal einfch ein logisches problem.

und es machst absolut sinn, dass von der DAW aus einzustellen genau wie man ja auch das audio und midi IO von der DAW aus einstellt, obwohl es bestadneteile des betriebssystems sind.



klein genug sind wir mit unseren audio zum glück.

aber 100 plug-ins auf 100 kernen laufen lassen will man echt nicht, dann geht wohl das allermeiste schon nur fürs verteilen drauf.

ansonsten wäre die aufgabe für die hersteller ja supereinfach zu lösen.





das "wie" muss schon die software selbst machen. und das plug-in. siehe oben, die meisten plug-ins unterstützen nur 4 oder 5 kerne, und das aus gutem grund.

das ist genau wie auch eine software selbst festlegen muss, wie groß ein fenster ist oder wann ein warnton erklingt, auch wenn das nachher alles das OS macht.

und die host muss es auch unterstützen. protools war bis 2004 in den dreh z.b. nicht in der lage, auch nur einen zweiten prozessor zu benutzen, geschweige denn 128.

wenn es so einfach wäre, dass man in XCode nur den kleinen bunten GDC knopf drückt und schon läuft das programm auf allen kernen, dann würden gewisse hersteller das so machen. es geht heute bei fast allem sehr einfach, nur eben nicht bei programmen mit echtzeitplug-ins. ich habe es aber auch schon von spielen gehört, de ren architektur das wohl irgendwie nicht erlaubt und/oder es schwer ist, die entscheidung darüber zu treffen wie man es macht.

dass das eine aufgabe der applikation ist erkennst du schon daran, dass die programme in den letzten jahren immer wieder verbesserungen bei der multithreadin gleistung bekommen haben und auch z.b. die anzahl der maximalen kerne unterschiedlich ist. oder auch an dem vom TE beschriebenen problem mit dem masterbus...

Natürlich muss die DAW sich darum kümmern die einzelnen Thread zu koordinieren und natürlich kann man in dem Bereich einiges optimieren und durch unterschiedliche Ansätze eine bessere Performance herauskitzeln (z.B. indem nicht nur ein kompletter Track in einem Thread läuft), das ist ja schliesslich auch genau die Frage von Plasmatron. Und ja, einen guten, performanten, parallelen Code zu schreiben ist nicht trivial, genau mit Thema beschäftige ich mich nicht umsonst seit ein paar Jahren (mehr für Simulationen auf Supercomputern, aber früher habe ich ja auch an Audioanwendungen gearbeitet). Du hast aber den Eindruck erweckt, als wäre es die Aufgabe der DAW sich selbst um die Zuordnung der Threads zu den einzelnen Cores zu kümmern, was halt so nicht stimmt. Um (viel) mehr ging es mir da gar nicht. Bin damit jetzt aus der Diskussion raus, eigentlich hätte ich gleich wissen können, das es nicht sonderlich sinnvoll ist, mit dir zu diskutieren (manchmal tut halt die Verbreitung von soviel Halbwissen echt weh).