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!

Aktivitätsanzeige oder Terminal top. Wobei jetzt sind es nur 8.

Ach so, ja, das ist terminologisch verwirrend; um diese Threads geht es hier gar nicht, sondern um Threads im Sinne parallel auszuführender Aufgaben (Tasks), die das Program an Apples Grand Central Dispatch weitergibt, das daraus die optimierte parallele Ausführung unter Verwendung jener Threads zaubert, die dann in top oder der Aktivitätsanzeige zu sehen sind. Wie Grand Central Dispatch das im einzelnen macht, ist für den Programmierer eine Black Box. Terminologisch sauberer wäre es von mir gewesen, in Bezug auf die Zahl der Affen nicht von Threads, sondern von Tasks zu sprechen, aber im Programmieralltag wird das oft synonym benutzt.

Trotzdem ist Deine Beobachtung interessant: Wenn ich die Affen handeln lasse, nutzt das Programm bei mir zwischen 18 und 20 Threads. Vielleicht lässt sich daraus der Performanceunterschied erklären? Wobei das, wenn geringere Performance tatsächlich immer zusammen mit geringerer Thread-Anzahl auftreten würde, die Frage natürlich nur dahin verschiebt, warum auf manchen Macs viel weniger Threads genutzt werden.

Na dein MP hat 12 logische Cores, mein MBA nur 4. Das dürfte die unterschiedliche Anzahl an Threads doch hinreichend erklären.

Warum allerdings Dropbox 138 Threads fürs Nichtstun braucht .. ?

Ah, OK.
Vermutlich nicht in Cocoa geschrieben, sondern in Qt, Java oder irgendeinem anderen Cross-Platform-Müll. In solchen Fällen explodiert die Thread-Anzahl oft, warum auch immer. Halt effizient programmiert …

Zum Code oder Ablauf des Programms selbst kann ich ja nichts sagen, da ich hier weder Einblicke noch Ahnung habe. Als Prämisse habe ich die Aussage von dir im Kopf, dass es beim Affen-Programm «um pure Rechenleistung ohne „Tricks“» geht und dass es mit vielen Threads eigentlich gut skalieren sollte. Und eben dass kann ich hier nicht sehen. Rein von der «puren Rechenleistung», etwa im Cinebench müsste dein MacPro, der von IceHouse sowieso, der iMacPro 8-core und der M1 meine alte Möhre total zersägen. Und beim Cinebench passiert das auch tatsächlich. Ebenso spiegelt der Geekbench (in anderer Gewichtung) den Leistungsunterschied korrekt wieder. Die Ergebnisse des Affen-Programms sind aber fast genau umgekehrt. Der 8-core im iMac Pro müsste der schnellste sein, ist es aber nicht. Der 12-Kerner sollte irgendwo auf Platz 2 oder 3 neben dem M1 landen, dann entweder mein 4-kerner oder dein 6-Kerner. Diese Reihenfolge ist aber deutlich verdreht.
Ebenso sollten die Effekte bei abgeschaltetem Multithreading oder deaktivierter 2. CPU nicht so sein. Wie gesagt aus meiner externen Sicht, mit deinem o.g. Statement im Hinterkopf. Ich kann mich da auch irren.

Den Test von IceHouse mit 100 Affen und 99 Jahren hab’ ich auch mal laufen lassen. Bei mir dauert es 12:23 min. Von den 32 GB Speicher sind dabei (mit ein paar anderen laufenden Tools wie Firefox, Mail, Numbers, iTunes, Dropbox, Aktivitätsanzeige…) erst 17 GB belegt und 0 Swap. An den 56 GB sollte es daher (eigentlich) nicht liegen.

Ich wusste gar nicht, dass ein Mac Pro 2019 (3,3 GHz 12-Core Intel Xeon W, 96 GB 2933 MHz DDR4, Catalina 10.15.7 (19H114)) so langsam sein kann: 39 min 15 s (obwohl der Prozessor permanent mit ca. 3,8 GHz läuft)

Sein 2013er Kollege braucht dafür nur 10 min 36 s (2,8 GHz 10-CoreE5-2680 v2, 32 GB RAM, Mojave 10.14.6)

