Der neue Mac Pro und seine Performance

  • Ersteller SilentWarrior
  • Erstellt am
Für mich sind das nur noch ungelenke Versuche Relevanz zu beweisen. Apple hat schon länger fertig... .
 
Na na na. Immer noch der... äh... drittgrößte Telefonhersteller der Welt.:respekt:
 
Das 256 SSD ein Witz ist, darüber brauchen wir nicht reden.

Hab ich am Anfang auch gedacht... aber das lag schlicht an der Perspektive. Wenn es um Bildbearbeitung geht, brauchst du nicht viel mehr. Bilder sind nicht groß. Wenn es um Videos geht, dann hast du, wenn in einem Umfeld Arbeitest in dem man 6k+ für Rechner ausgibt, definitv einen Server im Keller stehen auf dem die Daten zusammen laufen.

Einzig für Audioisten ist Plattenplatz IM Rechner interessant. Aber genau dafür ist das Ding ja auch Modular. Nichts spricht gegen eine 10 TB HDD für Sample Librarys.

Programmierst du Software sind 256 GB ebenfalls genug. Denn auch hier laufen dann die Datenbanken über Server.

Man sollte Sich bei dem Rechner und den Preisen mal anfangen davon zu verabschieden das hier ein Gerät für Hans Peter und Ich-AGs gebaut wurde. Der Mac Pro ist ein Workstation für Firmen mit Speziellen Ansprüchen. Das Ding ist nicht für den Massenmarkt. Von daher geht der Preis auch vollkommen Ok.

Und wer halt nen 6k Monitor mit 1600nits als erster auf den Marktwirft, der bestimmt dann halt auch die Party. Niemand zwingt die leute dazu den Monitor zu kaufen. Wenn du Ihn aber brauchst, kommts auf die 199 € für die Vesa Halterung auch nicht mehr an.

So ist es...
,aber amüsant finde ich, dass die 1600nits nur bei einer Temperatur von weniger als 25°C erreicht werden, was bei dem Klimanalagenwahn der Amis sicherlich kein Problem darstellt - trotzdem versteckt Apple dieses Kriterium geschickt mit einer Celsius Angabe in einer Fussnote auf der US Seite.;)
 
Er sagt ja auch : je grösser die Kette auf einer Spur desto mehr Performance wird geschluckt.

EDIT1: ein paar Ergänzungen Turbo Mode, Leistungsdaten CPU, Win7 vs Win10 performance
EDIT2: Ideal eingestelltes und performendes System unter Win7, ein paar LatencyMon screenshots kommentiert

Nein, die entscheidende Aussage von ihm ist, dass in einer Kette von Effekten das Audiosignal nur von einem thread bearbeitet wird. Der einzelne thread hat aber nichts von 28 Kernen, denn er läuft nur auf einem CPU core. Da Audiobearbeitung was mit Echtzeitbearbeitung zu tun hat, müssen die ganzen Berechnungen rechtzeitig fertig werden.

Wer seine Backing tracks mit vielen VSTi's bestreitet und zB selber Gitarre oder Drums über ein VSTi einspielt, der hat zusätzlich noch höhere Anforderungen an das System (Leistung, Agilität), weil man dann mit ASIO Buffersizes arbeiten muss (bei RME im Bereich 32 - 128), um noch unter 10ms RTL (Round Trip Latency) kommen zu können für den Weg von Audio von der Gitarre über das Interface, USB, zum Rechner, zur DAW und zurück bis zum Kopfhörer.

Wovon Du nun im Einzelnen mehr hast, vorn mehr cores oder einem höheren Systemtakt, kommt vor allem auf die Applikationen an. Ob sie mehr von Single Thread Performance oder einer höheren Anzahl von Cores profitieren.

Und bei einer DAW kommt es dann darauf an, wie Du Dein Projekt genau aufsetzt. Ob Du wirklich in alle möglichen Spuren einzelne VSTs als Inserts reinknallst oder versuchst, über Sends mit weniger Reverb Instanzen auszukommen. VSTi (synthetische Instrumente) werden vermutlich auch in einem thread ausgeführt und damit eine hohe Single Thread Performance benötigen.

