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!

Jaja, das sagt man mir bezüglich meines Körpers ja auch immer. Aber mein Standpunkt ist in beiden Fällen derselbe: Das hat einfach zu funktionieren, basta. Darauf irgendwelche Pflege-Energie zu verschwenden, habe ich keine Zeit. Bislang bin ich damit bestens gefahren.
Meine Mac Pros kriegt niemand von denen in die Hände. Abgesehen davon, dass ich die zeitlich gar nicht entbehren könnte.

Ich habe einen Bekannten, da ist der Rechner abgeraucht, weil der Lüfter der einzige war, der staubgesaugt hat. Aufm Fußboden stehend, hatte er ausreichend Material.

So alle fünf bis zehn Jahre je nach Lüfternutzung mal im Gerät entstauben ist thermisch nicht sooo verkehrt. Da gilt es denn abzuwägen: ist der Staub oder der gerätöffnende Benutzer das größere Risiko.

Danke für den Link.
Ein 1/4 mehr RAM Performance mit Triple Channel ist interessant.

In meinem habe ich, bis auf die Timemachine HD, ausschließlich Samsung NVMe PCIe SSDs eingebaut und bin damit zufrieden.

Wenn ich noch mehr Durchsatz bräuchte um das Auslagern zu beschleunigen, würde ich so was installieren.

Den Staub sollte man eigentlich mindestens einmal im Jahr entfernen. Nach 10-15 Jahren sollte man das Geräte komplett zerlegen und wieder zusammensetzen. Eigentlich muss man dann auch Elkos und Batterien schon längst ersetzt haben.

Wobei der CPU-Tausch beim 5.1er im Gegensatz zum 3.1 ziemlich einfach ist - man kommt überall gut ran, ohne sich die Finger zu verbiegen ... und erst recht im Gegensatz zum 4.1, wo die CPU "geköpft" werden muss.

Hab' ich damals™ so gemacht: Einen "kleinen" gut erhaltenen 5.1 besorgt, einen gebrauchten X5690, neue 3 x 16GB ECC. Die CPU habe ich statt mit WLP mittels Liquid MetalPad eingesetzt. Dabei muss man nur aufpassen, dass die Folie beim Aufsetzen des Kühlkörpers nicht verrutscht.

Alles easy - läuft bis heute tadellos.

Zum Glück kann man die schon geköpft kaufen. Das Zerschneiden und Entlöten des Deckels hätte ich ungern selber gemacht. Aber schlimmer als das Köpfen ist meiner Meinung nach das penible Festschrauben der Kühlkörper beim Dual-4,1. (Der Single-4,1 hat keine geköpfte CPU.) Zu fest: Mac geht nicht an. Zu locker: Mac geht nicht an. Ich habe locker eine Stunde mit Schrauben verbracht, bis mein 4,1 nach der Herz-OP wieder lief.

Laufen da auch 50 ander Programme gleichzeitig - oder doch nur der Compressor?

Hi Weia,
ich glaube Dein Test hat einen Denkfehler: Wenn der Mac während des Tests mit weniger RAM swappen muss, ist er natürlich langsamer (egal ob triple channel oder nicht). Um den Unterschied zwischen 48 und 56 GB RAM zu messen, müsstest Du Dir die Mühe machen, einen Test auszuführen, der komplett ins jeweilige RAM passt.
Allerdings meine ich mich ohnehin an einen Praxistest (mit real-world Software) von Barefeats erinnern zu können, bei dem der Unterschied zwischen triple channel und maximaler Anzahl an Riegeln so gering ausfiel, daß er zwar messbar war aber nicht wirklich fühlbar.

Ja, Staub ist eigentlich der Anti-Gottesbeweis schlechthin. Aber das vordere Lüftungsgitter von außen regelmäßig abzusaugen und grob die Innereien durchzusaugen, wenn ich in den Mac Pro ohnehin gerade einmal etwas einbaue, reicht mir als Agnostiker.
Über das Stadium sollte man mit 15 eigentlich hinaus sein.
Batterie? Logo, das ist ja nun ein Verschleißteil.

Elkos? Die stecken ja nun nicht in einem Elkofach. Das Labornetzgerät, das ich heute noch nutze, habe ich mir 1972 zusammengelötet. Probleme mit den Elkos habe ich keine.