Würde ggf. eine Neukompilierung für Intel mit aktuellem Xcode etwas ändern?

Off topic
Ich danke allen, die hier diskutiert haben besonders Weia. (Na weil er das in Gang setzte! ) Das spannendste und fairste, was ich seit langem hier las!

Ich fühle mich an meine ersten Computer-Annäherungen erinnert, als mein Ältester sich für sein Studium einen PC kaufte; und ich mir kurz darauf auch einen, weil ich ahnte, daß sich da etwas anbahnte, was ich keineswegs verpassen sollte. Monatelang telefonierten wir in der Nacht (ich arbeitete berufsbedingt meist bis 21 oder 22 Uhr) und ich erhielt Unterricht in DOS 3.1. Etwa zwei Jahre später schraubte ich ihm eine heiße Kiste zusammen, in derr die Festplatten per SCSI angebunden waren, was bei den DOSen nicht so üblich war. 2007 wechselte ich zum Mac, weil ich die Windows-Frickelei satt hatte. - Jetzt muß ich mir die Sottisen meines Sohnes über die Obstrechner gefallen lassen - oder auch nicht!
NB: Kann ich das Affen-Programm auf dem MacBoook Air M1 ans laufen bekommen? Irgendetwas fehlt Apple.

Eigentlich sollte es auf dem M1 laufen. Hier gab’ es ja schon ein Ergebnis dazu. Beim ersten Start sollte sich macOS melden, dass evtl. Rosetta (das Programm zum Umwandeln der Intel-Programme) installiert werden muss. Der erste Start dauert dann ein gutes Stück länger.
Diese Abfrage (nach Rosetta) sollte man aber einfach mit «Installieren» bestätigen können, dann läuft das Ding.

Der Test ist schon speziell. Mein Macbook Pro 2013, 2-core i5, 2.4 GHz, 8 GB, Big Sur schafft es in immerhin 25:10 Minuten, obwohl noch ein paar Dinge nebenher liefen.
Das Simulationsergebnis unterscheidet sich auch deutlich von der letzten Darstellung - trotz gleicher Parameter selbstverständlich.

Kleiner Nachtrag: mit 12 Kernen (6 Core + HT) dauert der Test 35 min 26 s. Also mit 12 statt 24 Kernen geht es etwas schneller... Der Prozessor läuft hier im Durchschnitt mit ca. 4,1 GHz laut Intel Power Gadget.

Ja, du hast mit all deinen Beobachtungen ja recht. Die Frage ist nur, was hat das zu bedeuten?

Zwischen den Zeilen höre ich bei dir, dass du argwöhnst, dass irgendwo in dem Programm der Wurm drin ist. Aber das kann eigentlich aus zwei Gründen nicht sein: Zum einen ist es sicherlich problemlos möglich, durch schlechte Programmierung ein Programm unnötig langsam zu machen. Aber ein Programm so zu schreiben, dass manche Rechner sehr langsam werden, andere hingegen, bei denen man das nicht unbedingt erwartet hätte, eher auftrumpfen – das ist ein Kunststück, das ich mir nicht zutrauen würde. Zum anderen habe etwas vereinfacht gesagt ich die kritischen Programmteile ja gar nicht geschrieben, sondern Apple. Du musst dir das grob skizziert so vorstellen, dass ich einfach nur beschreibe, was ein einzelner Affe macht und diese Beschreibung dann mittels eines bestimmten Befehls an macOS übergebe mit der Aufforderung: und jetzt verteile das mal für viele Affen optimal auf die einzelnen Prozessorkerne. Diese Aufgabe umzusetzen, das tue nicht ich, das tut Apple beziehungsweise macOS.

Was da passiert, verstehe ich genauso irgendwie wie du. Auffällig ist natürlich schon, dass das Programm optimal auf genau dem Rechner zu laufen scheint, auf dem es kompiliert wurde. Aber eigentlich sollte das keinen Einfluss haben.
Das war ja auch nur eine ironische Bemerkung kombiniert mit dem zaghaften Versuch, so zu tun, als habe diese spannende Diskussion noch irgendetwas mit dem ursprünglichen Thema gemein.

