News: M4 mac minis, 2024 (gerne auch für Mac studio). Erste Leaks

[siebenachtel]

dir ist schon klar, dass das rechnerisch in etwa einer viertelmillion stereospuren in 32 bit entspricht?

hmm, irrelevant ! weil: anderes Thema (sprich: man muss zwischen verschiedenen usecases differenzieren)

oder dass man damit in 0,3 sekunden eine bluray kopieren kann.

wieder: irrelevant ! weil: anderes Thema (sprich: man muss zwischen verschiedenen usecases differentieren)

Du sprichst von irgendwelchen usecases und schonglierst mit Zahlen die in Bezug zu meinem usecase nur theoretischer Natur sind. Meine Erfahrungen waren real live. Ich deale nicht mit files abspielen, sondern damit, audio das grad frisch berechnet wurde in echtzeit zu manipulieren.

Deine Zahlen mögen stimmen. Das stelle ich nicht in abrede.
Aber die haben wie erwähnt nichts mit meinen real-live Erfahrungen zu tun, die auf ner ganz anderen Ebene abliefen.
Der Punkt bei mir ist echtzeit manipulation von seriell gestaffelten Daten. Die manipulation geschieht an zig punkten gleichzeitig. Müsste eigentlich PC-intern ein ganz normaler Vorgang sein. Aber: hier dealen wir mit verketteten plugins in meinem Falle. Und das audio soll halt nicht crackeln ! k.A. wieso das so ist. Aber der hohe Datendurchsatz ändert da was bzgl. gewisser ganz spezifischer usecase szenarien.

ich habe den M1mac in Bezug zum Datendurchsatz in die knie gefahren ! Das ist real. (und: reproduzierbar)
Der M1 hat 100GB/sek Datendurchsatz.
Am M2 ist es mir nie passiert.
Der hat 200GB/sek Datendurchsatz.


Aber ok, ums komplett zu machen:
Dass dabei der Datendurchsatz das Nadelöhr war ist eine reine Vermutung von mir.
Sehe aber nichts anderes was es hätte sein können.
An der CPU lags nicht. Die war teils nur mittlemässig ( 1 Kern) teils sogar weniger, belastet.
Das mit dem Datendurchsatz hat in Bezug zu meinem Szenario auch ne gewisse Logik. Am M2 hatte ich selbige Probleme wie gesagt nie.


mittlerweile gibts btw. viel mehr Benchs zum M4.

Mein M2pro schaut im Vergleich zu anderen M2pro Werten nicht sehr gut aus. Hab den gestren mal gemessen.
M4er haben teils effektiv umd die 50% mehr Leistung als wie ein M2. Auch single Core.
Das ist dann 10core vs. 8core. aber bei beiden M2 udn M4 4x P-Kerne. (bzgl. der Daten die ich direkt Vergleiche)

Was ich mitbekommen habe ist dass man so tests nicht zu früh machen soll. Das System muss da was indizieren, oder wie auch immer. Jedenfalls laufen da anscheinend gewisse routinen im Hinterhrund ab am Anfang. Gewisse M4 benchs sind auch komisch tief. Einer komisch hoch. ( was ich gestern gesehen hatte). die tiefen werte basieren anscheinend oft darauf dass Leute das zu früh testen.


Ist auch die Frage woher die M4 Tests kommen. Anscheinend gabs ein Meeting in L.A..
Möglicherweise kommt das aber auch von Beta maschienen die jetzt vielleicht "dürfen".

Eins ist jedenfalls sicher:
Diese M4er sind sauschnell !
Der sprung vom M3 zum M2 war grösser als wie vom M2 zum M1.
Jetzt ist der sprung nochmals etwas grösser.
Wer vom M2 kommt hat das surplus von 2 generations jumps.

 

[einseinsnull]

hmm, irrelevant ! weil: anderes Thema (sprich: man muss zwischen verschiedenen usecases differenzieren)

was an deinem usecase (soweit mir bekannt) bedarf denn eine speicherbandbreite höher als 120gb/s?

ja, ich weiß, bei single core prozessen ist die speicherbandbreite natürlich entsprehend kleiner. aber doch immer noch viel mehr als du brauchst.

Ich deale nicht mit files abspielen, sondern damit, audio das grad frisch berechnet wurde in echtzeit zu manipulieren.