Dann geht die Sache ja auch noch weiter, wie die CPUen aufgebaut sind und wie der Hauptspeicher an alle Cores angebunden ist. Weswegen bei AMD Threadripper (NUMA Architektur) mit höheren internen Latenzen zu rechnen ist.

Und dann kommt auch das große Thema, wie gut eine Applikation überhaupt viele Cores auslasten kann und in welchen Situationen: eine Recording / Mixing Situation ist was anderes, als wenn Du einen Downmix von Deinem Projekt machst.

Im Grunde genommen müßte man alles ganz genau wissen, tut man aber nicht. Man müsste alle mögliche HW ausprobieren, was für die eigenen Projekte am besten ist, aber die Zeit und das viele Geld hat man auch nicht.

Wenn man nicht so viele tracks oder VSTi's hat und nicht völlig idiotischerweise zu viele Inserts pro Spur verwendet wird idR schon alles gut gehen. Da man also nie nicht genau weiß, was alles kommen wird, kauft man sich am besten eine CPU, die man sich noch leisten kann und bei der die Anzahl der Kerne und der Takt in einem ausgewogenen Verhältnis zueinander stehen.

Ich habe mich damals zu einem Xeon basierenden System entschieden. In diesem Bereich gibt es einen Haufen von CPU Möglichkeiten, die auch jeweils Ihre eigenen Vorzüge haben, es gibt sogar auch CPUen, die durch einen höheren Cache brillieren, weil das möglicherweise im Datenbankbereich etwas mehr Performance bringt..

Da habe ich halt auch überlegen müssen, wo ist denn da eine für mich vernünftige Preis / Leistungsgrenze erreicht. Gamen wollte ich mit dem Setup auch, was auch eher nach mehr Single Thread Performance, sprich höherem CPU Takt schreit.

Ich bin einfach davon ausgegangen, dass ich folgendes benötige:
- einen hohen Mindesttakt von 3.5 GHz Pro CPU core haben möchte (-> hohe single thread performance)
- dass es diesmal mehr als 4 CPU kerne sein sollten
- Preis sollte €600 nicht überschreiten (früher hatte ich immer bei €300-350 die Grenze gesetzt)

Andere Aspekte:
- Mehrkerner werden sehr schnell sehr teuer
- ab einer bestimmten Leistung steigen die Preise überproportional
- an die Abwärme denken

Deshalb ist es vernünftig, die Leistung in Relation zum Preis zu setzen und mit gesundem Augenmaß zu schauen bis zu welchem Preis man eigentlich noch eine gute Leistung bekommt oder ab wann weitere Leistungssteigerungen einfach zu teuer werden.

Dafür hatte ich damals einen umfangreichen Excel Job gemacht und habe für diverse CPUen (Consumer und Xeon), die es 2014 zu kaufen gab, die Benchmark Werte eines gemischten Benchmarks (Passmark) in Relation zum Preis gesetzt.
Gefiltert welche CPUen über 3.5 GHZ Basis Takt und die beste Leistung haben und vom Preis/Leistungsverhältnis noch gut dastehen.
Somit hatte ich dann eine CPU gefunden, die meiner Meinung nach für alles geeignet sein sollte: Office, Gaming, DAW, Videobearbeitung

Ist nachher ein Xeon 6-kerner geworden (das war Stand Oktober ~2014)
Xeon E5-1650v3 mit 6 Cores / 12 threads, 3.5 GHz Basis Takt, 3.8 GHz Turbo für €545.

Aktuelle Leistungsdaten siehe hier
https://www.tonstudio-forum.de/blog...0-10-Performance-Test-400-Audio-Tracks-de-en/
und hier Cubase Vergleich Win7 vs Win10:
https://www.forum.rme-audio.de/viewtopic.php?pid=141931#p141931