Nein, nur Mail, Safari, Fotos, iTunes und noch ein paar andere Programme

Es ging mir ja aber eben gerade nicht um ein isoliertes Messergebnis, sondern um die Praxisfrage, ob ich unter dem Strich von dem 8-GB-Riegel profitiere, und das tue ich, wie ich mittlerweile nach ein paar Tagen Arbeit mit 56 GB bestätigen kann. Es war also in der Praxis eine richtige Entscheidung, ihn einzubauen.

Das isolierte Messergebnis reiche ich wie gesagt nach, wenn der zweite Riegel für meinen zweiten Mac Pro hier eingetroffen ist.
Eben, und wenn damit dann noch deutlich geringeres Swappen einhergeht, war der Einbau unter dem Strich fraglos die richtige Entscheidung.

So, das habe ich jetzt getan mit dem von mikeboss empfohlenen AmorphousMemoryMark.

Der hier getestete Mac Pro ist frisch installiert und außer dem, was in macOS zu jeder Zeit stattfindet, waren keine weiteren Prozesse aktiv.

Getestet wurde das Lesen und Schreiben von 512 MiB in sequentielle und randomisierte Speicherzellen in 1 Thread und in 8 Threads, gemittelt über 5 Testdurchläufe.

Hier die Ergebnisse:

48 GB in 3 RAM-Modulen:


56 GB in 4 RAM-Modulen:


Wie man sieht, bleibt bei 8 Threads der Durchsatz gleich bzw. verbessert sich sogar minimal bei 56 GB, bei 1 Thread ist es nicht viel anders, nur sind hier die 48 GB ganz leicht im Vorteil. Das sind aber alles keine Abweichungen, die man in der realen Nutzung „spüren“ würde.

Wir haben jetzt also 3 unterschiedlich gewonnene Datensätze:

• die hier gezeigte Messung
• die “real world”-Messung der Kompressionszeit von Compressor
• meine subjektive Erfahrung mit dem aufgerüsteten Mac Pro

Alle drei sagen im Prinzip dasselbe: der Speicherdurchsatz ändert sich nicht wesentlich, nur bei der subjektiven Erfahrung kommt hinzu, dass aufgrund des deutlich reduzierten Swappings die Arbeit am Mac gefühlt wesentlich beschleunigt wird.

Ich bleibe dabei: Die 22€ für die zusätzlichen 8 GB RAM waren gemessen an Performancegewinn/Preis die beste Tuning-Maßnahme, die ich meinen Mac Pros je angedeihen ließ.

Interessante Werte... besonders deine 1 Thread Werte.

hier mal der M1 aus dem MacbookAir ... Temporal kann ich aber nicht einstellen.

In der Tat. Mit wie viel GHz laufen denn deine CPUs (mein 6-Core läuft ja mit 3,33 GHz)? Am Ende ist das wieder der bekannte Effekt, dass bei nur 1 Thread die CPU-Frequenz viel wichtiger ist als die (in diesem Fall ja praktisch irrelevante) Anzahl von Kernen.

Spannend! Sequential vs. Random macht hier einen viel größeren Unterschied. Vielleicht, weil durch die direkte Anbindung diese Anbindung überhaupt kein Bremsfaktor mehr ist und stattdessen andere Faktoren wie eben dieser ausbremsen.

Diese kleine Progrämmchen erfüllt seinen Zweck der leichten Vergleichbarkeit ja wirklich prima.
Was meinst Du mit Temporal?

Hi Weia,

im rechten Feld steht bei mir memmove und bei euch temporal load.

Ach so, ja. Hm, bei mir war das voreingestellt und ich habe mir keinen Kopf darüber gemacht. Im Sinne der allgemeinen Vergleichbarkeit ist es ja auch am besten, einfach die voreingestellten Werte zu nehmen.

Wenn das beim M1 dann nicht geht, ist das natürlich blöd. Seltsam, dass es nicht geht …

Ich mag jetzt nicht am Testrechner RAM nochmals aus- und wieder einbauen; generell sind bei mir die Werte bei memmove etwas schlechter, aber kein großer Unterschied bis auf die Leseleistung sequentiell 1 Thread – die bricht auf die entsprechende Schreibleistung ein.

