Mac Mini und Grafik

  • Ersteller TedStriker
  • Erstellt am
nun ist video insofern bisschen was anderes weil video sowieso grösstenteils ne streaming-angelegenheit ist. ich hab das 8GB modell erst gekauft nachdem zahlreiche nerd-benchmarker verblüfft festgestellt haben, dass sich das verhalten im arbeitsalltag zwischen dem 8 und 16GB modell nicht nennenswert unterschieden hat. bei audio kann das natürlich was anderes sein. also wenn man grösstenteils audio macht, also audiotracks und mixing, dann ist das kein problem. auch virtuell analoge instrumente sind eher nicht so das problem, zumindest die simpleren vertreter nicht. aber wenn man natürlich mit sample libraries um sich wirft, dann sind 8GB natürlich zuwenig und je nachdem um welche libraries es sich handelt eigentlich 16GB auch noch. da kann apple natürlich was von anderer speicherverwaltung dem pferd erzählen soviel sie wollen, ne library die ram menge X braucht, braucht diese menge, und wenns die nicht gibt, kriegt dein system ordentlich extralast mittels auslagerungsaktivität verabreicht, was insbesondere bei niedrigen latenzen dann auch kein spass ist.

Das Video sowieso nur streaming ist, behauptet nur jemand, der noch nicht mit mehreren, größeren Videodaten in einem Schnittprogramm gerendert hat.

Wo soll denn ein Unterschied sein bei Daten, die den RAM füllen? Vielleicht schnelle oder langsame Daten? Daten belegen RAM und aus wessen Quelle (Video, Audio, Library) sie stammen, ist völlig egal. Sind nur Nullen und Einsen und unterschiedlich komplex angeordnet.

Der M1 ist in der Datenverarbeitung aufgrund seiner Architektur schneller als ein konventioneller Prozessor im modularen Aufbau mit RAM Riegeln. Stichwort Unified Memory.

Beim M1 sitzt zwischen Grafikprozessor und den Prozessorkernen eine einheitliche Speicherarchitektur, deshalb wird der M1auch System on Chip genannt. Genau das bringt den Geschwindigkeitsvorteil, denn es ist ein einziger Pool auf den jeder Teil des Prozessors zugereifen kann, wenn die Daten benötigt werden.

Intel Chips mit integrierten Grafikchip sind übrigens genauso aufgebaut wie ein M1.
Aber eine dedizierte Grafikarte ist genauso wie die RAM Riegel im modularen Aufbau beim PC per BUS an den Prozessor gekoppelt. Die BUS Taktung des RAM Riegel oder der Grafikkarte ist hier der Geschwindigkeitsbegrenzer.

Genauso das ist aber beim M1 aufgrund der SoC Architektur mit Unified Memory nicht geben und deshalb ist der M1 auch schnell.

Genau das bestätigst du auch mit deiner Entscheidung von 16GB abzusehen und auf 8GB zu setzen, weil der Unterschied für dich nicht nenneswert ist. Nenneswert wird er aber genau in dem Moment, wo mehr RAM benötigt wird; völlig egal aus welcher Quelle diese Daten angefordert werden.

Bei Windows wie bei Mac müssen, wenn die RAM Kapazität erreicht ist, Daten ausgelagert werden. Da sind beide OS gleich langsam, denn keine SSD, die immer mit einem BUS angebunden ist, kann schneller sein als der Zugriff aus dem RAM. Insofern ist dein Argument mit den Latenzen technisch betrachtet bei Windows genauso gegeben wie beim Mac.

Interessant wird es, wenn der RAM und die Anzahl der Kerne beim Nachfolger des M1 größer werden. Dann spielt der Mac deutlich den Vorteil von SoC Architektur mit Unified Memory aus. Die Zugriffs- und Verarbeitszeit von Daten wird aufgrund der dazu im Vergleich niedrigen BUS Taktungen von RAM und Grafikkarte, die beim modularen PC nun mal per Architektur existent sind, immer schneller sein. (Nebenbei erwähnt sind die maximalen 16GB RAM nicht Apples Arroganz geschuldet, sondern einzig und allein dem Umstand, dass zum Zeitpunkt(Frühjahr 2019) der Konfiguration und Produktion des M1 garkeine größeren 4266 MHz LPDDR-DDR4X RAMs existent waren)