Dann gibt es noch weitere Dinge zu beachten:
Der Turbo Takt wird nur unter bestimmten Bedingungen erreicht
- nur für eine gewisse Anzahl von Cores und
- wenn als Ausgleich dafür eine gewisse Anzahl anderer Cores runtergetaktet sind oder durch Windows geparkt sind
CPUen mit mehr kernen haben einen eher bescheidenen Basis Takt und der Turbo Takt liegt dann für einige wenige Cores viel höher als bei meiner CPU. Aber dann muss man das System auch so aufsetzen, dass Turbo erreicht werden kann und Takt Schwankungen erhöhen wieder etwas die internen Latenzen im System, denn eine CPU muss sich auch erstmal auf einen neuen Takt ein bisschen einschwingen, wesentlich längere Zeit braucht es, um aus einem Schlagzustand aufzuwachen, wzB verursacht durch Windows CPU core parking.

Es kommt auch sehr auf die CPU Generation ab und ist im Grunde genommen nichts anderes als ein Wärmeproblem, damit ein gewisser "TDP" Wert nicht überschritten wird.

Zum Thema Turbo takt. Wird meist eh nicht erreicht und man möchte auch keinen schwankenden CPU takt (-> interne Latenzen, zu messen mit LatencyMon)
Das heißt .. in einem System profitieren unter Umständen eh nur sehr wenige cores von der Turbofrequenz.

Cubase und AVX Kommandos: noch besser, Cubase verwendet komplexe Vektorbefehle (AVX instruction set) , damit laufen die CPUen meistens nur auf dem Basis Takt und nicht mehr. Beim Downmix eines Projekts läuft auf jeden Fall die ganze CPU nur auf Basis Takt wegen der Verwendung des AVX instruction sets.
Leider ist das bei Intel nur sehr schlecht dokumentiert wie hoch der Takt bei der Ausführung von AVX instructions ist.
Eine herbe Enttäuschung war die Nachfolgeversion der CPU, der E5-1650v4.
Die hatte eigentlich einen viel höheren Takt, 3.6 GHz Basis und 4 GHz Turbo.
Im normalen Betrieb erreichte sie einen stabilen Takt von 3.8 GHz.
Sobald Cubase lief, ist dann der Takt wegen der AVX Instruktionen auch auf 3.5 GHz runtergegangen, wie bei der alten v3er CPU. Was für eine Enttäuschung. Neuere CPU, kleinere Stukturen, weniger TDP, aber geht dann noch 100 MHz unter den Basis Takt auf nur 3.5 GHz ?!
Man muss also sehr aufpassen, die spannende Frage ist einfach, welchen Takt bekommt man am Ende des Tages raus, bei der Art und Weise wie das System zum einen eingerichtet ist (CPU core parking aus oder nicht, Turbo im BIOS aus oder nicht, EIST aus oder nicht) und wie die Applikation arbeitet oder ob sie diese AVX Kommandos verwendet.

Damit möchte ich einfach sagen, dass man sich darauf einrichten sollte, dass man meistens eh nur mit dem Basis Takt kalkulieren kann und sich die höheren Turbo Werte unter Umständen erstmal abschminken kann.

Konsequenz: wenn Du Dir also so ein Xeon Monster mit 28 Kernen holst, dann richte Dich darauf ein, dass Du nur den Basis Takt bekommst und die Turbo Frequenz unter umständen nie erreichst.

Taktänderungen, interne Latencen (-> LatencyMon, DPC Latenzen, etc)
Taktänderungen in einem System erzeugen sowieso einige interne Latenzen, die sich bei LatencyMon Messungen etwas bemerkbar machen. Insofern ist ein stabiler Basis Takt, der ständig anliegt, eh die bessere Wahl, vermutlich aber auch nur bei Desktop Systemen realisierbar, denn ein Laptop käme zu schnell in Thermische Probleme.

Bei meiner besagten Xeon E5-1650v3 CPU sieht das dann so aus.
Basis Takt erreiche ich immer: 3.5 GHz
Wenn das System keine AVX Befehle ausführen muss, dann sogar permanent 3.6 GHz.
Den Turbo Takt von 3.8 GHz erreicht mein System nie, weil ich CPU core Parking deaktiviert habe, um die internen System Latenzen zu minimieren. Somit legt sich kein Core schlafen, man muss nicht auf die Wiederauferstehung warten, aber halt kein Turbo.
Schlimm, nö,. dafür agiles System und man kann tendenziell mir geringeren ASIO buffer sizes arbeiten, damit es keine Audio Aussetzer gibt.

