Hallo allerseits,

mein Mac Pro 5,1 (2012) stößt mittlerweile immer öfter an die Grenze der verbauten 48 GB RAM und swappt so um die 10 – 12 GB.

Die 48 GB RAM resultieren aus 3 × 16 GB RAM in den 4 vorhandenen Steckplätzen. Ich weiß nur noch dunkel, dass es damals hieß, man dürfe nur 3 der 4 Steckplätze belegen, aber erinnere nicht mehr, warum.

Wie sieht es denn aus heutiger Sicht mit diesem reichlich skurrilen Faktum aus? Sind 4 RAM-Bausteine lediglich irgendwie nicht superduperoptimal oder explodiert dann der Mac Pro? Ich könnte die 16 GB in dem verbliebenen 4. Steckplatz ja offenkundig gut gebrauchen, das sollte den 12 GB Swap dann ja eigentlich verhindern können – und dürfte daher kleinere evtl. Nachteile an anderer Stelle aufwiegen.

32-GB-RAM-Module verträgt der Mac Pro 5,1 (2012) ja wohl grundsätzlich nicht, wenn ich das recht in Erinnerung habe?

Danke im Voraus für alle Tipps von unseren Hardware-Experten hier!

Nur um keine Missverständnisse aufkommen zu lassen. Es geht mir überhaupt nicht darum, Apple Silicon schlecht aussehen zu lassen (wenn, dann viel eher Apples gegenwärtige Softwarequalität … ).

Es geht mir darum, etwas mehr Licht in den Performancesprung zu bringen, der so viel Erstaunen hervorgerufen hat. Und solche Beobachtungen legen eben nahe, dass ein Teil der Qualität des M1 darin besteht, dass Apple ihn für spezifische, Mac-typische Anwendungsfälle über das allgemeine Prozessor-Design hinaus optimiert hat.

Programme wie Affen, die durch dieses Raster fallen, lassen den M1 dann etwas irdischer erscheinen. Aber hey, wenn man den Big-Sur-Bug mal abzieht, dann ist der M1 auch bei Affen doppelt so schnell wie ein Mac Pro 2012, in Volumen, Energieverbrauch Geräuschentwicklng und Kosten aber nur ein Bruchteil davon. Das ist doch bereits ein tolles Ergebnis!

Es könnte natürlich an Catalina oder BigSur liegen bzw. wir sehen hier einen eindeutigen Zusammenhang. Das ist klar.
Was mir nicht klar ist und gegen die Catalina, BigSur, Metal, GPU-Beschleunigungstheorie geht, sind die Ergebnisse von IceHouse. Bei ihm wird ja auf ein- und demselben System das Programm schneller, je weniger CPUs bzw. Multithreading zur Verfügung steht. Und auch die Tests mit 100 Affen und 99 Jahren deuten jetzt nicht auf das krasse 10.000 Thread Problem hin, das als Vermutung im Raum stand.
Meiner Vorstellung nach (die mangels Detailwissen natürlich illusorisch sein kann), sollte das Programm auf dem selben Rechner, mit dem selben OS umso schneller werden, je mehr CPUs/CPU-Kerne oder eben Multithreading zur Verfügung steht. Aber selbst in diesem Testszenario verhält es sich nicht wie vermutet.

Das macht mich halt stutzig.

Hat zunächst nichts mit "Affen" zu tun.

Cinebench rendert nur auf der CPU. Der Pro Render (GPU-Renderer) wurde mit Cinema 4d Version 23 aus der Software entfernt. Metal wird nur für die Bildschirmanzeige verwendet.

Größere Bilder (8k) rendern schon mal einige Stunden am Stück auf der CPU, wobei alle Kerne permanent voll ausgelastet werden.

Rein "bildlich" sieht die Prozessorauslastung bei "Affen" und Cinebench sozusagen identisch aus. Auch die Prozessorfrequenzen und die Leistungsaufnahme sind vergleichbar.

Es wäre natürlich interessant zu sehen, wie sich Cinebench V23 unter BigSur auf dem 2013er verhält. Wenn die Leistung in "Affen" unter Mojave so gut ist, in BigSur deutlich einbricht, Cinebench unter BigSur aber nicht einbricht, haben wir dann ein Erklärungsproblem? Oder andersherum: ist die Parallelität der Prozesse beim Rendern eine andere als in "Affen"?

Es kann natürlich jemand Cinebench V23 und "Affen" unter Mojave und unter BigSur auf der gleichen Hardware laufen lassen. Ich kann es leider nicht, da der Mac Pro 2019 nur ab Catalina läuft und ich BigSur nicht auf dem 2013er installieren möchte (Fehler beim Firmwareupdate auf Catalina, hat mich ein neues MoBo gekostet...).

Das könnte sein. Ich bin alles andere als ein Renderexperte und kann da völlig danebenliegen, aber meinem Verständnis nach ist es beim Rendern so, dass einzelne Bildteile weitgehend unabhängig voneinander berechnet werden können. Klar gibt es Interdependenzen, wenn sich z.B. ein Objekt im andern spiegelt, aber um ein Objekt links unten zu rendern, muss, so stelle ich mir das vor, der Prozess nichts über das Objekt rechts oben wissen, das zeitgleich gerendert wird.

Bei den Affen ist das anders, denn sie handeln ja alle dieselben Aktien. Wenn also ein Affe gerade eine bestimmte Aktie kauft oder verkauft, ist die Aktie in diesem einen Moment für den Zugriff aller anderen Affen gesperrt, denn sonst gäbe es ja Kurschaos. Erst wenn der Kurs aufgrund der Transaktion des einen Affen neu berechnet wurde, können andere Affen überlegen, ob sie zu diesem neuen Kurs nun kaufen oder verkaufen wollen. Es findet also potentiell ein unentwegter Austausch aller Affen vermittelt über die Aktienkurse statt. Meine Vermutung wäre, dass diese Interdependenzen weit stärker ausgeprägt sind als beim Rendern.