Noch interessanter wird es, wenn man dem Nebensatz, der in der WWDC fiel, mit einbezieht. Da wurde gesagt, dass Xcode demnächst die Möglichkeit auf OS 15 bietet jeden einzeln Kern des Chips individuell per Programmierung zukünftig ansprechen zu können. Quasi ein Kern Loadbalacing per Programmierung. Wenn das - z.Zt. kenne ich noch keine weiteren Details - real wird, kann Intel mit dem herkömmlichen System der Datenschleusung von RAM -> L1 -> L2 -> Prozessor zukünftig Geschwindigkeitsmässig einpacken. (Deshalb hat Intel auch gerade 20Mrd $ in neuen Fertigungen für Großkunden in Arizona investiert, um dort explizit ARM Chips in 7nm produzieren zu können)

Aber egal was wird, unstrittig ist, das die SoC Architektur Geschwindigkeitsvorteile gegenüber jedem modularen PC bietet und dass RAM, der tradionell teurer beim Mac ist, zukünftig beim ARM mit mehr als 8 Kernen eine Rolle spielt. Wie die RAM Kapazität dann zu bewerten ist, wird sich zeigen, denn vergleichbar mit dem klassischen Intel Ansatz ist ja sie heute schon nicht mehr wie die Benchmarks beweisen.
 
Du hattest mich mit "die Benchmarks beweisen".
 
Echt? Ich hätte schwören können der TE hatte ein Problem mit der Videoleistung
Das wurde ja auf den Seiten 1-3 abgehandelt, ich glaube schon auf Seite 1.

Vielen Dank an alle für die fachkundigen Kommentare. Die haben mir bei der Entscheidungsfindung sehr geholfen
Zu was für einer Entscheidung biste den gekommen? Aufrüsten? Neukauf? Abwarten und dann zuschlagen?

Aufrüsten kommt jetzt auf keinen Fall in Frage. Bei den paar aufwändigen Video-Sachen, die ich mit meinen rudimentären Grafikkenntnissen mache, ist der Leidensdruck einfach nicht hoch genug. Und wenn ich es dann doch irgendewann nicht mehr aushalte, geht's in Richtung M1. Mal schauen, was Apple da in Zukunft noch so alles auf den Markt bringt. Das könnte ja durchaus spannend werden. Insgeheim spekuliere ich auf sowas wie einen Mini Pro.
 
Bei den paar aufwändigen Video-Sachen, die ich mit meinen rudimentären Grafikkenntnissen mache, ist der Leidensdruck einfach nicht hoch genug. Und wenn ich es dann doch irgendewann nicht mehr aushalte, geht's in Richtung M1.

Keine Ahnung, ob das hier schon erwähnt wurde, aber der M1 bietet keinen eGPU support an. eGPUs werden zwar erkannt, können aber nur auf Monterey fähigen Intel Macs betrieben werden.
 
Keine Ahnung, ob das hier schon erwähnt wurde, aber der M1 bietet keinen eGPU support an. eGPUs werden zwar erkannt, können aber nur auf Monterey fähigen Intel Macs betrieben werden.

War nicht die Rede davon, dass sich das wohl bald ändern würde?
 
Keine Ahnung, ob das hier schon erwähnt wurde, aber der M1 bietet keinen eGPU support an. eGPUs werden zwar erkannt, können aber nur auf Monterey fähigen Intel Macs betrieben werden.

War nicht die Rede davon, dass sich das wohl bald ändern würde?

Es wurde spekuliert von den üblichen Verdächtigen, würde ich sagen.

Ich bezweifele einen Support von eGPUs in naher Zukunft erstmal. Später könnte es sicherlich möglich sein, das aber frühestens nach dem Apple die Transition abgeschlossen hat.

Es gibt features auf Monterey, die nur auf Macs mit M verfügbar sind: Facetime mit Bouquet Mode, Live Text Copy, interaktiver 3D globe in maps, text2speech in verscchiedenen Sprachen, zeitlich unlimitiertes diktieren von Texten.

Warum sind diese features auf Intel Macs nicht verfügbar?
MMn, weil die Grafik features rein code basiert sind und sie dafür die neural engine benötigen, die auf Intel nicht existent ist. Neural engine ist Bestandteil des A14x+ Chips vom M1.
Die Text features (text2speech in verschiedenen Sprachen, zeitlich unlimitiertes diktieren von Texten) benötigen Apple Silicon, das es auch nicht auf Intel Macs gibt.