Sagenhaft! Je älter, desto schnell … 🥴
Das habe ich mich auch schon gefragt, aber eigentlich ergibt das keinen Sinn. Denn de facto ist es ja genau umgekehrt mit Befehlen an das Betriebssystem: Das Programm ruft immer denselben Befehl auf (verteile diese Aufgabe effizient auf die einzelnen Kerne), aber je nachdem, auf welcher macOS-Version das Programm dann läuft, werden mit diesem selben Befehl intern dann möglicherweise im Detail vollkommen andere Prozesse ausgelöst, die jeweils optimal auf die jeweilige macOS-Version abgestimmt sind; es ist also gerade nicht nötig, für eine bestimmte macOS-Version das Programm jeweils neu zu kompilieren. Aber wie schon geschrieben, ich finde es sehr wohl auffällig, dass das Programm auf dem Rechner, auf dem es kompiliert wurde, besonders schnell läuft.

Wie auch immer, mikeboss hat währenddessen den Sourcecode von mir erhalten und wird den wohl für den M1 zu kompilieren versuchen. Wenn das klappt, sind wir vielleicht etwas schlauer.

Das zumindest ist völlig normal. Das unterscheidet eine echte Simulation ja gerade von einer algorithmischen Berechnung des statistischen Durchschnitts: Letztere wird bei gleichen Parametern stets zum selben (statitischen Durchschnitts-)Ergebnis führen, während Erstere eben wirklich das Resultat eines tatsächlich ablaufenden, komplexen Prozesses mit vielen kleinen Zufällen sind. Deswegen werden zwei Simulationsabläufe so gut wie nie zum selben Ergebnis führen – wie im wirklichen Leben halt auch.

Auch ein 2013 MBP, 2-core i5, 2.6 GHz und 16 GB, es lief nichts nebenbei: 13:59 min. Aber mit einem vernünftigen OS - Mojave

Eine Neukompilierung für Intel wäre vielleicht wirklich interessant.

Für Mojave habe ich es hier neu kompiliert – ohne die geringste Änderung im Ergebnis zu zuvor, jedenfalls auf meinem Mac Pro.

Wenn Du magst, kann ich Dir diese auf Mojave kompilierte Version zum Download anbieten. Da Du selbst Mojave nutzt, müsste diese Version ja optimal angepasst sein; wenn sich dann keine Besserung ergibt, können wir die Xcode-Version, mit der kompiliert wird, als Problemursache ausschließen (meiner Auffassung nach können wir das schon jetzt, aber egal).

Abgesehen davon ist doch Dein Wert ziemlich plausibel relativ zu meinem: Ein 2012er 6-Kern mit 3,33 GHz ergibt 10 Minuten, ein 2013er 2-Kern mit 2,6 GHz ergibt 14 Minuten – das klingt doch stimmig, wenn, dann eher überraschend gut für Dein MBP.

auf Macmini9,1 (aarch64 nativ):

zweiter durchlauf auf Macmini9,1 (aarch64 nativ):

Vielen Dank – spannend! Von der Größenordnung her ist der M1 hier also gleichauf mit meinem Mac Pro 5,1 von 2012 und in etwa doppelt so schnell wie die Intel-Version von Affen via Rosetta auf einem M1, wie Tom Macintosh sie getestet hat.

Wirklich überraschen tut mich das nicht – der Mac Pro hat eben mehr und höher getaktete Kerne als der M1. Das meiste andere, was den M1 so überragend erscheinen lässt, sind eben vermutlich einfach Optimierungen für ganz spezifische, wenn auch typische und entsprechend häufige Standardaufgaben. Da die Simulation von Affen in keiner Weise eine Standardaufgabe ist, greifen diese Optimierungen hier alle nicht, und das ist das Ergebnis davon. Am Ende ist eben doch alles einfach Physik. Dieser Verdacht von mir war der Hintergrund dafür, warum ich dieses Programm für einen Test vorgeschlagen habe.

