Kaufempfehlung: Mac Pro - wieviele Kerne?

[CharlyBeck]

du kannst deine daw nicht darauf programmieren, parallel ein signal zu berechnen, welches es noch gar nicht gibt.

sehr einfach veranschaulichbar: sagen wir, du hast einen wahnsinns blockflötentake, der die welt erobern soll. zum zwecke des erlangens besagter weltherrschaft hängst zwei plugins hintereinander in kanal-inserts der flötenspur. das erste ist ein echtzeitpitchshifter, bei dem du deiner blockflötenspur mit einer transposition von +36 halbtönen erst so richtig schmiss verleihst.

das zweite ist ein quadrafuzz, weil so eine 3 oktaven nach oben gepitchte blockflöte natürlich erst mit einer multibandverzerrung so richtig schön smooth klingt.

dieses setup ist nicht parallel berechenbar. denn der zerrer kann ja nicht parallel schonmal etwas verzerren, was noch gar nicht berechnet ist. da kannst du die daw noch so sehr "extra auf mehrprozessoren programmieren" wie du willst, eine serielle bearbeitung ist halt eine serielle bearbeitung.

Wer sagt denn sowas? Ich denke, das ist eine Milchmädchenrechnung. Das zweite Plugin in der Kette kann natürlich auf einem zweiten Prozessor laufen. Ich denke mal keiner hier - einschliesslich mir - kennt die interne Architektur von DAW Software aber zumindest denkbar/machbar ist es, man könnte jedes einzelne Plugin in einem anderen Prozesssorkern laufen lassen. Während Plugin 1 auf Kern 1 das zweite sample berechnet, kann Plugin 2 auf Kern 2 das erste erste sample berechnen, das es als eingabe von plugin 1 erhalten hat. Die Ausführung läuft paralell, das von Nachtschicht erläuterte - vermeindliche - Problem, der serialisierung kann man dadurch lösen, dass die ausführungsstränge zwar parallel laufen, aber eben nicht gleichzeitig loslaufen. (=> Wie bei Sequenzen zwischen mehreren ActiveObjects (Alexander, Schmidt))

Wenn 2 Spuren paralell berechnet werden können und einigermaßen exakt zusammengeführt werden können, dann hat man schon verfahren implementiert, die abgewandelt ersteres realisieren können. Blablub. Nur mal so eingeworfen

Douglas Schmidt hat eine ähnliche Auffassung von paralellen Systemen. Imho aber gefährlich bzgl. Kontrollverlust. Funktioniert auf hohem Level im Internet, obs bei so sachen wie DAWs (so n bissl echtzeit) performant genug ist -- ??

 

[andreee]

Aber welchen Mac Pro würdet ihr empfehlen?

Von den "aktuellen" (5 Jahre alten) ? Im Moment gar keinen... es wird gemunkelt, daß dieses Jahr noch ein neuer Mac Pro vorgestellt werden soll. Zudem bekommst Du mit einem 2010-2012 in Dual-CPU Konfiguration deutlich günstiger eine adequate Rechenleistung, wenn Du auf Thunderbolt verzichten kannst. Ich würde eine Käsereibe in Basiskonfiguration (z.B. Dual Quad-2,4 GHz, Standardgraka) nehmen, diese mit zwei 3,33 GHz 6-Core CPUs (max. gingen 2 x 3,46 GHz, sind aber deutlich teuerer), ordentlich Ram, sowie einer PCIe-SSD (oder ggf. SATA plus Adapter, wenn Dir das reicht) und einer Metal-kompatiblen Grafikkarte (bspw. Radeon 7870) ausstatten.

Plus 1

 

[Gel Mitglieder 67478]

du kannst deine daw nicht darauf programmieren, parallel ein signal zu berechnen, welches es noch gar nicht gibt.

sehr einfach veranschaulichbar: sagen wir, du hast einen wahnsinns blockflötentake, der die welt erobern soll. zum zwecke des erlangens besagter weltherrschaft hängst zwei plugins hintereinander in kanal-inserts der flötenspur. das erste ist ein echtzeitpitchshifter, bei dem du deiner blockflötenspur mit einer transposition von +36 halbtönen erst so richtig schmiss verleihst.

das zweite ist ein quadrafuzz, weil so eine 3 oktaven nach oben gepitchte blockflöte natürlich erst mit einer multibandverzerrung so richtig schön smooth klingt.

dieses setup ist nicht parallel berechenbar. denn der zerrer kann ja nicht parallel schonmal etwas verzerren, was noch gar nicht berechnet ist. da kannst du die daw noch so sehr "extra auf mehrprozessoren programmieren" wie du willst, eine serielle bearbeitung ist halt eine serielle bearbeitung.