und wie gesagt: unbuffered DIMMs waeren noch etwas schneller (genaue werte kann ich mangels eines entsprechenden systemes leider keine mehr liefern). es duerfen auch ruhig welche sein die hoehere taktfrequenzen erlauben wuerden (da bei diesen dann idR die RAS/CAS latenzen tiefer ausfallen). die 1866 MHz module aus den MacPro6,1 waeren da zb passende kandidaten. 4 und 8GB module von Apple waren immer unbuffered. die 16GB hingegen waren dann auch ab werk registered/buffered. eure DIMMs (Weia & IceHouse) sind buffered. wenn mehr als 9 bzw 18 chips auf dem modul verbaut sind, ist es ein registered.

Bei mir registered, ja.

Hi Weia,
ist doch ok, es sollte ja nur ein vergleich alt/neu sein. Wenn man das Paket von Apple sieht haben sie wohl viel richtig gemacht.
Und hier im Thread ging es ja im eigentlichen um deine Speichererweiterung. Danke für die Infos.

MacPro5,1 (Mid 2012) | X5690 Dual mit 3,46 GHz

k.A. warum die Single Threads da so einbrechen.

Oooops!

Vielleicht hätte ich noch einen anderen interessanten Test für Intel vs. M1 anzubieten, falls das hier interessiert.

Ich habe vor 4 Jahren mal im Zusammenhang mit einer Diskussion im MacTechNews-Apple-Aktien-Thread eine kleine App geschrieben, die MacTechNews dankenswerterweise hostet: . Die App simuliert das Verhalten von Affen (stellvertretend für vollkommen zufällig agierende Marktteilnehmer), die am Aktienmarkt handeln.

Worum es in der Diskussion und App ging, braucht hier nicht zu interessieren, eine kurze Übersicht bietet der Ausgangsbeitrag auf Affen handeln Aktien – eine Computersimulation als kleine Mac-App (die von einem Troll dominierte Diskussion könnt Ihr getrost ignorieren …) und eine ausführlichere Beschreibung die Online-Hilfe der App.

In unserem Zusammenhang ist nur Folgendes interessant: Die App ist eine soziale Simulation, das heißt, sie zeigt den Einfluss verschiedener Faktoren auf das Endergebnis nicht anhand statistischer Algorithmen auf, sondern spielt das Szenario tatsächlich durch. Wenn man also das Verhalten von 10.000 Affen analysiert, dann werden in der App tatsächlich 10.000 virtuelle Affen generiert, die dann gemäß bestimmter Vorgaben agieren. Da jeder Affe ein eigener Thread ist, haben wir es also in diesem Beispiel bereits mit 10.000 Threads zu tun, sprich, einer massiv parallelen App. Gleichzeitig ist die Simulation des Verhaltens von am Aktienmarkt spekulierenden Affen nichts, wofür Apple einen Spezialchip vorgesehen hätte so wie für das Komprimieren von Videodateien. Es geht also um pure Rechenleistung ohne „Tricks“.

Bei einem Mac Pro wird die gesamte Rechenleistung beansprucht, er bleibt aber zumindest „cool“; bei meinem MacBook Pro habe ich mich nie getraut, 10.000 Affen ein (virtuelles) Jahr lang spekulieren zu lassen, denn es „kochte“ schon bei 1.000 Affen.

Falls jemand Lust hat, die App auf einem M1 zu testen, sollten wir uns für die Vergleichbarkeit auf die gleichen Einstellungen einigen:



Praktischerweise für unseren Zweck gibt die App am Ende der Simulation auch die benötigte Rechenzeit aus, so dass man präzise vergleichen kann. Bei meinem Mac Pro 5,1 (mit 56 GB RAM ) sieht es mit obigen Einstellungen wie folgt aus:

Experiment beendet
1 Jahr (Simulationsdauer 10 Minuten 36 Sekunden)