Was auch mich wirklich überrascht hat und was ich nicht verstehe, ist, warum die Macs zwischen dem Mac Pro 5,1 und dem M1 relativ gesehen derart abstinken. Wenn ich das recht überblicke, liefen die Macs mit den schlechten Testergebnissen aber alle auf Catalina oder Big Sur, oder übersehe ich gerade was? Falls das so ist, könnte das eher auf ein macOS-Software-Problem hindeuten, das während der macOS-Versionen auftauchte, in denen Apple intern sich vermutlich schon weitgehend auf die optimale Lauffähigkeit unter Apple Silicon konzentrierte.

anmerkung/nachtrag: die kerne vom M1 waren waehrend des testlaufes mit 480 bis 530% anstelle 800% ausgelastet. da waere also theoretisch noch mehr rauszuholen...

Habe meinen Hauptrechner MP 5.1 aus 2010 auch mal getestet... und bin doch enttäuscht: Obwohl 2 x 3,06 GHz 6-Core Intel Xeon mit 96 GB 1333MHz DDR3 Speicher komme ich unter Mojave auf konstante 14 Min 30 Sek. Das hätte ich nicht erwartet

Ja, es scheint durchgängig, auch unter Mojave, so zu sein, dass Dual-CPU-Macs schlechter performen als ihre Single-CPU-Pendants.

Das ist z.B. etwas, worauf ich als Programmierer keinerlei Einfluss habe; mein Code ist ja nicht auf einer Low-Level-Ebene angesiedelt, wo ich auch nur feststellen könnte, welche Art von Hardware genau meinen Code ausführt.

Mit meinem iMac late 2012, 3,4GHz Quadcore i7, 16 GB RAM habe ich unterschiedliche Betriebssysteme (gestartet von externer USB3.1-SSD) getestet:
High Sierra: Simulationsdauer 10 Minuten 44 Sekunden, CPU <650%
Mojave: Simulationsdauer 9 Minuten 45 Sekunden, CPU <650%
Catalina: Simulationsdauer 44 Minuten 10 Sekunden, CPU <270%
Big Sur: Simulationsdauer 23 Minuten 14 Sekunden, CPU <500%

Big Sur ist die CCC-Kopie des Systems eines MB Air. Mit entsprechender NVRAM-Modifikation kann mein iMac davon starten. Natürlich ist WLAN dann nicht möglich, was mich aber nicht stört, da der Rechner mit Kabel angeschlossen ist.

Vielen Dank, das ist ausgesprochen hilfreich und informativ!

Ich war/bin auch gerade bei einem ähnlichen Test, „hänge“ aber noch bei Catalina …

Jetzt muss ich nicht mehr warten, denn mit Deinem Test hat sich meine Vermutung ja mehr als deutlich bestätigt: Mit Catalina wurde ein massiver Low-Level-Bug in macOS eingeschleppt, den auch Big Sur nur halbherzig behebt (jedenfalls auf Intel).

Das ist ziemlich sicher bei der Vorbereitung der tiefsten Innereien auf Apple Silicon passiert.

Heftig.

Hier noch ein MacBook Air von 2015 mit BigSur 11.2 beta



liefert 25 min 49 s, was gut zum Ergebnis von pünktchen mit 27 min 45 s passt. Die OS-Version von pünktchen war nicht angegeben.



Es bleibt rätselhaft...

Beim "schlechten Ergebnis" meines Mac Pro 2019 waren alle 12 Kerne des Prozessors mit nahezu 100% (= 2400%) ausgelastet, wobei "Affen" davon unter Catalina ca. 2000-2100 % beanspruchte (entspricht also 20-21 Kernen). Die schlechte Auslastung unter Catalina konnte ich nicht beobachten, so dass es beim Mac Pro anderweitig "klemmen" muss...

Ich werde den Mac Pro noch unter BigSur booten und testen...

Nun mit BigSur 11.1:



Das Ergebnis:



Intel Power Gadget (Ausschnitt):



Aktivitätsanzeige:



Die reine CPU-Zeit von "Affen" scheint ca. 6 min der ca. 17 min Testdauer bei max. 29 Threads zu betragen.

Ich war mal neugierig und wollte mal mein privates MBP zum Explodieren bringen