Wer sagt denn sowas? Ich denke, das ist eine Milchmädchenrechnung. Das zweite Plugin in der Kette kann natürlich auf einem zweiten Prozessor laufen. Ich denke mal keiner hier - einschliesslich mir - kennt die interne Architektur von DAW Software aber zumindest denkbar/machbar ist es, man könnte jedes einzelne Plugin in einem anderen Prozesssorkern laufen lassen. Während Plugin 1 auf Kern 1 das zweite sample berechnet, kann Plugin 2 auf Kern 2 das erste erste sample berechnen, das es als eingabe von plugin 1 erhalten hat. Die Ausführung läuft paralell, das vermeindliche Problem, der serialisierung kann man einfach dadurch lösen, dass die ausführungsstränge zwar parallel laufen, aber eben nicht gleichzeitig loslaufen.

Wenn 2 Spuren paralell berechnet werden können und einigermaßen exakt zusammengeführt werden können, dann hat man schon verfahren implementiert, die abgewandelt ersteres realisieren können. Blablub. Nur mal so eingeworfen

Douglas Schmidt hat eine ähnliche Auffassung von paralellen Systemen. Imho aber gefährlich bzgl. Kontrollverlust. Funktioniert auf hohem Level im Internet, obs bei so sachen wie DAWs (so n bissl echtzeit) performant genug ist -- ??

Anwendungsentwicklung hat nichts mit Kuchen backen zu tun. Letzteres geht auch theoretisch.
Schöner Ansatz deine Überlegung, aber nicht wirklich nah an der Realität.
Was ist denn mit anderen Berechnungen die auch zeitgleich in den Kernen berechnet werden? Skype, Systemprogramme etc. Willst du die alle mit stamps versehen und wieder zusammenfrickeln? Latenz Level over 9000 incoming.

 

[CharlyBeck]

du kannst deine daw nicht darauf programmieren, parallel ein signal zu berechnen, welches es noch gar nicht gibt.

sehr einfach veranschaulichbar: sagen wir, du hast einen wahnsinns blockflötentake, der die welt erobern soll. zum zwecke des erlangens besagter weltherrschaft hängst zwei plugins hintereinander in kanal-inserts der flötenspur. das erste ist ein echtzeitpitchshifter, bei dem du deiner blockflötenspur mit einer transposition von +36 halbtönen erst so richtig schmiss verleihst.

das zweite ist ein quadrafuzz, weil so eine 3 oktaven nach oben gepitchte blockflöte natürlich erst mit einer multibandverzerrung so richtig schön smooth klingt.

dieses setup ist nicht parallel berechenbar. denn der zerrer kann ja nicht parallel schonmal etwas verzerren, was noch gar nicht berechnet ist. da kannst du die daw noch so sehr "extra auf mehrprozessoren programmieren" wie du willst, eine serielle bearbeitung ist halt eine serielle bearbeitung.

Wer sagt denn sowas? Ich denke, das ist eine Milchmädchenrechnung. Das zweite Plugin in der Kette kann natürlich auf einem zweiten Prozessor laufen. Ich denke mal keiner hier - einschliesslich mir - kennt die interne Architektur von DAW Software aber zumindest denkbar/machbar ist es, man könnte jedes einzelne Plugin in einem anderen Prozesssorkern laufen lassen. Während Plugin 1 auf Kern 1 das zweite sample berechnet, kann Plugin 2 auf Kern 2 das erste erste sample berechnen, das es als eingabe von plugin 1 erhalten hat. Die Ausführung läuft paralell, das vermeindliche Problem, der serialisierung kann man einfach dadurch lösen, dass die ausführungsstränge zwar parallel laufen, aber eben nicht gleichzeitig loslaufen.

Wenn 2 Spuren paralell berechnet werden können und einigermaßen exakt zusammengeführt werden können, dann hat man schon verfahren implementiert, die abgewandelt ersteres realisieren können. Blablub. Nur mal so eingeworfen

Douglas Schmidt hat eine ähnliche Auffassung von paralellen Systemen. Imho aber gefährlich bzgl. Kontrollverlust. Funktioniert auf hohem Level im Internet, obs bei so sachen wie DAWs (so n bissl echtzeit) performant genug ist -- ??

Anwendungsentwicklung hat nichts mit Kuchen backen zu tun. Letzteres geht auch theoretisch.
Schöner Ansatz deine Überlegung, aber nicht wirklich nah an der Realität.
Was ist denn mit anderen Berechnungen die auch zeitgleich in den Kernen berechnet werden? Skype, Systemprogramme etc. Willst du die alle mit stamps versehen und wieder zusammenfrickeln? Latenz Level over 9000 incoming.

Naja, wie gesagt, kenne mich mit daws wenig aus. Aber ohne das Problem jetzt näher zu betrachten werden wohl einzelne elemente (audiostreams) paralell berechnet und müssen dann wohl auch - mittels timestamps - wieder zusammen geführt werden. In welchen Boundariers das sinnigerweise geschieht - keine ahnung. Man kann die Spuren ja beliebig miteinander verkutteln, mit sidechaining etc.