Daraus kann man schlußfolgern, dass Grafikanwendungen, die beim M1 in den Grafikchips und teilweise in den cores (mit)berechnet werden eine Api für externe Grafikkarten benötigen würden.
Das fehlerfrei zu bewerkstelligen, stelle ich mir ziehmlich aufwendig vor. Einen SoC zu programmieren, der zwischen interner (M) und externer (eGPU) Grafik hin und her switchen kann, ist definitiv eine Herausforderung aufgrund der SoC Architextur und ihrern gegebenen Funktionalität. (Bei modularer Architektur im Mac bei dem Prozessor(mit integrierten Grafikchip) und zusätzlich dedizierter Grafikkarte ist das bereits seit Jahren gelöst.)
Auch das Problem einer schnellen Anbindung(Port) einer eGPU muss gelöst werden muss. Ob Thunderbolt 3 beim M1 mit max 40Gb/s dafür ausreichend Feuer hat, um nicht zur Bremse im Datenflow zu werden, ist quasi die Frage.
 

Intel Chips mit integrierten Grafikchip sind übrigens genauso aufgebaut wie ein M1.
Das stimmt so nicht. Vgl. Unified Memory (Apple) vs Shared Memory (bei Intel)

Du solltest schon zwischen Architektur und Wirkungsprinzip unterscheiden.
Deshalb habe ich von auch "aufgebaut" und der Bedingung Intel Chips mit integrierten Grafikchip gesprochen.

Der Unterschied im Aufbau ist, dass beim shared memory ein dezitierter RAM als Modul verwendet wird während beim M kein dezierter RAM vorhanden ist, da er Bestandteil des SOCs ist.
Fällt der dedizierte RAM (= shared memory) weg und befindet sich der RAM im Chip, spricht man von unified memory.
 

Intel Chips mit integrierten Grafikchip sind übrigens genauso aufgebaut wie ein M1.
Das stimmt so nicht. Vgl. Unified Memory (Apple) vs Shared Memory (bei Intel)

Du solltest schon zwischen Architektur und Wirkungsprinzip unterscheiden.
Deshalb habe ich von auch "aufgebaut" und der Bedingung Intel Chips mit integrierten Grafikchip gesprochen.

Der Unterschied im Aufbau ist, dass beim shared memory ein dezitierter RAM als Modul verwendet wird während beim M kein dezierter RAM vorhanden ist, da er Bestandteil des SOCs ist.
Fällt der dedizierte RAM (= shared memory) weg und befindet sich der RAM im Chip, spricht man von unified memory.
Ich bin begeistert…
Der Punkt ist doch, dass beim Shared Memory einfach ein Bereich des RAMs „abgezweigt“ für die GPU ist. Der RAM selbst liegt aber aber außerhalb. Beim Unified Memory können alle CPU Bestandteile gleichermaßen und gleichzeitig innerhalb des SOCs zugreifen, und Grafikdaten müssen nur einmal vorgehalten werden und nicht zum GPU dedizierten Soeicher hin- und hergeschoben werden, oder?
 

Intel Chips mit integrierten Grafikchip sind übrigens genauso aufgebaut wie ein M1.
Das stimmt so nicht. Vgl. Unified Memory (Apple) vs Shared Memory (bei Intel)

Du solltest schon zwischen Architektur und Wirkungsprinzip unterscheiden.
Deshalb habe ich von auch "aufgebaut" und der Bedingung Intel Chips mit integrierten Grafikchip gesprochen.

Der Unterschied im Aufbau ist, dass beim shared memory ein dezitierter RAM als Modul verwendet wird während beim M kein dezierter RAM vorhanden ist, da er Bestandteil des SOCs ist.
Fällt der dedizierte RAM (= shared memory) weg und befindet sich der RAM im Chip, spricht man von unified memory.
Ich bin begeistert…
Der Punkt ist doch, dass beim Shared Memory einfach ein Bereich des RAMs „abgezweigt“ für die GPU ist. Der RAM selbst liegt aber aber außerhalb. Beim Unified Memory können alle CPU Bestandteile gleichermaßen und gleichzeitig innerhalb des SOCs zugreifen, und Grafikdaten müssen nur einmal vorgehalten werden und nicht zum GPU dedizierten Soeicher hin- und hergeschoben werden, oder?

Ja so funktionierts.
Damit Apple hat einen Chip designed, der sehr große Datenmengen sehr schnell und mit maximaler Effizenz "bewegen" kann. Dabei entfallen beim M die sonst üblichen Speicher (L1, L2, RAM) und das üblicherweise benötige hin- und her kopieren von Daten zwischen diesen und/oder einer dedizierten Grafikkarte.