Und war dann schon erstaunt:

Ist mein MBP nun so "affenschnell" wie ein M1? Kann das sein? Oder hab ich die falschen Parameter genommen?

Auf anderen Plattformen hättest Du aber darüber die Kontrolle, weil es entsprechende APIs gibt, das exakt zu steuern. Es zeigt nur wieder, dass Apple das Thema NUMA noch nie in der Lage war korrekt zu behandeln.

Was die Verschlechterung bei neueren macOS Versionen betrifft. Hier muss man den Verdacht haben, dass Apple absichtlich die Werte für ARM Systeme besser aussehen lässt. Das miese Spiel haben sie damals auch beim Umstieg auf Intel gespielt.

Wie bei bmonno2 ergibt sich bei mir ebenfalls eine ungefähre Halbierung der Simulationsdauer mit BigSur im Vergleich zu Catalina.

Dein MBP läuft vor allem unter Mojave. Da schafft mein MBA auch 17 Minuten statt der 28 Minuten unter Big Sur. Allgemein scheint eine CPU + Mojave die ideale Kombination für die Affen zu sein.

Ob das nun ein Bug ist, wer weiss. Vielleicht hängt es zB auch mit Massnahmen gegen die Spectre & Meltdown Sicherheitslücken zusammen. Oder sonst einer bewussten Entscheidung die leider zu gewissen Nebeneffekten führt.


Dazu müsste es ja allgemeiner auftreten und dürfte nicht die M1 Macs betreffen. Die sehen da aber auch nicht so doll aus und ausser diesem Affentest ist mir bisher auch noch keine Bremse in Big Sur aufgefallen.

Ich lade mir gerade mal die letzte Version von BigSur bei Apple runter und werde das mal die Tage installieren und testen. Das interessiert mich ja nun auch mal...

Nöö, die passen, und dein Ergebnis reiht sich ja auch recht stringent in das Bild ein, das sich immer deutlicher herausschält: Mojave und 1 CPU (je schneller, je besser) sind optimal für die Affen und in etwa in der Region eines M1.

Aber schon erstaunlich. Gerade nochmal einen Lauf durchgeführt, der war bei mir wie bei mikeboss etwas schneller (Weia, werden die Affen bei weiteren Läufen schlauer? )

Ich sehe gerade mein Kaufverlangen für M1 kleiner werden:

• MacMini M1: 8:35 min
• Meine Intel-Möhre: 8:54 min

Apple M1 ist nur 3,5% "affenschneller" als Apple Intel.

Wie haben die das damals gemacht? Die Benchmarks kamen ja nicht nur von Apple und haben auch nicht nur einen Aspekt getestet.

Bei mir poppt auf: " Apple kann die Sicherheit dieses Programms nich prüfen" - oder so ähnlich - und dann geht nichts mehr.

Auf meinem Xeon E3 Ubuntu 18.04 LTS Host, macOS 10.12 VM mit einem Core 20′41″, zwei Cores 13′04″, vier Cores 15′52″. Dabei ist die Last auf dem Host mit vier Cores nur zwischen 320-350%, d.h. es gibt es Problem mit dem Scheduler oder den Abhängigkeiten im Code.

Apple hat für die Benchmarks den iMac G5 mit PPC 970FX und den neuen Intel iMac mit CoreDuo verglichen. Das Problem dabei war, dass der iMac G5 nicht aktualisiert wurde und den veraltete PPC 970FX verbaut hatte mit separaten Memory Controller der im iMac nur gedrosselt verbaut wurde. Der PPC970 MP verbrauchte gegenüber dem PPC 970FX gleich viel Strom, hatte dafür aber zwei statt einem Core und benötigte den externen Memory Controller nicht mehr, so dass das System deutlich weniger Strom benötigte und dazu war diese Version noch 15-20% pro Core schneller.

Apple bewarb dann, dass der neue Intel iMac 230% der Leistung vom iMac G5 erreichen würde. Zu gut deutsch er lief mit nativen Code nur so schnell, wie ein iMac mit PPC 970MP gewesen wäre, wenn Apple ihn angeboten hätte, und mit nativen Code natürlich langsamer. Damit war auch erklärt weshalb es das iMac Update nicht gab. Es hätte den Intel iMac vollkommen sinnlos erscheinen lassen.