Falls du weisst, wie diese paralellberechnung - ohne timestamps - funktioniert - raus mit der sprache

Aber abgesehen davon - soviel steckt nicht dahinter. Du hast int -timestamps und einen offset den du einfach auf einen index eines puffers umrechnen kannst denke ich. Da gibts nix zusammenzufrickeln nach dem motto IndexOf(DateTime.New) Will sagen arg viel CPU-Last macht das nicht. Es wird ja nicht jedes einzelne Plugin auf einem eigenen Kern laufen...Ich sage nur dass es genauso wie es möglich ist, 2 spuren auf 2 kerne zu verteilen auch möglich ist, 2 plugins auf 2 kerne zu verteilen....

Fakt ist jedenfalls DAWs unterstützen mehrere Kerne und ich gehe mal davon aus, dass da auch schon dann die Audio-/Plugin berechnung verteilt wird.

Aber was hat skype damit zu tun? Das sind andere prozesse, die werden schon vom betriebssystem auseinandergehalten, keine sorge...

 

[Nachtschicht]

du kannst deine daw nicht darauf programmieren, parallel ein signal zu berechnen, welches es noch gar nicht gibt.

sehr einfach veranschaulichbar: sagen wir, du hast einen wahnsinns blockflötentake, der die welt erobern soll. zum zwecke des erlangens besagter weltherrschaft hängst zwei plugins hintereinander in kanal-inserts der flötenspur. das erste ist ein echtzeitpitchshifter, bei dem du deiner blockflötenspur mit einer transposition von +36 halbtönen erst so richtig schmiss verleihst.

das zweite ist ein quadrafuzz, weil so eine 3 oktaven nach oben gepitchte blockflöte natürlich erst mit einer multibandverzerrung so richtig schön smooth klingt.

dieses setup ist nicht parallel berechenbar. denn der zerrer kann ja nicht parallel schonmal etwas verzerren, was noch gar nicht berechnet ist. da kannst du die daw noch so sehr "extra auf mehrprozessoren programmieren" wie du willst, eine serielle bearbeitung ist halt eine serielle bearbeitung.

Wer sagt denn sowas? Ich denke, das ist eine Milchmädchenrechnung. Das zweite Plugin in der Kette kann natürlich auf einem zweiten Prozessor laufen. Ich denke mal keiner hier - einschliesslich mir - kennt die interne Architektur von DAW Software aber zumindest denkbar/machbar ist es, man könnte jedes einzelne Plugin in einem anderen Prozesssorkern laufen lassen. Während Plugin 1 auf Kern 1 das zweite sample berechnet, kann Plugin 2 auf Kern 2 das erste erste sample berechnen, das es als eingabe von plugin 1 erhalten hat. Die Ausführung läuft paralell, das von Nachtschicht erläuterte - vermeindliche - Problem, der serialisierung kann man dadurch lösen, dass die ausführungsstränge zwar parallel laufen, aber eben nicht gleichzeitig loslaufen. (=> Wie bei Sequenzen zwischen mehreren ActiveObjects (Alexander, Schmidt))

Wenn 2 Spuren paralell berechnet werden können und einigermaßen exakt zusammengeführt werden können, dann hat man schon verfahren implementiert, die abgewandelt ersteres realisieren können. Blablub. Nur mal so eingeworfen

Douglas Schmidt hat eine ähnliche Auffassung von paralellen Systemen. Imho aber gefährlich bzgl. Kontrollverlust. Funktioniert auf hohem Level im Internet, obs bei so sachen wie DAWs (so n bissl echtzeit) performant genug ist -- ??

Der Punkt ist doch, dass du es innerhalb des puffers schaffen musst.

Da haste jetzt also 32 samples Zeit für ein pufferpaketchen. Sagen wir, dein ausgangssignal ist ne uhe diva und verbringt auf einem Prozessor mit clockspeed x,x schonmal 20 samples mit der Berechnung eines Pakets.
Wenn ein zweiter Prozessor jetzt brav 20 samples lang drauf wartet, bis er dieses Häppchen bekommt , hast du keinerlei Zeit gewonnen - wenn du jetzt dahinter z.B. irgendein zynaptiq Plugin im insert hast, bei dem Herr Bernsee seinen evil genius mal wieder in einen Algorithmus vom Mars gegossen hat, welches aber eventuell selber nochmal 20 samples für die Berechnung braucht, dann hast dus innerhalb der 32 samples eben nicht berechnet bekommen, egal ob du es auf einem Kern rechnest oder auf einem Kern plus 2 oder 200 Kernen die währenddessen auf den ersten Kern warten mussten. Da kriegste dann je nach Programm ne Fehlermeldung oder nen low latency Kratzer, und der einzige weg das zu lösen ist, wenn der rechnende Kern halt schneller rechnet und eben das pufferpaket der Diva in 10 samples und den zynaptiq in 10 samples rechnet. Du kannst auch nicht einfach sample für sample aufteilen, weil je nach Art des dsp Prozesses eventuell mehrere samples notwendig sind um überhaupt zu wissen was du tust, phasenlineare Bearbeitungen, enveloper, es sind ja nicht alles beliebig sezierbare Prozesse sondern welche, die für ihre Berechnung eine gewisse mindestpaketgrösse haben müssen.