die anforderungen an den maximalen speicherdurchsatz sind für lesen/schreiben/bearbeiten identisch mit dem für lesen/schreiben ohne bearbeitung. das gilt um so mehr für audio oder video, was in blöcken verarbeitet wird. es ist ja jetzt nicht so, dass wenn einhall plug-in aus 1000 filtern besteht, dass die einzeln prozessed und zwischendurch wieder wo hingeschrieben werden würden.

hast du da schon mal erlebt, dass etwas nicht berechnet werden konnte weil das RAM zu langsam war? während der prozessor noch luft gehabt hätte?

 

[siebenachtel]

ja, ich weiß, bei single core prozessen ist die speicherbandbreite natürlich entsprehend kleiner.

eben

aber doch immer noch viel mehr als du brauchst.

das weiss ich nicht.

Für mich siehts anders aus.
Ne Bestätigung dass das was ich denke auch richtig ist habe ich aber nicht. (Wie bereits erwähnt)
Aber es ist -für mich- die einzig mögliche logische Erklärung.

es ist ja jetzt nicht so, .............., dass die einzeln prozessed und zwischendurch wieder wo hingeschrieben werden würden.

"ich denke" das ist bei meinem Prozess haargenau der Fall.
Deins ist da btw. auch wieder nur ne Vermutung


Delay -> audio wird in den Buffer geschrieben -> der buffer (gespeichertes audio)wird ausgelesen -> der Zeit parameter des delays wird manipuliert ( das delay steht dabei im kleinen ms bereich, inkl. aufgedrehtem FB)
-> dieses manipulierte audio geht ins nächste delay ( ähnliche Einstellungen). Wird also erneut in nen buffer geschrieben,....und wird erneut ausgelesen -> dieses Delay wird auch im Zeit parameter manipuliert, -ZEITGLEICH-,
-> dieses audio geht in noch ein delay, selbe Geschichte ! wird auch -ZEITGLEICH- manipuliert.
Weiss nicht bis wie weit ich das jeweils getrieben habe. 4 stück delays hintereinander ganz sicher. Hab aber ein delay verwendet gehabt das in sich selbst delays stacken kann........


also mehrfach seriell hintereinander, audio in buffer schreiben, dieser Inhalt des buffers wird manipuliert während es ausgelesen wird.
alles mehrfach hintereinander.
ALLE Delays werden zum gleichen zeitpunkt manipuliert !
D.h. es ist immer der inhalt des buffers der jetzt -als audio- manipuliert wird, und damit den sound ändert.
Das ist echtzeit sounddesign, FXing in serieller abfolge, während die manipulation auf allen verarbeitungsstufen nicht seriell, sondern parallel erfolgt.

Die delays stehen dabei nicht nur im kleinen ms bereich was den Zeitfaktor angeht. Die manipulation geschieht mit nem fader den man sehr schnell bewegt. ( Das sind alles Faktoren die hier mit rein spielen in Bezug zu, was geht und was nicht)


und jetzt sag du mir ob das Sinn macht zu denken dass ich "so" das ganze Ding am Datendurchsatz an die Grenze bringen kann ?






Dass das alles kein Problem wäre, wenn alles innerhalb eines einzigen plugins abliefe, das ist mir klar. Ich sehe es jedenfalls so.
Aber der ganze ablauf auf mehrere plugins verteilen ?
Scheint was zu ändern

Dann fängt das irgendwann an zu zicken.
Und ich behaupte jetzt, dass ein schnellerer Datendurchsatz da bei dem ganzen hilft.
Da ist ne Relation zu sehen.
Das behaupte ich so.
hab da ausführliche tests gemacht gehabt (auf dem M1)



Daraus leite ich im weiteren ab, das wenn du in ner DAW sehr viel automatisierst, dann zwar anders aufgebaut, aber allenfalls auf vielen Tracks gleichzeitg, dass du dort -wenn alles blöd geht- allenfalls auch ans limit des datendurchsatzes kommen kannst.

Der springende Punkt ist aus meiner Sicht definitv das Ding mit "audio in nen Buffer schreiben", ...wieder auslesen, wieder in nen buffer schreiben.
also delays + Reverbs sind hier die ersten kandidaten.

Weiss nicht. Ich würde bei nem "teureren" PC auf Nummer Sicher gehen wollen.


Der DAW hilfts aber dass die auf vielen Kernen arbeiten kann.
Drum hilfts umgekehrt auch mehr Kerne zu nehmen als man von der reinen CPU gesammtpower vielleicht brauchen würde.
Die DAW kann dann die Lasten einfacher verteilen.

 