Der Vergleich ist natürlich insofern unfair, als dass Affen auf einem M1 ja unter Rosetta läuft. Ist hier ein Entwickler mit M1 unter uns? Dann könnte ich ihm den Sourcecode zur Rekompilation schicken in der Hoffnung, dass am Code nichts geändert werden muss (das will ich niemandem zumuten und ich selbst kann es mangels Big Sur ja eben noch nicht).

Ist jetzt zwar kein M1, aber ich hab’ die Simulation mal testhalber auf einem 2014er Mac15,1 QuadCore 4,0 GHz i7, 32 GB RAM laufen lassen. Der dreht die Lüfter etwa auf und handelt die Aktien in 7 Minuten und 18 Sekunden.

Meine Vermutung für einen M1 liegt (nativ) bei unter 3 Minuten, via Rosetta unter 5 Minuten. Bin gespannt, was tatsächlich rauskommt

Interessant. Mein olles MBA 2015 mit 1.6 GHz bleibt da ganz cool. Lüfter unhörbar so bei 1200 Umdrehungen, CPU bei 80°C. Solange die GPU nicht gefordert wird dreht auch die Lüftungsturbine nicht auf.

Experiment beendet
1 Jahr (Simulationsdauer 27 Minuten 45 Sekunden)
10’000 Affen, 500 Aktien

Das sollte dein MBP auch überleben.

Mein Ergebnis verwirrt mich. Meine Dual-CPU Hardware ist mehr als 4,6 mal so langsam wie deine Single-CPU? Meine RAM Bank Bestückung kannst du ja weiter oben im Bild sehen.

Das verstehe ich auch überhaupt nicht. Keine Ahnung, woran das liegen könnte. Die macOS-Version? Ich wüsste absolut nicht, warum die so einen Einfluss haben sollte. Krypton, pünktchen – unter welcher Version habt ihr denn getestet?

Mit welcher Methode hast du denn Catalina auf dem Mac Pro 5,1 zum Laufen gebracht? Vielleicht, dass da was schiefgegangen ist? (Bei mir läuft Mojave.)

Big Sur 11.1

Hi zusammen,

ich teste gern für euch... MBA 16/500 - am Monitor und 11.1.
17 Minuten und 31 Sekunden

Danke – das ist interessant! Als Intel-Version unter Rosetta ist das also eine App, wo der M1 dem Mac Pro 5,1 unterlegen ist. Ich hatte sowas geahnt, weshalb ich auf die Idee mit diesem Test kam.

Umso spannender wäre es jetzt zu wissen, wie sich eine native Version verhält. Daher nochmals die Frage, ob hier vielleicht ein Entwickler mit einem M1 mitliest ist oder zumindest jemand, der sich zutraut, ein Xcode-Projekt zu kompilieren.

Die App ist 200% Cocoa und und der Source Code sollte theoretisch also „einfach funktionieren“, ohne dass etwas angepasst werden muss, aber bei Umstellung auf eine neue Plattform wäre das natürlich schon bemerkenswert …

OK, dann sollte macOS wohl nicht der Grund sein, denn es wäre ja schon sehr schräg, wenn 10.14 und 11 reibungslos funktionieren würden, 10.15 aber bremsen.

15 Min auf einem iMacPro mit Xeon, sehe schon da ist gegen die nächsten M-CPU's keine Chance mehr ....

-tpau17

Ich lasse Catalina Nativ ohne Patch über OpenCore 0.6.4 laufen, damit ich einen BootScreen mit meiner RX 570 Nitro+ habe und damit ich die volle HW Beschleunigung der GPU nutzen kann .

Ich habe eben mal 10.14.6 (incl. aller Patches) nativ (ohne OpenCore) gebootet und 2 Testdurchläufe "zelebriert":

Erster Durchlauf mit 24 CPU-Threads - die Werte sind besser aber nicht zufriedenstellend:



So, jetzt wird es "spooky" - mit Xcode Instruments habe ich mal 12 Threads abgeschaltet. Das würde deinem W3680 mit 6 Cores und 12 Threads entsprechen .

Viel Spass beim "entschlüsseln" des Ergebnisses:

Da warten die Threads wohl irgendwann aufeinander - race condition.

Aber warum sollte es race conditions nur bei 2 CPUs geben? (Und die App ist diesbezüglich sehr sorgfältig programmiert.)