Hinzu kommt der Designvorteil des M, dass CPU, GPU, ISP (Image processing unit), DSP (Digital signal processor), NPU (Neural processing unit) quasi spezialiisert und arbeitsteilig zu einander die Daten verarbeiten.

Was ich auch als Erklrärung betrachte, dass der M mit mehr RAM nicht schneller, aber bei zunehmender Datenmenge kontinuierlich leistungsfähiger bleibt als ein Intel.
Der Intel wird unter gleicher Voraussetzung in eine extreme Leistungsaufnahme von Watt gepusht, um quasi durch "energetisches übertakten" die Rechenoperationen zu maximieren. Dass führt dann bekanntlich schnell zu entstehender Mehrwärme und Überhitzungsgefahr, die dann aufwendig abgekühlt werden muss oder eine schnellere "Runtertaktung" nach sich zieht.
Der M ist deshalb nicht nur schnell, sondern er verbraucht dabei auch noch sehr wenig Energie und produziert entsprechend weniger Wärme.
 
Das Video sowieso nur streaming ist, behauptet nur jemand, der noch nicht mit mehreren, größeren Videodaten in einem Schnittprogramm gerendert hat.

deswegen habe ich ja auch nicht gesagt "nur" sondern eine graduelle formulierung benutzt, die du dann weggelassen hast. aber als jemand, der "mit mehreren, größeren Videodaten in einem Schnittprogramm gerendert hat" präzisiere ich gerne, um weiteren missverständnissen (absichtlich oder unabsichtlich) vorzubeugen:

eine passende analogie wäre ein sampler mit disk streaming, welches vorzugsweise dann verwendung findet, wenn (surprise) grosse datenmengen im spiel sind. selbstverständlich bedeutet dies nicht, dass ein grosser komplexer kontakt patch "nur" (deine formulierung) streaming betreibt und keinerlei ram braucht, aber er braucht eben weniger ram als man bei althergebrachter audiodenke über sampler ("dieser patch ist 128 MB gross, also brauche ich dafür 128 MB ram") annehmen würde.

nur darum geht es, nicht mehr, nicht weniger. dass es selbstverständlich noch zahlreiche andere formen des speicherbedarfs gibt, bestätige ich dann mal besser präventiv, bevor das auch noch gesplaint wird.

Wo soll denn ein Unterschied sein bei Daten, die den RAM füllen? Vielleicht schnelle oder langsame Daten? Daten belegen RAM und aus wessen Quelle (Video, Audio, Library) sie stammen, ist völlig egal. Sind nur Nullen und Einsen und unterschiedlich komplex angeordnet.

...da du hier mit einer absolutistischen behauptung streitest, die gar nicht meine war, überspringe ich mal bisschen was...

Genau das bestätigst du auch mit deiner Entscheidung von 16GB abzusehen und auf 8GB zu setzen, weil der Unterschied für dich nicht nenneswert ist. Nenneswert wird er aber genau in dem Moment, wo mehr RAM benötigt wird; völlig egal aus welcher Quelle diese Daten angefordert werden.

richtig, und wo dieser moment liegt, kann man anhand von real life benchmark tests gut nachvollziehen, also sieht man sich diese an, sieht dass sich der flaschenhals erst ab einem punkt einstellt der für die eigenen anwendungen (und arbeitsmethode) nicht von belang ist, und gut is.
es kann zudem einen riesen unterschied machen, mit welcher methode du arbeitest. wenn man z.b. wie ich eher mit multicam clips arbeitet nimmt einem zumindest resolve da sehr viel verwaltung (deaktivierung gerade nicht benötigter streams etc) aus der hand. bis zu 16 kamerafeeds laufen da höchst problemlos, livepreview immerhin noch bei halbem proxy sehr flüssig - für das bisschen geld absolut beachtlich. länge der projekts nahezu egal, und da ich jenseits von diversen farbkorrekturen (die sich ebenfalls in multicamclips selber ressourcenmanagen) und sehr grundlegenden edits jetzt keine speicherintensiven fusion-orgien benutze bzw solche dann auch als compound clip stressfrei auslagern kann, ist da sehr viel mehr luft im grünen bereich als man erstmal vermuten würde.