[einseinsnull]

Delay -> audio wird in den Buffer geschrieben -> der buffer (gespeichertes audio)wird ausgelesen

ja ja, das ist schon klar, bei verzögerungen oder bei transferfunktionen schreibt man auch mal ausnahmsweise was in den hauptspeicher. das merkt ein M4 aber überhaupt nicht. da kannste nebenher noch 3 videos schauen.

-ZEITGLEICH-,
-> dieses audio geht in noch ein delay, selbe Geschichte ! wird auch -ZEITGLEICH- manipuliert.

ist auch richtig, letztlich kommt es nur auf die potentiellen spitzen an.

Weiss nicht bis wie weit ich das jeweils getrieben habe. 4 stück delays hintereinander ganz sicher.

4 feedback delay effekte hintereinander mache ich dir auf einem 604e prozessor von 1993.

dass der datendurchsatz des speichers dabei eher an seine grenzen kommt als die CPU, die dieses auslesen und bearbeiten ja auch erledigen könenn muss, können wir gestrost ausschließen, ohne es evident beweisen zu müssen. selbst bei einem delay. (wobei man auch nicht unterschätzen sollte, was ein richtig gutes delay macht: komplexe interpolation bei hochsampeln, antialiasing filter nach dem upsamplen usw.)

ALLE Delays werden zum gleichen zeitpunkt manipuliert !
D.h. es ist immer der inhalt des buffers der jetzt -als audio- manipuliert wird, und damit den sound ändert.

das passiert alles in blöcken. erst wenn die queue voll ist feierabend.

und jetzt sag du mir ob das Sinn macht zu denken dass ich "so" das ganze Ding am Datendurchsatz an die Grenze bringen kann ?

man kann alles an seine grenze bringen wenn man nur genug #irgendwas aufmacht. aber sicherlich nicht mit 4 plug-ins.

nehmen wir noch mal meine naive "berechnung" von oben.

wenn 10 kerne 120 gb/s haben, dann hat 1 kern immerhin noch 12 gb/s.

jetzt nehmen wir mal großzügg an, dass nur 25% des unified RAM in schnitt für GP zur verfügung stehen, weil du gerade auch viel mit video macht und noch 3 andere programme auch offen sind.

aus der "viertelmillion streams" die ich oben behauptete, die sich auf 32bit/44khz/mono bezogen, würden selbst bei 64bit/4-fach oversampling und in stereo immer noch 1500 solcher streams übrig bleiben.

1500x32 samples passen noch auf den cache eines G4 server prozessors aus dem jahr 2002. das RAM bekommt von dem vorgang erst nach dem VST slot etwas mit. die CPU hingegen macht lange vorher schlapp.

ich würde mal behaupten, dass hauptspeicher immer schnell genug angebunden sind um die CPU voll auszulasten. vermutlich selbst bein bloßen auslesen von daten.

hab da ausführliche tests gemacht gehabt (auf dem M1)

es gibt doch analyse tools dafür, dir dir zeigen, was so passiert. ist nur in bezug auf die CPU als vergleichsgröße manchmal nicht ganz einfach.

Daraus leite ich im weiteren ab, das wenn du in ner DAW sehr viel automatisierst, dann zwar anders aufgebaut, aber allenfalls auf vielen Tracks gleichzeitg, dass du dort -wenn alles blöd geht- allenfalls auch ans limit des datendurchsatzes kommen kannst.

wenn die steuerdaten eine höhere priorität haben wie das audio, dann stören sie die bearbeitung von audio streams. ob sich im DPS irgendwas live ändernt oder nicht, sollte allerdgins egal sein. dadurch werden nicht mehr daten geschrieben, falls denn überhaupt.

was sagt denn dein CPU meter in sochen fällen? hyperthreading macht da je mehr probleme, bei einer ein-kern oder ein-prozessor anwendung sollte manin einem audioprogramm durchaus bis zu 90% auslastunganzeige kommen können.

Der springende Punkt ist aus meiner Sicht definitv das Ding mit "audio in nen Buffer schreiben", ...wieder auslesen, wieder in nen buffer schreiben.
also delays + Reverbs sind hier die ersten kandidaten.

reverbs sollen sowas nicht machen. über welches delay reden wir? ein bestimmtes produkt?