ich wuerde auf die ergebnisse der Affen.app nicht zuviel geben... der M1 ist im durchschnitt gut und gerne doppelt so schnell wie ein MacBookPro14,3 (und dies bei single- und mulithreaded aufgaben). davon kommt gefuehlt auch wirklich viel beim benutzer an. mein hauptrechner ist ein iMac 5k mit einem i7-7700 drin. der Macmini9,1 ist bis anhin bloss im testbetrieb und ich kann den tag kaum erwarten an welchem ich endlich den neuen iMac mit Apple silicon bestellen kann.

mikeboss
Ich brauch eh ein MBP mit Dual Monitor Unterstützung, daher muss ich wohl sowieso auf ARM Gen2 warten.

Sollte natürlich „emulierten Code“ heißen.

Das ist aber halt nur die eine Seite der Geschichte.Wie Apple damals auf der Keynote angekündigt hatte, war der Hauptgrund nicht die Leistung per se, sonder die Leistung pro Watt. Apple konnte auch Jahre nach dem ersten G5 kein PowerBook anbieten, da der G5 insgesamt viel zu viel Energie gezogen hatte. Zudem war die Zukunft ungewiss, da Motorola und/oder IBM die Consumer-Chips der PPC Familie nicht mehr weiterentwickeln wollten.
Für das eine Modell des iMacs und das erste Modell des MacPro mag es so ausgesehen haben, dass sie «nicht nötig» gewesen seien. Die PPC Reihe ansich war jedoch am Ende und bot keine Zukunft mehr. Es geht und ging Apple nicht um ein Modell oder ein Jahr sondern um ein Jahrzehnt. Was passiert in den nächsten 10 Jahren.

Das selbe steht jetzt beim ARM-Wechsel im Fokus. Die letzten 6-7 Jahre von Intel bzw. x86 waren einfach sehr lahm. Die Entwicklung lief nur noch in klitzekleinen Etäppchen und Innovation suchte man vergebens. Jedes neue Feature und jede neue Revolution passierte nur noch auf den Smartphones & Tablets. Ein iPhone 3G oder 4 konnte h264 Videos abspielen und wurde nicht mal warm, das MacBook aus dem selben Jahr hat sich (dank fehlendem .h264 Dekoder) einen abgelüftet. Ältere Modelle waren hauptsächlich mit Ruckeln beschäftigt.

Die größten Gewinne wurden in den letzten Jahren mit «Spezial-Einheiten» gemacht. h264 & h265 Codierung und Decodierung, Bildbearbeitung und Analyse, Neurale Netzwerke, Verschlüsselung, KI-Lernen, etc. Hier läuft ein Apple-Chip Runden um den Intel, bevor der überhaupt die Schuhe gebunden hat. Dazu die Themen bei Spectre & Meltdown. Wie oft hat Intel probiert, eine brauchbare und konkurrenzfähige Grafik einzubauen? Und wie oft sind sie auf die Nase gefallen? Wie lange brauchte Intel, bis sie moderne Standards (HDMI, USB 3, Thunderbolt) jeweils ohne eine Armada Zusatzchips in die Prozessoren integriert bekamen? Von den Problemen bei der 10 oder 7nm Produktion will ich gar nicht reden.

Intel kann aus sich heraus keine Innovation anführen. Sie agieren nicht, sie reagieren nur. Es ist ein ständiges Henne-Ei Problem. Wenn irgendeine Software etwas fordert (MMX, SSE, Matrixmultiplikation, Inverse Consinustransformation) dann muss erst die Software entwickelt werden, diese dann irgenwie trotz fehlendem Hardware-Support halbwegs erfolgreich werden, bevor eine halbwegs passende Einheit integriert wird und sich die Technik dann ggf (wenn es nicht schon zuspät ist) durchsetzten kann. Dieses Spiel erstreckt sich oft über 2-3 Prozessorgenerationen und mithin 3-4 Jahren.
Wenn die Idee, die Softwareerstellung und die Hardwareschmiede in einer Hand sind, dann lässt sich dieser Zyklus von 3-4 Jahren auf 1-2 Jahre verkürzen. Da ist etwas, was die anderen Hersteller so nicht können.