Bei Windows wie bei Mac müssen, wenn die RAM Kapazität erreicht ist, Daten ausgelagert werden. Da sind beide OS gleich langsam, denn keine SSD, die immer mit einem BUS angebunden ist, kann schneller sein als der Zugriff aus dem RAM. Insofern ist dein Argument mit den Latenzen technisch betrachtet bei Windows genauso gegeben wie beim Mac.

(Loriot)
Ach was!
(/Loriot)
 
Das Video sowieso nur streaming ist, behauptet nur jemand, der noch nicht mit mehreren, größeren Videodaten in einem Schnittprogramm gerendert hat.

deswegen habe ich ja auch nicht gesagt "nur" sondern eine graduelle formulierung benutzt, die du dann weggelassen hast. aber als jemand, der "mit mehreren, größeren Videodaten in einem Schnittprogramm gerendert hat" präzisiere ich gerne, um weiteren missverständnissen (absichtlich oder unabsichtlich) vorzubeugen:

eine passende analogie wäre ein sampler mit disk streaming, welches vorzugsweise dann verwendung findet, wenn (surprise) grosse datenmengen im spiel sind. selbstverständlich bedeutet dies nicht, dass ein grosser komplexer kontakt patch "nur" (deine formulierung) streaming betreibt und keinerlei ram braucht, aber er braucht eben weniger ram als man bei althergebrachter audiodenke über sampler ("dieser patch ist 128 MB gross, also brauche ich dafür 128 MB ram") annehmen würde.

nur darum geht es, nicht mehr, nicht weniger. dass es selbstverständlich noch zahlreiche andere formen des speicherbedarfs gibt, bestätige ich dann mal besser präventiv, bevor das auch noch gesplaint wird.

Wo soll denn ein Unterschied sein bei Daten, die den RAM füllen? Vielleicht schnelle oder langsame Daten? Daten belegen RAM und aus wessen Quelle (Video, Audio, Library) sie stammen, ist völlig egal. Sind nur Nullen und Einsen und unterschiedlich komplex angeordnet.

...da du hier mit einer absolutistischen behauptung streitest, die gar nicht meine war, überspringe ich mal bisschen was...

Genau das bestätigst du auch mit deiner Entscheidung von 16GB abzusehen und auf 8GB zu setzen, weil der Unterschied für dich nicht nenneswert ist. Nenneswert wird er aber genau in dem Moment, wo mehr RAM benötigt wird; völlig egal aus welcher Quelle diese Daten angefordert werden.

richtig, und wo dieser moment liegt, kann man anhand von real life benchmark tests gut nachvollziehen, also sieht man sich diese an, sieht dass sich der flaschenhals erst ab einem punkt einstellt der für die eigenen anwendungen (und arbeitsmethode) nicht von belang ist, und gut is.
es kann zudem einen riesen unterschied machen, mit welcher methode du arbeitest. wenn man z.b. wie ich eher mit multicam clips arbeitet nimmt einem zumindest resolve da sehr viel verwaltung (deaktivierung gerade nicht benötigter streams etc) aus der hand. bis zu 16 kamerafeeds laufen da höchst problemlos, livepreview immerhin noch bei halbem proxy sehr flüssig - für das bisschen geld absolut beachtlich. länge der projekts nahezu egal, und da ich jenseits von diversen farbkorrekturen (die sich ebenfalls in multicamclips selber ressourcenmanagen) und sehr grundlegenden edits jetzt keine speicherintensiven fusion-orgien benutze bzw solche dann auch als compound clip stressfrei auslagern kann, ist da sehr viel mehr luft im grünen bereich als man erstmal vermuten würde.

Bei Windows wie bei Mac müssen, wenn die RAM Kapazität erreicht ist, Daten ausgelagert werden. Da sind beide OS gleich langsam, denn keine SSD, die immer mit einem BUS angebunden ist, kann schneller sein als der Zugriff aus dem RAM. Insofern ist dein Argument mit den Latenzen technisch betrachtet bei Windows genauso gegeben wie beim Mac.

(Loriot)
Ach was!
(/Loriot)

In einigen Generationen wird es genügen, sich grunzend zu verständigen.

(dito Loriot) ;)
 

Ähnliche Themen

moonbooter
    • Danke
  • Artikel
Antworten
2
Aufrufe
2K
Ennui
Ennui
moonbooter
  • Artikel
Antworten
5
Aufrufe
64K
moonbooter
moonbooter
M
  • Artikel
Testberichte Resolume 3 Avenue
Antworten
0
Aufrufe
36K
M

Neue Antworten


Oft gelesene Themen

Zurück
Oben