Daher die Faustregel dass für niedrigste Latenzen eher der nackte speed relevant ist, und für grosse Projekte eher die Gesamtsumme an über viele Kerne verfügbare Rechenleistung. Das denke ich mir ja übrigens nicht aus sondern ich gebe hier nur das wieder, was man in nerdgesprächen mit mitarbeitern diverser audiofirmen über die Jahre so hört. Ich hab da ja überhaupt kein Pferd im Rennen, aber ist doch völlig nachvollziehbar - und übrigens auch in der Praxis exakt so zu beobachten. Und wird - nochmal - immer unwichtiger, weil heutige Rechner soviel wumms haben.

Ist mir vollkommen schleierhaft, wie aus so nem harmlosen Plausch hier jetzt so ein Politikum gebastelt wird.

 

[Unik SUS]

Also, ich verstehe die Mac/Windows Aufreger immer nicht. Wir sind uns doch einig und es ist doch hinlänglich bekannt:

"an apple a day keeps the doctor away"

Aus dem Grund nutze ich schon seeehr lange Mac. Mein Hausarzt begrüßt das auch.

 

[Nachtschicht]

Also, ich verstehe die Mac/Windows Aufreger immer nicht.

Ich auch nicht, denn von Mac vs Windows war hier überhaupt nicht die Rede. Vielleicht muss man bei soviel trigger happiness heutzutage extra drauf hinweisen, dass es in Apples Portfolio beide Prozessorphilosphien zu kaufen gibt. Vielleicht sollte man statt i7 und xeon einfach "iMac" und "iMac/Mac Pro" schreiben, um potentieller kränkung allzu empfindlicher Seelen vorzubeugen.

 

[Gel Mitglieder 84964]

nun ja, wie gesagt, es kommt primär auf das anwendungsszenario an. das ist auch mehr oder weniger daw-unabhängig, weil z.b. serielles statt paralleles berechnen (also das, wo eher die geschwindigkeit der CPU als die anzahl der kerne entscheidend ist) einfach in der natur der sache liegt.

Das Anwendungsszenario wäre dann so, dass du beim Vergleich eines 6- und 8-Kerners und 2 Threads pro Kern die Vorteile schon ab >12 bis 16 Spuren zu spüren bekommst (oder ist es z.B. bei Ableton tatsächlich 1 Kern pro Spur? dann wärs ja schon bei 6 bis 8 Spuren), und das hat im Prinzip jede Session und nicht nur jedes große Projekt. Ich zweifel die Wichtigkeit der Single-Core-Performance gar nicht an, nur denke ich, dass bei der Wahl des Prozessors die Multicore-Performance unterschätzt wird, weil man die nicht einfach am Takt oder sonstwas ablesen kann und es hierbei natürlich zusätzlich auf die Optimierung der Software und das Anwendungsgebiet selbst ankommt (Stichwort Gaming vs. Mukke).

Ist mir vollkommen schleierhaft, wie aus so nem harmlosen Plausch hier jetzt so ein Politikum gebastelt wird.