Auch wenn es jetzt so aussehen mag, dass die M1 nicht sooo viel besser sind als die letzten Intel (die Berichte zeigen aber genau das), solltest du den Wechsel nicht an dem einen Modell, dem ersten oder zweiten Jahr festmachen, sondern in 3 oder 5 Jahren nochmal einen Blick drauf werfen.

oder so ähnlich ist bei Fehleranalysen nie besonders hilfreich.

Meinst Du am Ende die schlichte Tatsache, dass seit vielen Jahren nicht signierte Programme das erste Mal über rechten Mausklick (bzw. Ctrl-Klick) und dann Klick auf Öffnen gestartet werden müssen?

So, mittlerweile bin ich auch damit durch, wobei ich mich jetzt auf High Sierra und Catalina beschränkt habe (Mojave fehlt auf meinem MacBook mit den diversen macOS-Versionen aus Platzgründen leider, da es ja auf meinem Hauptrechner läuft).

Das ist ein MacBook Pro Retina 2012 mit 2,3 GHz Quad-Core Intel Core i7 und 16 GB RAM (also von daher identisch mit Deinem iMac 2012 bis auf dessen höhere Taktfrequenz von 3,4 GHz).

High Sierra: Simulationsdauer 20 Minuten 26 Sekunden, CPU <650%
Catalina: Simulationsdauer 63 Minuten 02 Sekunden, CPU <270%

Die absoluten Zeitdauer ist bei mir höher, was konsistent ist mit der niedrigeren Taktfrequenz bei mir und der Tatsache, dass aufgrund rasenden Lüfters vermutlich noch weiter abgeregelt wurde.

Aber die strukturellen Phänomene (relative Zeitdauer der beiden macOS-Versionen, CPU-Auslastung) decken sich mit Deinen.

Von daher können wir (in Größenordnungen gesprochen) die Situation augenblicklich wohl wie folgt zusammenfassen:

• Mit Catalina wurde (mutmaßlich im Zusammenhang mit der Vorbereitung auf Apple Silicon) ein Low-Level-Bug eingeschleppt, der massiv parallele Anwendungen ohne Sonderbehandlung wie Video oder GPU-Nutzung um den Faktor 4 verlangsamt. Ein Faktor 2 geht auf die halbierte Prozessorauslastung zurück, der andere Faktor 2 auf eine offensichtlich geringere Effizienz pro Thread.
• Mit Big Sur wurde der Bug der mangelhaften Prozessorauslastung behoben, sodass nur noch der Faktor mit der halbierten Effizienz bleibt.
• Single-CPU-Macs sind effizienter als Dual-CPU-Macs. Laut den Ergebnissen von ahs sieht es beim Mac Pro 2019 diesbezüglich ganz besonders schlimm aus.
• Ein M1 ist in etwa gleichauf mit Desktop-Macs aus dem Jahre 2012 mit Mojave oder früher; ohne Effizienz-Bug wäre/ist ein M1 also etwa doppelt so schnell.

No way. Wer in einer bewussten Entscheidung die Rechnerleistung in bestimmten rechenintensiven Situationen viertelt, sollte von Elon Musk umgehend auf den Mars geschossen werden.

Wie Weia schon geschrieben hat, ist das eine Standard-macOS Meldung, wenn das Programm (Affen) ohne Apple-Zertifikat erstellt wurde. Das soll normalerweise vor Programmen aus «unsicheren» Quellen schützen. In diesem Fall ist das wohl aber nicht der Fall.
Am einfachsten umgeht man das, indem du das Programm mit der rechten Maustaste anklickst und «Öffnen» aus dem Kontextmenü wählst. Dann kommt der Dialog nochmals, erlaubt es aber, das Programm trotzdem zu starten.

Generell könnte man das auch abstellen, das würde ich für solche einmaligen Ausnahmen nicht empfehlen.