Ein ganz anderer Punkt ist freilich, dass ich mir nicht vorstellen kann, dass die großen Hersteller von Renderprogrammen auf Grand Central Dispatch zurückgreifen; die werden ihren eigenen Low-Level-Code haben, der sie unabhängiger von Bugs in macOS macht.

Nun, alles was ich soweit noch dazu sagen kann ist:

Ich habe 4 Programme die die CPU auslasten und dabei Bench-Werte erstellen mit ihren Ergebnissen gegenüber gestellt:

10.14.6


10.15.7


(LuxMark 3.1 - GeekBench 5.3.0 - Cl!ng 1.3 - CineBench 23)

Zumindest diese 4 Applikationen verhalten sich unter den beiden strittigen Systemen, hinsichtlich des Affen Programms, "normal".

BigSur habe ich mir erst mal nicht angetan - der Aufwand war mir zu groß (echtes Partitionieren für den PreBoot und den Recovery damit ich das auf der selben Platte installieren kann).

Das klärt am Ende nicht wirklich was genau da bei den Berechnungen des Affen Programms passiert, aber vllt. kann ja noch jemand unter 10.15.7 mit Xcode die App neu kompilieren und weitere Tests machen.

Mit meinem iMac late 2012, 3,4GHz Quadcore i7, 16 GB RAM habe ich die Tage mit Geekbench 5.2.2 (gestartet von externer USB3.1-SSD) folgende Ergebnisse erhalten:
Mojave: Single Core: 845, Multi Core: 3157
Catalina: Single Core: 692, Multi Core: 2761
Big Sur: Single Core: 712, Multi Core: 2945

"Honi soit qui mal y pense"

Nachdem ich einige Wochen Catalina im Einsatz hatte, bin ich vor 2 Wochen zu Mojave zurückgekehrt und bleibe dabei.

Die Tatsache, dass ein Programm die CPU auslastet, heißt nicht, dass das Programm massiv parallel arbeitet. Wenn Du 24 Kerne hast, reichen prinzipiell 24 parallele Tasks für 100% CPU-Auslastung. Aber Affen verwendet in unserem Test 10.000 parallele Tasks. Das ist eine völlig andere Dimension.
Das habe ich getan (Catalina 10.15.7 mit Xcode 12.3) und es verändert absolut nichts (ich wüsste auch nicht, wieso es das sollte). Die Performance von dem neu kompilierten Affen unter Catalina ist exakt dieselbe wie mit der alten Version, die CPU-Auslastung wiederum nur < 270%; auf weitere Tests habe ich daher verzichtet.

Mir ging es lediglich darum, festzustellen, das absolut identische Programme (incl. Versionsnummer) unter 10.14.6 und 10.15.7 sich absolut plausibel und nachvollziebar verhalten und es keine Abweichungen im Multi-Threading gibt. Meine Core-Auslastung lag grundsätzlich immer bei 2400% - ausser bei den Single-Core Tests von GeekBench. Affen hat bei mir meist ca. 2120% an Leistung "gezogen". Erst als ich 4 Affenprogramme gleichzeitig laufen lassen habe ging der Wert gegen ca. 2384%.


Ursprünglich ging es bei Affen einmal darum:
Das würde dann aber vorraussetzen, dass für das vergleichen von Leistungswerten, beide Systeme unter BigSur laufen müssen um "vergleichbare" Ergebnisse zu erzeugen was die reine Multi-Threading CPU Belastung angeht. Denn wie ja bereits schon gezeigt, gibt es gravierende Unterschiede in den Messergebnissen zwischen 10.14 und 10.15 was das Affenprogramm angeht.

Zu meinem Ergebnis von ca. 46 Min. unter 10.15 habe ich vorhin einmal einen weiteren Test durchlaufen lassen. Zwei Affenprogramme mit den selben Parametern (99 Jahre) zeitgleich durchlaufen lassen - Ergebnis:

Affen-1: 1 Std. 3 Min. 3 Sek.
Affen-1: 1 Std. 2 Min. 42 Sek.


Wie sie sehen, sehen sie eine gute skalierbarkeit der Threads über die vorhandenen 24 Threads der 12 Cores. Jedes Affenprogramm hat dafür lediglich zeitgleich 30 Threads geöffnet.


Apropos Threads:

Das sind die vom macos 10.15 vorgegebenen max. Limits. Ich denke da passen noch weitere bequem rein um abgearbeitet zu werden.

Stimmt, aber zumindest einen Vergleichswert haben wir ja jetzt (gerundet auf Minuten):

Big Sur Intel (sorry, falls ich jemanden übersehen habe):
28 (pünktchen, MacBook Air 2015)
25 (marm, MacBook Pro 2013)
23 (bmonno2, iMac 2012)
17 (ahs, Mac Pro 2019)

Big Sur M1 Rosetta:
18 (Tom Macintosh, MacBook Air M1)

Big Sur M1 nativ:
9 (mikeboss, Mac mini M1)

M1 Rosetta ist demnach so schnell wie ein Mac Pro 2019, M1 nativ doppelt so schnell.

Dabei sind die M1-Rechner ein Mac mini oder ein MacBook Air, also Einstiegsmodelle, die nur wenig mehr kosten als die Bodenrollen für den Mac Pro. Das ist doch was.

Dass Mojave Intel Mac Pro 2012 so schnell ist wie Big Sur M1 nativ 2020 ist eine andere Geschichte, dafür darf Apples Software-Abteilung gehauen werden.

Wenn auch arg verspätet - herzlichen Dank! Das Programm läuft auf dem "externen" MBA M1.