Ja, mir auch Ich plauder gern mit dir ÜBER SINGLE VS MULTICORE VERDAMMTE SCHEIßE!!!!!!!!!!!"""""!!!!xoxo

 

[Nachtschicht]

Ich zweifel die Wichtigkeit der Single-Core-Performance gar nicht an, nur denke ich, dass bei der Wahl des Prozessors die Multicore-Performance unterschätzt wird, weil man die nicht einfach am Takt oder sonstwas ablesen kann und es hierbei natürlich zusätzlich auf die Optimierung der Software

Gibt's sicherlich. So wie es auch Leute gibt, die nicht verstehen warum der insgesamt kräftigste Rechner nicht automatisch auch der bei niedrigsten Latenzen beste Rechner ist. Ich halte da jetzt auch kein Plädoyer für das eine oder das andere, nochmal schreib ich jetzt nicht dass Rechner heutzutage sowieso alle soviel wumms haben dass es zunehmend egal wird, musste dir jetzt vorstellen

SINGLE VS MULTICORE VERDAMMTE SCHEIßE!!!!!!!!!!!""

Wir hätten uns natürlich auch über etwas weniger umstrittenes unterhalten können. Die Mondlandung oder so
Wobei, wenn man sich ganz doll anstrengt kriegt man in die vielleicht auch noch nen Plattformkrieg reinprojeziert. Müsste man einfach mal ausprobieren.

 

[CharlyBeck]

Der Punkt ist doch, dass du es innerhalb des puffers schaffen musst.

Ich hab alles gelesen aber nehm grad mal den ersten satz als aufhänger. Warum "muss ich es innerhalb des Puffers schaffen"? Muss ich nicht! Was soll passieren, wenn ichs nicht schaffe? Bufferunderrun? (Hast du das gemeint?) - Nö das passiert jedenfalls nicht:

Die Puffergröße begrenzt ja nur den möglichen Jitter bevor ein underrin eintritt, der jitter darf nicht länger sein als der puffer, sons gibts nen buffer undrrun. aber wenn regelmässig nachgeschoben wird, kann die latenz beliebig hoch sein...

Oder reden wir jetzt voll aneinander vorbei?

Man kann ja auch mal 10 eqs im maximum linear phase mode einbauen. Dann dauerts auch 1 sek. bis nach "play" ein ton kommt. Diese Zeit ist weit höher, als der Puffer.

Klar, das Beispiel 2 serielle plugins auf 2 cores zu verteilen ist vl. etwas an den haaren herbeigezogen. Ich habe ja nicht gesagt, dass es praktikabel ist, aber denkbar ist es. Man könnte aber mal ganz einfach die probe aufs excempel machen: ABleton hat keine Pluginbegrenzung pro spur. Man könnte eine extrem lange, rechenintensive plugin kette in eine einzige Spur bauen und schauen, ob irgendwann mehrere Kerne aktiv werden. Ich hätte das jetzt gemacht aber finde unter laptop-win10 die anzeige der auslastung der einzelnen kerne nicht...

Wenn ich drandenke werde ich das aber mal in der daw testen, das würde mich jetzt schon interessieren, ob eine rechenintensive masterkette jetzt multicore läuft oder nicht...

Fazit: Kann sein dass du bzgl der PAralellisierung von seriallen Plugins recht hast, aber die begründung war nicht so recht einleuchtend.

 

[CharlyBeck]

st mir vollkommen schleierhaft, wie aus so nem harmlosen Plausch hier jetzt so ein Politikum gebastelt wird

Warum Politikum??? Ich hab nicht die Energie und Zeit und wahrscheinlich auch erstmal nicht das wissen eine DAW oder ähnliches zu bauen, aber ein bisschen Fachgesimple ist doch ok... Vl kommt ja irgendwann der große durchbruch

 

[Nachtschicht]

st mir vollkommen schleierhaft, wie aus so nem harmlosen Plausch hier jetzt so ein Politikum gebastelt wird

Warum Politikum??? Ich hab nicht die Energie und Zeit und wahrscheinlich auch erstmal nicht das wissen eine DAW oder ähnliches zu bauen, aber ein bisschen Fachgesimple ist doch ok... Vl kommt ja irgendwann der große durchbruch

Hat überhaupt nix mit dir zu tun, hast ein paar inzwischen gelöschte posts verpasst alles gut.

 

[Nachtschicht]

Der Punkt ist doch, dass du es innerhalb des puffers schaffen musst.

Ich hab alles gelesen aber nehm grad mal den ersten satz als aufhänger. Warum "muss ich es innerhalb des Puffers schaffen"? Muss ich nicht! Was soll passieren, wenn ichs nicht schaffe? Bufferunderrun? (Hast du das gemeint?) - Nö das passiert jedenfalls nicht:

Die Puffergröße begrenzt ja nur den möglichen Jitter bevor ein underrin eintritt, der jitter darf nicht länger sein als der puffer, sons gibts nen buffer undrrun. aber wenn regelmässig nachgeschoben wird, kann die latenz beliebig hoch sein...

Oder reden wir jetzt voll aneinander vorbei?

Man kann ja auch mal 10 eqs im maximum linear phase mode einbauen. Dann dauerts auch 1 sek. bis nach "play" ein ton kommt. Diese Zeit ist weit höher, als der Puffer.

Klar, das Beispiel 2 serielle plugins auf 2 cores zu verteilen ist vl. etwas an den haaren herbeigezogen. Ich habe ja nicht gesagt, dass es praktikabel ist, aber denkbar ist es. Man könnte aber mal ganz einfach die probe aufs excempel machen: ABleton hat keine Pluginbegrenzung pro spur. Man könnte eine extrem lange, rechenintensive plugin kette in eine einzige Spur bauen und schauen, ob irgendwann mehrere Kerne aktiv werden. Ich hätte das jetzt gemacht aber finde unter laptop-win10 die anzeige der auslastung der einzelnen kerne nicht...

Wenn ich drandenke werde ich das aber mal in der daw testen, das würde mich jetzt schon interessieren, ob eine rechenintensive masterkette jetzt multicore läuft oder nicht...

Fazit: Kann sein dass du bzgl der PAralellisierung von seriallen Plugins recht hast, aber die begründung war nicht so recht einleuchtend.

Es muss innerhalb des puffers passieren, um einen sauberen output bei einer vorgegebenen Latenz / puffergrösse zu gewährleisten (üblicherweise 32 samples).

Das ist der ganze Punkt Das können hoch getaktete Kerne halt besser als niedriger getaktete, egal wieviele es davon gibt.

Wie gesagt, der Unterschied wird seit Jahren zunehmend akademisch. Aber vor paar Jahren war das noch ein relativ heftiger Unterschied und für echtzeit Anwendungen hat man deswegen eher keine xeons genommen. Heute ist der Unterschied eher klein. Aber ganz weg isser noch nicht. Für ein live Gerät würde ich weiterhin eher den fokus auf hohe Takte setzen (ist bei mir mit ca 30% meiner Tätigkeit ein ziemlicher Batzen. Für ne mix monster Maschine ganz klar xeon


aber es ist echt nicht mehr so wild inzwischen alles. Moderne Rechner sind echte killer alle miteinander. Mac und PC gleichermaßen, um Missverständnissen vorzubeugen

 

[CharlyBeck]

Der Punkt ist doch, dass du es innerhalb des puffers schaffen musst.

Ich hab alles gelesen aber nehm grad mal den ersten satz als aufhänger. Warum "muss ich es innerhalb des Puffers schaffen"? Muss ich nicht! Was soll passieren, wenn ichs nicht schaffe? Bufferunderrun? (Hast du das gemeint?) - Nö das passiert jedenfalls nicht:

Die Puffergröße begrenzt ja nur den möglichen Jitter bevor ein underrin eintritt, der jitter darf nicht länger sein als der puffer, sons gibts nen buffer undrrun. aber wenn regelmässig nachgeschoben wird, kann die latenz beliebig hoch sein...

Oder reden wir jetzt voll aneinander vorbei?

Man kann ja auch mal 10 eqs im maximum linear phase mode einbauen. Dann dauerts auch 1 sek. bis nach "play" ein ton kommt. Diese Zeit ist weit höher, als der Puffer.

Klar, das Beispiel 2 serielle plugins auf 2 cores zu verteilen ist vl. etwas an den haaren herbeigezogen. Ich habe ja nicht gesagt, dass es praktikabel ist, aber denkbar ist es. Man könnte aber mal ganz einfach die probe aufs excempel machen: ABleton hat keine Pluginbegrenzung pro spur. Man könnte eine extrem lange, rechenintensive plugin kette in eine einzige Spur bauen und schauen, ob irgendwann mehrere Kerne aktiv werden. Ich hätte das jetzt gemacht aber finde unter laptop-win10 die anzeige der auslastung der einzelnen kerne nicht...

Wenn ich drandenke werde ich das aber mal in der daw testen, das würde mich jetzt schon interessieren, ob eine rechenintensive masterkette jetzt multicore läuft oder nicht...

Fazit: Kann sein dass du bzgl der PAralellisierung von seriallen Plugins recht hast, aber die begründung war nicht so recht einleuchtend.

Es muss innerhalb des puffers passieren, um einen sauberen output bei einer vorgegebenen Latenz / puffergrösse zu gewährleisten (üblicherweise 32 samples).

Das ist der ganze Punkt Das können hoch getaktete Kerne halt besser als niedriger getaktete, egal wieviele es davon gibt.

Wie gesagt, der Unterschied wird seit Jahren zunehmend akademisch. Aber vor paar Jahren war das noch ein relativ heftiger Unterschied und für echtzeit Anwendungen hat man deswegen eher keine xeons genommen. Heute ist der Unterschied eher klein. Aber ganz weg isser noch nicht. Für ein live Gerät würde ich weiterhin eher den fokus auf hohe Takte setzen (ist bei mir mit ca 30% meiner Tätigkeit ein ziemlicher Batzen. Für ne mix monster Maschine ganz klar xeon


aber es ist echt nicht mehr so wild inzwischen alles. Moderne Rechner sind echte killer alle miteinander. Mac und PC gleichermaßen, um Missverständnissen vorzubeugen

Ja das leuchtet ein, besser takten als verwaltungstechnisch teure multicores.... ich war in den späten 90ern mal bei einem vortrag bei siemens und da hat einer auf die frage, wieviele cores praktikabel wären bevor es verwaltungstechnisch zu teuer wird geantwortet, glaub 8-16 kerne und weiter ist man heute ja auch (noch) nicht. Es wird glaub sehr viel an abläufen optimiert aber physikalisch ist man wohl schon ne weile an den grenzen angelangt... wird zeit für etwas quanten computing für den hausgebrauch

 

[one_hit_wonder]

Ja das leuchtet ein, besser takten als verwaltungstechnisch teure multicores....

So einfach ist das aber nicht.
Es ist energietechnisch und damit auch wärmetechnisch einfacher einen Prozessor mit 2 Kernen a 2 Ghz zu betreiben als einen Kern mit 4 Ghz.
Und dann ist es egal, ob du einen Prozessor mit 2 Kernen hast oder einen mit 18 wie der iMacPro.
Der verwaltungstechnische Aufwand bleibt ähnlich.
Die Programme müssen nur darauf optimiert sein.
Einen Prozessor mit nur einem Kern wird eh keiner mehr verwenden.

 

[CharlyBeck]

Der Punkt ist doch, dass du es innerhalb des puffers schaffen musst.

Ich hab alles gelesen aber nehm grad mal den ersten satz als aufhänger. Warum "muss ich es innerhalb des Puffers schaffen"? Muss ich nicht! Was soll passieren, wenn ichs nicht schaffe? Bufferunderrun? (Hast du das gemeint?) - Nö das passiert jedenfalls nicht:

Die Puffergröße begrenzt ja nur den möglichen Jitter bevor ein underrin eintritt, der jitter darf nicht länger sein als der puffer, sons gibts nen buffer undrrun. aber wenn regelmässig nachgeschoben wird, kann die latenz beliebig hoch sein...

Oder reden wir jetzt voll aneinander vorbei?

Man kann ja auch mal 10 eqs im maximum linear phase mode einbauen. Dann dauerts auch 1 sek. bis nach "play" ein ton kommt. Diese Zeit ist weit höher, als der Puffer.

Klar, das Beispiel 2 serielle plugins auf 2 cores zu verteilen ist vl. etwas an den haaren herbeigezogen. Ich habe ja nicht gesagt, dass es praktikabel ist, aber denkbar ist es. Man könnte aber mal ganz einfach die probe aufs excempel machen: ABleton hat keine Pluginbegrenzung pro spur. Man könnte eine extrem lange, rechenintensive plugin kette in eine einzige Spur bauen und schauen, ob irgendwann mehrere Kerne aktiv werden. Ich hätte das jetzt gemacht aber finde unter laptop-win10 die anzeige der auslastung der einzelnen kerne nicht...

Wenn ich drandenke werde ich das aber mal in der daw testen, das würde mich jetzt schon interessieren, ob eine rechenintensive masterkette jetzt multicore läuft oder nicht...

Fazit: Kann sein dass du bzgl der PAralellisierung von seriallen Plugins recht hast, aber die begründung war nicht so recht einleuchtend.

Es muss innerhalb des puffers passieren, um einen sauberen output bei einer vorgegebenen Latenz / puffergrösse zu gewährleisten (üblicherweise 32 samples).

Das ist der ganze Punkt Das können hoch getaktete Kerne halt besser als niedriger getaktete, egal wieviele es davon gibt.

Wie gesagt, der Unterschied wird seit Jahren zunehmend akademisch. Aber vor paar Jahren war das noch ein relativ heftiger Unterschied und für echtzeit Anwendungen hat man deswegen eher keine xeons genommen. Heute ist der Unterschied eher klein. Aber ganz weg isser noch nicht. Für ein live Gerät würde ich weiterhin eher den fokus auf hohe Takte setzen (ist bei mir mit ca 30% meiner Tätigkeit ein ziemlicher Batzen. Für ne mix monster Maschine ganz klar xeon


aber es ist echt nicht mehr so wild inzwischen alles. Moderne Rechner sind echte killer alle miteinander. Mac und PC gleichermaßen, um Missverständnissen vorzubeugen

Also ich hab das grade mal ausprobiert. Mit einer Spur (ca. 10x Limitless Native Limiter drauf) war die CPU-Peak nur in einem Kern. Bei 2 Spuren war der deutliche Peak auf 5 Kernen zu sehen. Ich glaube nicht dass Windows andere Prozesse auf die Kerne ausgelagert hat denn so hoch wie die Peaks waren, soviel Last habe ich nicht laufen gehabt neben Ableton.

Somit wäre für mich zumindest empirisch bewiesen, dass zumindest Ableton schon seriell geschaltete Plugins innerhalb einer Spur auf versch. Kerne verteilt. Und jetzt du?

 

[Nachtschicht]

Dann machen sies offenbar bei ableton zu Beginn wie von mir beschrieben und ab einem gewissen Punkt sowas wie du es beschreibst, aber das ändert ja nicht das Problem mit der Latenz. Solange, vereinfacht gesagt, sample 2 erst ausgerechnet werden kann wenn sample 1 berechnet ist, kannst du das beliebig verteilen und es bleibt trotzdem seriell in seiner Natur (nur dann mit mehr Verwaltungsoverhead . So oder so musst du einen seriellen Prozess innerhalb einer vorgegebenen Zeit (für echtzeit gerne 32 samples) abgearbeitet haben, und da hilft wenns knapp wird nur die nackte rechengeschwindigkeit, die die Serie abarbeitet.

Ich kenn das ja auch aus der Praxis. Wir haben bei uns auf einer Produktion sowohl nen i7 als auch nen xeon aus derselben Generation im Einsatz. Der xeon war ein vielfaches teurer, und bei grossen Projekten mit hoher Latenz ist der erste Wahl. Aber bei echtzeitrelevanten Anwendungen, etwa auch komplexes Softwaremonitoring durch viel processing durch, macht der gegen den höher getakteten i7 keinen Stich. Da kommt der i7 auch bei 32 samples richtig weit, während der xeon eigentlich erst ab 128 wirklich vernünftig einsetzbar ist.

 

[one_hit_wonder]

Der xeon war ein vielfaches teurer, und bei grossen Projekten mit hoher Latenz ist der erste Wahl. Aber bei echtzeitrelevanten Anwendungen, etwa auch komplexes Softwaremonitoring durch viel processing durch, macht der gegen den höher getakteten i7 keinen Stich. Da kommt der i7 auch bei 32 samples richtig weit, während der xeon eigentlich erst ab 128 wirklich vernünftig einsetzbar ist.

Das mag bei Windows wirklich so der Fall sein aber bei Apple liegt es genau umgekehrt.
Ich kann es nur von Logic uns PT sagen, da machen mehr Kerne bei vielen Spuren mehr Sinn.
Das funktioniert aber nur, wenn das Programm explizit für Apple programmiert wurde.
Bei Programme die eigentlich für Windows programmiert sind, und weil man jetzt auch auf den Apple Zug aufspringen will, nur für Apple kompilierte Versionen herausbringt geht das meist in die Hose und die Performance sinkt gegenüber Windows ab.
Es hat schon seinen Grund warum es Softwarehäuser gibt die ihre Software nur für Windows oder nur für Apple herstellen.

 

[CharlyBeck]

Dann machen sies offenbar bei ableton zu Beginn wie von mir beschrieben und ab einem gewissen Punkt sowas wie du es beschreibst, aber das ändert ja nicht das Problem mit der Latenz. Solange, vereinfacht gesagt, sample 2 erst ausgerechnet werden kann wenn sample 1 berechnet ist, kannst du das beliebig verteilen und es bleibt trotzdem seriell in seiner Natur (nur dann mit mehr Verwaltungsoverhead . So oder so musst du einen seriellen Prozess innerhalb einer vorgegebenen Zeit (für echtzeit gerne 32 samples) abgearbeitet haben, und da hilft wenns knapp wird nur die nackte rechengeschwindigkeit, die die Serie abarbeitet.

Ich kenn das ja auch aus der Praxis. Wir haben bei uns auf einer Produktion sowohl nen i7 als auch nen xeon aus derselben Generation im Einsatz. Der xeon war ein vielfaches teurer, und bei grossen Projekten mit hoher Latenz ist der erste Wahl. Aber bei echtzeitrelevanten Anwendungen, etwa auch komplexes Softwaremonitoring durch viel processing durch, macht der gegen den höher getakteten i7 keinen Stich. Da kommt der i7 auch bei 32 samples richtig weit, während der xeon eigentlich erst ab 128 wirklich vernünftig einsetzbar ist.

Zum Thema Latenz,Jitter und verteilung von seriellen Prozessen hatte ich ja schon geschrieben. Ich hatte mal in einem Projekt probleme, wegen eines Jitters von 6 mikrosekunden. Ein Puffer selbst von nur 32 samples@44khz wäre da undenkbar. Aber selbst in diesem Scope werden mittlerweile multicore mcus eingesetzt, wenngleich die verteilung da vergleichsweise simpel ist, aber auch sein muss, weil man sonst zeitmässig einfach nicht hinkommt.

Ich weiss nicht, wer setzt PC-Audio Sequencer Software für echtzeit betrieb ein? Dafür gibts doch digitalmischpulte bzw dsp gestützte systeme? Aber natürlich liegt es in der Natur der sache, dass schnellere Taktraten für Echtzeitfähigkeit geeigneter sind, da gebe ich dir vollkommen recht. Und ohne Frage ist es in der DAW angenehmer zu arbeiten, wenn die latenz unter sammmer mal ~100ms bleibt... (mit allen plugins)

 

[Nachtschicht]

Es gibt zwei Szenarien bei denen diese Kombi aus niedrigsten Latenzen und vielen eher seriellen bearbeitungsketten wichtig ist, mit denen zumindest ich oft zu tun habe:

1. Softwaremonitoring bei grossen aufnahmesessions

2. Die Nutzung von Rechnern als Klangerzeuger im Kontext von Liveproduktionen.

Editiert
LM18