Wer sich also den dicken Mäckes da holt, der sollte sich vorher genau überlegen, was er braucht, mehr Kerne oder einen höheren Takt zwecks höherer Single Thread performance.

Und nie vergessen, es kommt auf die Applikationen an, jede DAW könnte für sich betrachtet anders reagieren. Und Cubase steht ja auch in dem Ruf, dass gewisse Dinge in einem Thread passieren müssen und nicht alles auf alle Cores verteilt werden kann so dass es zu einer gleichmäßigen und hohen Auslastung aller Cores kommt.

Was für ne CPU holen ohne eine Wissenschaft draus zu machen ?
Also einfach kucken, dass man in 2019 einfach ne aktuelle Intel CPU für €350 - 600 kauft.
Am besten mit Hyperthreading und größtmöglicher Anzahl Cores bei einem Basis Takt von mindestens 3.5 GHz.

Da wird man dann vermutlich bei einem 8 Kerner landen wzB diesem hier, der Leistungsmäßig oben mitspielt
https://geizhals.de/intel-core-i9-9900k-bx80684i99900k-a1870092.html €487
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i9-9900K+@+3.60GHz&id=3334

Der Rest (Apple etc) ist eigentlich völlig Humpe, die verwendeten Intel Xeons werden ja schliesslich auch in Windows Büchsen verbaut.

Das ganze ist wie auch bei allen anderen Anwendungen ein reines Applikations / Performance Thema und man sollte die Belange seiner Applikation kennen und dann die Hardware Auswahl darauf auslegen.

Wer auf geringe RTL (Round Trip Latencies) angewiesen ist, also kleinere ASIO Buffer sizes braucht, zB durch Einspielen mit VSTi's, der muss auf einige Dinge mehr acht geben (Performance, Hohen Takt für hohe Single Thread Performance, agiles getuntes System) als jemand, der nur ein paar Spuren sicher aufnehmen möchte und eine ASIO buffersize von 1024 oder sogar 2048 dafür einstellen kann.

Ideal eingestelltes und performendes System unter Win7
Gemessen mit LatencyMon 6.7 (Einstellung Kernel Latency Timer), auf einem unbelasteten System (ohne DAW aufgestartet) in etwa so aus ...

Man sieht, der Kernel Latency Timer kommt auf einem unbelasteten System runter bis auf 2 microsekunden. Das zeigt, dass die BIOS und Systemeinstellungen gut sind und die Cores durch nichts ausgebremst / laggy werden, sei es durch ungünstige BIOS oder Windows Einstellungen im Bereich Energy Saving. Jeder CPU core ist sofort da und die CPU kann sofort auf Last reagieren ohne erstmal aus einem Schlafzustand aufwachen oder den Takt ändern zu müssen. Das ist eine sehr notwenige Voraussetzung, wenn man viel mit VSTi's arbeitet und vor allem mit einem virtuellen Instrument etwas einspielen möchte. Dann muss man wie gesagt die ASIO buffersizes was runterdrehen um unter die 10ms RTL zu kommen. Wenn dann irgendwas die CPUs blockiert, schlechter Treiber oder Systemeinstellungen, dann gibt es mit höchster Wahrscheinlichkeit Audio Aussetzer.
Das ist der ganze Sinn und Zweck von ein paar Einstellungs/Tuning Massnahmen, um das zu vermeiden. Für das reine recorden von 30 oder mehr spuren und ASIO Buffersizes von 1024-2048 ist das ziemlich humpe. Es kommt immer drauf an, wie man mit dem System arbeiten will, weil eine DAW load je nach Anwendungszweck und Aufbau des Projektes sehr unterschiedlich sein kann.
LatencyMon v6.70 - Win7.jpg