Das ist tatsächlich eine Vermutung, ich wollte dir aber nicht unterstellen, dass du unsauber gearbeitet hast. Ich leite das lediglich aus diversen Beobachtungen ab. Andere leistungshungrige Programme (Videoschnitt, Bildbearbeitung, Codierung, 3D Rendering, auch andere Benchmarks, Spiele…) verhalten sich seit Jahren recht linear, wenn sie Mulithreading-optimiert sind. Bei keinem der genannten Kategorien ist in den letzten Jahren etwa ein Leistungsabfall durch Catalina oder BigSur aufgefallen. Ebenso ist es nicht aufgefallen, dass Programme proportional zu den Prozessorkernen langsamer werden, wo sie eigentlich schneller werden sollen.

Wenn also eine vielzahl an Programmen nahezu linear mit den Prozessorkernen skaliert und schneller wird, das Affen-Programm aber nicht, dann sieht es für mich eben so aus, als ob hier etwas nicht stimmt. Ob das der Scheduler von macOS ist, eine verwendete Bibliothek, Corona oder die Wetter-Fee, kann ich nicht beurteilen. Mir kamen halt die Ergebnisse komisch vor, weiter nichts.
Bin aber dennoch gespannt, wie sich das weiter entwickelt.

Passt ganz gut zum vorhergehenden Post von Krypton:



Catalina und Big Sur verhalten sich identisch. Der Mac Pro 2019 rendert doppelt so schnell wie der Mac Pro 2013. "Affen" fällt aus dem Rahmen. Hier "gewinnt" der "alte Prozessor" mit deutlich geringerer Rechenleistung.

Kleiner Fehler: Catalina und Big Sur verhalten sich natürlich nur bei Cinebench identisch ...

Danke für die Zusammenfassung.
Als Laie denke ich schlicht, dass Apple da Bugs eingebaut hat. Wohl eher aus Schlamperei, denn mit Absicht. Das ist ja bei Apple schon häufiger vorgekommen.
Übrigens drehte bei meinem iMac late 2012 der Lüfter nicht hoch, die Prozessoren blieben also wohl kühl genug.

Videoschnitt, Bildbearbeitung, 3D Rendering und Spiele sind klassische Kandidaten für Metal bzw. die GPU und GPUs sind natürlich Spezialisten für Parallelisierung.

Und dass Apple darauf achtet, dass Xcode und die üblichen Benchmarks gut aussehen, dürfte sich von selbst verstehen.

Das Interessante an Affen ist einfach, dass es sich um ein massiv paralleles Programm aus einer Ecke handelt, die niemand im Blick hat.

Hätte ich da jetzt auf Assembler-Ebene wilde eigene „Optimierungen“ vorgenommen, wäre Argwohn sicher angebracht. Aber ich verwende ja nun einfach die für diesen Zweck vorgesehenen Standardmethoden von macOS (hauptsächlich dispatch_async() und ein bisschen NSThread und NSEnumerationConcurrent).
Das könnte aber daran liegen, dass von grafiklastigen Programmen abgesehen so gut wie kein Programm von der Stange derart extreme Rechenleistungen über so lange Zeit fordert. Am ehesten interessant wäre ein sehr großes Logic-Projekt, denn Logic verwendet die CPU, nicht die GPU für die rechenintensiven Anwendungen. (Auch da kann Apple in Zukunft natürlich wunderbar die Hardware für die Software optimieren.)
Das Argument funktioniert umgekehrt aber genauso: Wenn Affen bis einschließlich Mojave wunderbar performant läuft, in Catalina aber – selbst unverändert – plötzlich stark einbricht, dann ist das ein Indiz für ein Problem in Catalina, nicht in Affen, denn auf allen vorangegangenen Versionen lief Affen ja prima und die eine Bedingung, die sich geändert hat, ist die macOS-Version.

Kann es sein, dass Catalina und Big Sur auf den T2-Chip für die Verteilung der Prozesse auf die Prozessorkerne setzen und das nicht so gut klappt, wie das Zusammenspiel von Mojave (was womöglich keinen T2 erwartet) mit Intel?
Sorry, wenn das kompletter Blödsinn ist...