Vielleicht ist das Aufteilen auf zwei physisch getrennte und voneinander entfernte Chips ein größerer Bremsfaktor, als man denkt? (So wie wie umgekehrt der M1 nicht zuletzt durch den SoC-Ansatz „rast“)?

Na gut, das heißt wenigstens schon mal, dass unsere Ergebnisse konsistent sind, also Deine Hardware völlig OK ist.

Dass zwei CPUs statt einer so bremsen können, ist aber natürlich ein überraschendes Ergebnis. Und warum Catalina mit beiden CPUs dann nochmals so viel schlechter performt als Mojave mit beiden CPUs, ist auch noch völlig unklar.

Ich verstehe viel zu wenig von Open Core, um beurteilen zu können, ob da der Hase im Pfeffer liegen könnte. (Das ist im übrigen auch ein Grund dafür, dass ich von solchen Modifikationen Abstand nehme: Wenn alles läuft, fein, aber wenn nicht, weiß man nie, ob es am Ende nicht an dem Hack liegt.)

Das Programm scheint bei Dual-CPUs ein Problem mit dem Hardware Multi-Threading zu haben. Wenn ich unter Catalina mit eingeschaltetem HW MT dein Programm bei 12 Threads laufen lasse, stürzt die Performance ins Bodenlose. Schalte ich das HW MT aber aus, werden alle 12 Threads VOLL ausgelastet.

Xcode Instruments Prefs:


Mit Hardware Multi-Threading:


Ohne Hardware Multi-Threading:


Ich bin mir nach wie ziemlich sicher, das es NICHT an OpenCore liegt. Wenn die Performance so stark einbrechen würde durch OpenCore, dann wäre das einigen Usern mit ihren MacPro5,1 bei MacRumors sicherlich schon aufgefallen.

Meine Benchtests mit "CL!ng", "Cinebench 23" und "GeekBench 5" unter 10.14.6 und 10.15.7 waren "unauffällig und fallen in den Bereich "Messtoleranzen".

10.15.7 - 10.14.6 (GeekBench)


Mir fällt soweit nichts mehr konstruktives ein...

Auf meinem iMac (das i hatte ich wohl oben vergessen) läuft 10.14.6 Mojave.

Wenn ich mir die Ergebnisse so anschaue, kann da einiges an der App nicht passen.
Mein 4-core aus 2014 braucht 7 Minuten, der 12-core von IceHouse 40, 14 oder als 6-core nur noch 9 Minuten. Der iMac Pro mit 8-core (auf einem Prozessor) Xeon aus 2017 benötigt 15 Minuten.

Entweder liegt tatsächlich sowas wie eine Race-Condition vor, dass einige Threads auf andere «massiv» warten, oder es passt was nicht mit der Thread-Verteilung. Es gibt/gab einige Programme, bei denen werden Threads wild zwischen Cores oder sogar physischen Prozessoren hin- und her geschoben und die Verschieberei dauert letztendlich länger als die eigentliche Berechnung. Vielleicht ist der Scheduler von macOS mit den sehr vielen aber super kurzen Einzelthreads völlig überfordert. Eventuell zeigteine Änderung des Programmcodes in der Art, dass jeder «Thread» 100 Affen linear nacheinander berechnet und es so nur noch zu 100 systemrelevanten Threads kommt, bereits eine Wirkung.

Hier scheint es doch so, dass das Programm langsamer wird, je mehr Kerne ins Spiel kommen. Selbst der M1 unter Rosetta sollte schneller sein als mein alter iMac. Ist es aber nicht. Er liegt dagegen (erstaunlicherweise) als 8-Kerner auf dem selben 15-17 Minuten-Fenster wie der iMac Pro mit ebenfalls 8 Kernen.

Interessant wäre mal ein Test auf dem MacPro von Icehouse, wenn nur noch 4 oder 2 Kerne laufen.

Naja, die App nutzt einfach die entsprechenden Apple-Technologien, NSThread und Grand Central Dispatch. Ich habe im Augenblick zu wenig Zeit, um mir den Code in der gebotenen Tiefe nochmals anzuschauen, ich erinnere aber, dass ich damals sehr auf sauberen Code geachtet und gründlich getestet habe.
Naja, das meiste passt doch. Ein 6-core von 2012 (IceHouse und ich) braucht 9-10 Minuten, ein 4-core von 2014 mit höherem Takt braucht 7 Minuten. Finde ich plausibel.