Wenn man die Treiberliste nach höchster Ausführungszeit sortiert, sieht man wie effektiv die einzelnen Treiber performen und ob sie im ungünstigsten Fall zu lange die Cores blockieren.
Windows ist kein RealTime Betriebssystem. Eine laufende Treiber / Kernel / Interrupt Routine kann durch den Prozess Scheduler des Betriebssystems nicht unterbrochen werden. Das heißt, der Treiber blockiert den Kern so lange, wie es im Treiber kodiert ist. Wenn der Prozess Scheduler auch einen Audio Prozess auf diesen Kern legt, dann kommt es zu den berüchtigten Audio Aussetzern, die durch schlechte Treiber verursacht werden. Treiber müssen gut programmiert sein, nichts im Betriebssystem kann ihre Laufzeit (mit höchster Prio) aufhalten, das muss die gute Treiber Programmierung (einfache "Konventionen" an die sich Entwickler eigentlich halten sollten) richten .. bei manchen gehts, bei manchen eben nicht.
LatencyMon v6.70 - Win7 - Drivers sorted for highest DPC.jpg
 
Zuletzt bearbeitet:
Nein, die entscheidende Aussage von ihm ist, dass in einer Kette von Effekten das Audiosignal nur von einem thread bearbeitet wird.
Und der Thread wird doch größer je größer die Kette, oder verstehe ich da etwas falsch?
 
Nein, die entscheidende Aussage von ihm ist, dass in einer Kette von Effekten das Audiosignal nur von einem thread bearbeitet wird.
Und der Thread wird doch größer je größer die Kette, oder verstehe ich da etwas falsch?

Multi Thread Programmierung ist nicht so ganz ohne, denn wenn Du eine Task auf verschiedenen Cores ausführst, dann musst Du ja irgendwann auch die Teilergebnisse der Berechnungen mit einer Programmlogik (warten auf Ereignisse / Teilberechnungen) irgendwie und irgendwo wieder zusammenführen.

Vermutlich wird das alles viel zu kompliziert, weswegen man dann alle Inserts in einer Spur lieber von einem Prozess komplett durchrechnen läßt, als da noch einen gewissen overhead durch thread Progammierung einzugehen, was vielleicht auch einfach das Programm zu kompliziert werden läßt. Und eine zu große Anzahl aktiver threads kann sich uU auch negativ auf die Gesamtleistung des Systems auswirken.

Und diese Berechnung aller inserts im Rahmen eines Threads muss halt auch schnell duchgeführt werden. Je schneller, desto besser (also hohe Single Thread performance) damit das alles auch rechtzeitig fertig berechnet ist, denn das ganze muss ja noch uU durch ein paar Subgruppen, die auch wieder ein paar inserts geladen haben können und dann zum finalen Ausgang und auch da kann es wieder ein paar Inserts geben. Mal ganz ab von noch ein bisschen EQing im Kanalzug, was bei Cubase auch möglich ist und möglicherweise einen anderen thread wieder was "anfettet" von der workload.

Und das alles soll dann alles am Ende des Tages möglichst ohne Verzögerung und ohne Aussetzer in "Near Realtime" am Ausgang Deines Recording Interfaces über Monitor oder Phones gehört werden ...
 
@akl

Ich weiß nicht worauf die hinaus willst. Ich schrieb ja, je größer die Kette desto größer der Thread. Also je mehr Plugins auf einer Spur desto
mehr Stress. Darum ging es doch und genau das hat doch Apple bei dieser Präsentation vermieden wie mir scheint.
 
Nein, die entscheidende Aussage von ihm ist, dass in einer Kette von Effekten das Audiosignal nur von einem thread bearbeitet wird.
In Logic (10.4.4) kann man sehr schön sehen, dass nur die sog. Live-Spur auf einem Thread berechnet wird. Die Live-Spur ist die, die markiert ist, auf der "erwartet" Logic eine Aufnahme und packt deshalb diese Spur auf einen Kern/Thread. In der Prozessor-Auslastungsanzeige ist das immer der Thread ganz rechts.
Es war schon immer ein Trick in Logic, statt einer Softwareinstrumentenspur eine Spur ohne Last (leere Audiospur, external Midi) zu wählen, wenn's mal eng wurde. (Und man gerade nicht aufnehmen wollte)
Dann ist die Last auf mehrere Cores verteilt (auch die der ehemaligen Live-Spur), man sieht in der Auslastung keinen Peak mehr.
 
  • Danke