Was unklar ist, ist der Unterschied zwischen Catalina (40 Minuten) und Mojave (14 Minuten) und der Unterschied auf Mojave zwischen 2 CPUs (14 Minuten) und 1 CPU (9 Minuten).
Ja, das passt auch nicht so völlig rein. Und dann gibt es ja noch die Frage mit dem Hardware-Multithreading. Da kommen ziemlich viele Faktoren zusammen.
Das könnte man ja ganz einfach ausprobieren, indem man die Zahl der Affen eben auf 100 stellt (und ggf. dafür die Dauer des Experiments auf mehrere Jahre, um eine gewisse Rechenzeit zu erzwingen) und schaut, ob dann die verschiedenen Konfigurationen sich konsistenter verhalten.

Naja, wer nutzt schon Programme mit 10.000 Threads?

Du könntest ja mal probieren, ob das Verhalten Deiner verschiedenen Konfigurationen untereinander stimmiger wird, wenn nur 100 Affen handeln.

Hier mein Ergebnis auf einem iMac 2019 mit i9 CPU (11:45 Minuten):



(Sorry für das „Bildschirmfoto“...)

Ich hätte da eigentlich bessere Werte erwartet...

wo gibt's das xcodeproj? moechte mal schauen was aarch64 nativ so hergibt...

Ich habe mir den Spass unter 10.15.7 mal in 2 Durchläufen gegönnt und bin - richtig verwirrt

10.15.7 - ohne Hardware Multi-Threading mit 4 Threads:
36 Min 29. Sek.


10.15.7 - ohne Hardware Multi-Threading mit 12 Threads:
36 Min 16. Sek.


Das war jetzt, selbst für mich - überraschend...

Bei mir.

Ich schicke Dir einen Download-Link per PM, wird aber heute Nacht oder morgen Früh werden.

den link gerne auch per elektronische post: mb ät n4n0 punkt ch

Entspricht ungefair der ersten Berechnung

Allerdings kann man nur 99 Jahre eingeben statt 100 um ein Äquivalentes Ergebnis anzustreben.

Du kannst auch 100 Jahre eingeben: 99 Jahre + 11 Monate + 20 (Handels-)Tage.

Aber darauf kommt es überhaupt nicht an; erstens geht es ja um Größenordnungen und zweitens ist der Zusammenhang nicht so linear, wie du dir das denkst – Dauer des Experiments und Simulationsdauer stehen in tatsächlich einem linearen Zusammenhang (schließlich sind beide einfach iterativ), aber der Zusammenhang zwischen Anzahl der Affen und Simulationsdauer ist nicht linear, da ja hier die Interaktionen zwischen den Affen dazukommen.

Ich habe das jetzt bei mir mit Deinen neuen Einstellungen durchgespielt und bin von meinen 10 Minuten und 36 Sekunden auf 16 Minuten und 21 Sekunden geklettert; sprich, die Verhundertfachung der Jahre belastet mehr, als die Hundertstelung der Affen entlastet. Das ist auch so zu erwarten.

Dass du bei dir wieder bei zufällig genau 47 Minuten landest, liegt vermutlich daran, dass die geringere Anzahl der Threads deinen Mac Pro tatsächlich ein wenig entlastet, nur eben leider nicht sonderlich viel, sondern gerade so viel, dass damit der bei mir auftretende Mehraufwand kompensiert wird.

Das spektakulär schlechtere Ergebnis deines Mac Pros kann also nicht an der Überlastung durch zu viele Threads liegen (100 Threads muss jeder Mac locker wegstecken können). Was es aber dann ist – keine Ahnung.

Ich kann überhaupt nicht nachvollziehen, warum ausgerechnet mein Mac Pro relativ zu dem, was zu erwarten stünde, so viel besser abschneidet als viele andere Macs hier. (Ob’s an den 56 GB liegt? )

Also bei mir laufen die Affen auf gerade mal 9 Threads und nicht mit den 10.000 versprochenen.

Das siehst Du wie?