Reaktionen: akl
Es war schon immer ein Trick in Logic, statt einer Softwareinstrumentenspur eine Spur ohne Last (leere Audiospur, external Midi) zu wählen, wenn's mal eng wurde. (Und man gerade nicht aufnehmen wollte)
Das kannte ich noch nicht - und klingt interessant. Das heißt, wenn es beim Mixen ressourcentechnisch klemmt, einfach eine fake live - Spur erstellen, markieren und fertig?
 
@akl

Ich weiß nicht worauf die hinaus willst. Ich schrieb ja, je größer die Kette desto größer der Thread. Also je mehr Plugins auf einer Spur desto
mehr Stress. Darum ging es doch und genau das hat doch Apple bei dieser Präsentation vermieden wie mir scheint.

Ja, ich fragte mich nur, warum Du eine Rückfrage stelltest und habe dazu noch ein wenig ausgeholt, vielleicht einfach ein Missverständnis, aber im Grunde genommen scheint es uns ja beiden klar zu sein.
 
Das kannte ich noch nicht - und klingt interessant. Das heißt, wenn es beim Mixen ressourcentechnisch klemmt, einfach eine fake live - Spur erstellen, markieren und fertig?

Jo. Klappt eigentlich auch gut, mit der aktuellen Version auch besser als je zuvor, da die Lastverteilung auf die "nicht live" Threads mittlerweile sehr flutschig läuft, was vor der 10er nicht wirklich immer so war (da musste man besonders leistungshungrige Projekte oft mehrfach starten, bis die Verteilung hinhaute).
 
Das kannte ich noch nicht - und klingt interessant. Das heißt, wenn es beim Mixen ressourcentechnisch klemmt, einfach eine fake live - Spur erstellen, markieren und fertig?

Jo. Klappt eigentlich auch gut, mit der aktuellen Version auch besser als je zuvor, da die Lastverteilung auf die "nicht live" Threads mittlerweile sehr flutschig läuft, was vor der 10er nicht wirklich immer so war (da musste man besonders leistungshungrige Projekte oft mehrfach starten, bis die Verteilung hinhaute).

Frage mich warum die dann nicht sowieso einfach eine fake Spur einbauen, per default. Das sollte doch nicht so schwierig sein, oder will man das aus irgendeinem Grund auch nicht ??
 
Frage mich warum die dann nicht sowieso einfach eine fake Spur einbauen, per default.
Wie willst Du das machen? Ein leere "Geheimspur", die prinzipiell besteht, und auf die umgeschaltet wird, wenn ich Play drücke?
Würde nicht automatisch umgeschaltet, brächte sie ja nix.
Dann verliere ich aber den Vorteil der Live-Spur. Ich kann, wenn ich will, schon mal dazuspielen. Jedes mal Logic erst davon zu überzeugen, dass ich zwar nicht aufnehmen will, aber trotzdem gerne spielen will, wäre nervig.
Spuren will ich nur haben, wenn ich sie auch erzeuge.
Und das ist ja auch ein Klacks: "Alt-cmd-X" -> Neue Midispur. Evtl. "Alt-C" -> Farbauswahl und die Spur passend einfärben, damit man sie leichter findet - fertig.
 
Frage mich warum die dann nicht sowieso einfach eine fake Spur einbauen, per default.
Wie willst Du das machen? Ein leere "Geheimspur", die prinzipiell besteht, und auf die umgeschaltet wird, wenn ich Play drücke?
Würde nicht automatisch umgeschaltet, brächte sie ja nix.
Dann verliere ich aber den Vorteil der Live-Spur. Ich kann, wenn ich will, schon mal dazuspielen. Jedes mal Logic erst davon zu überzeugen, dass ich zwar nicht aufnehmen will, aber trotzdem gerne spielen will, wäre nervig.
Spuren will ich nur haben, wenn ich sie auch erzeuge.
Und das ist ja auch ein Klacks: "Alt-cmd-X" -> Neue Midispur. Evtl. "Alt-C" -> Farbauswahl und die Spur passend einfärben, damit man sie leichter findet - fertig.

War nur eine fixe Idee, kenne mich mit logic nicht aus.
 

Ähnliche Themen


Oft gelesene Themen

Zurück
Oben