@MyKeyz
Ich habe mal den Inhalt des von dir neu erstellten Threads hier mit reingepackt.
14 Core Hackintosh auf El Capitan, Postinstall & Optimization Hilfe
Dafür muss man keinen neuen Vorgang erstellen...
Das verwirrt nur alle... 
-
-
Trotzdem sollte das eigentlich besser laufen, der 12 Kerner der im MacPro steckt ist vielleicht 200-300Mhz schneller wenn ALLE Kerne ausgelastet sind
-
Mal ne ganz doofe Frage, aber welche SMBIOS nutzt du denn?
-
Momentan benutze ich das SMBIOS von dem MacPro6,1 habe aber auch schon andere wie 5,1/iMac 14,2 etc versucht
-
Ich gehe mal eher davon aus das es eher mit dem cpu zu tun hat, wenn man so in anderen Seiten liest 2x6 core 2x8 Core 10 und 12 Core haben alle keine Probleme, nur ab 12 machen die Zicken, im Tomaten Forum haben wenn man so ließt die 16,18 und 20 Core starke Probleme mit Performance, darunter nie.
-
Aber wieso eigentlich? Weil alle Kerne werden erkannt und wie gesagt auch genutzt, je nach Programm. Sollte ich mal Probeweise 2 Kerne im BIOS deaktivieren? Oder ändert das nichts?
Edit: Im Bios auf 12 Kerne schalten bringt auch nichts, habe jetzt aber bemerkt das Handbrake, Final Cut und Premiere unter Mac auch nur die physischen Kerne und nicht die Virtuellen Threads benutzt, jedoch Cinebench schon..
-
Hallo MyKeyz,
die meiste Software ist leider immer noch nicht für viele cores ausgelegt.
Cinema würde auf Deinem System traumhaft skalieren.After Effects zB. läuft auf einem schnellen 4 core jedem mehr kern Mac Pro davon.(Was sehr schade ist) ähnlich ist es bei Premiere.Beste Balance scheinen die 6cores wie zB. der i7 5930K die mit viel SingleCore Speed trumpfen.
Bei Apple Compressor lässt sich eine Plist verändern so das compressor mehr cores benutzt als offiziell in den settings angeboten. Vielleicht gibt es sowas bei Final Cut auch.
Handbreak kannte ich noch nicht - aber vielleicht mal einen Blick auf Media Encoder werfen.Einziger Trick den ich Dir empfehlen kann::
Programme mehrmals zu starten und des Rendering 2 oder 3 mal zu teilen.Am ende wieder zusammen als ein H264 zu exportieren.
Das ist keine komfortable Lösung - holt aber bei grossen Projekten ein Zeitersparnis raus. -
Das Ganze scheint eine hochkomplexe Angelegenheit zu sein.
Ich habe z.B. zwei 6-Kerner, die je max. 80 Watt verbraten. Wenn aber eine einzige CPU auf 150 Watt begrenzt ist und - sagen wir - 14 Kerne hat, dann wird im Mehrkern-Betrieb die Geschwindigkeit entsprechend runter gedreht.
Und soweit ich es begriffen habe, haben die Prozessoren also gewisse Vorgaben, in welchem Betrieb die welche Geschwindigkeit maximal haben. Ich weiß nicht, ob das unter Windows und OSX gleichermaßen abläuft oder ob es da Unterschiede gibt.
Aber zig Kerne machen nur Sinn, wenn es eine Software gibt, die damit was anfangen kann - und wenn ein Programm nicht entsprechend geschrieben ist, bringen viele Cores nichts. Laufen aber alle, ist die Taktrate dann niedriger als mit nur wenigen Kernen. Daher gibt es wohl auch diese Vielfalt an CPUs, um die bedarfsgerecht verwenden zu können. -
Das ist mir schon klar, aber wenn ein 12 Kerner wunderbar funktioniert sprich der MacPro und seine Hackintosh Varianten, dann sollte ein 14 Kerner auch wunderbar funktionieren. Das tut er auch in Cinebench, Geekbench etc das heißt die Rohleistung ist da und KANN genutzt werden.. das geht mir nicht in den Kopf. Selbst wenn dann auch nur 12 Kerne beansprucht werden würde das Sinn machen aber wie gesagt Final Cut, Premiere, Handbrake etc nutzen nur die jeweils 14 Physischen Kerne aber nicht deren Threads. Wenn ich die CPU mit Final Cut etc auslaste wird genau jeder 2 Thread nicht genutzt, sprich 1-0-1-0-1-0-1-0-1-0-1-0-1-0-1-0-1-0-1-0-1-0-1-0-1-0-1-0.. das ist viel zu auffällig das genau die Virtuellen Threads nicht genutzt werden obwohl sie vom OS erkannt und genutzt werden können. Da muss irgendwo zwischen Final Cut etc und dem OS ein Kommunikations Problem sein, indem dann die jeweilig Betroffenen Programme nur von 14 Threads ausgehen..
-
Und das macht so auch Sinn.
Hyperthreading ist ja nichts anderes als die Möglichkeit auf einem CPU Kern einen 2. Thread laufen zu lassen wenn der erste Thread gerade pausiert also zum Beispiel auf eine EA Operation wartet etc. damit das möglichst effizient funktioniert muss die Software dafür optimiert sein was im Falle von FinalCut nur bedingt der Fall ist. Jetzt ist es natürlich ein erheblicher Unterschied ob man ein Benchmark laufen lässt das genau darauf optimiert ist und so die Leistung optimal ausreizt oder ob man Videos rendern möchte. Im Hyperthreading Umfeld kommt die erste Prio immer den physikalischen Kernen zu sind diese ausgelastet wird eben auch kein weiterer Thread geöffnet selbst wenn die CPU es könnte.
Cinebench berechnet ein einziges statisches Bild das Endergebnis ist ein einzelnes Bild sprich hier macht es Sinn die Berechnungsschritte auf alle verfügbaren Cores (auch die virtuellen) zu verteilen es spielt bei dem zu erzielenden Ergebnis keine Rolle in welcher Reihenfolge die Ergebnisse vorliegen sprich die Aufgabe lässt sich prima aufteilen und verteilt rechnen. Geekbench stellt theoretische Berechnungen an auch hier geht es nicht darum am Ende ein Ergebnis zu erhalten das die Leistung aller Kerne in einem definierten Ergebnis vereint sondern vielmehr misst Geekbench wie viele einzelne Berechnungen in einem definierten Zeitfenster mit einem definierten Algorithmus gleichzeitig möglich sind wobei das Ergebnis jeder Berechnung für sich steht. Software zum encodieren oder umcodieren von Videos profitiert davon aber nicht denn in einer linearen Abfolge (Video) lassen sich die Aufgaben nicht oder nur schlecht verteilen. Ein Video setzt sich aus vielen Einzelbildern zusammen die in einer definierten Abfolge aneinander gereiht werden müssen zudem muss obendrein noch der Ton berechnet bzw. umgerechnet werden.
Was also tun? Ich kann entweder die Berechnung eines einzelnen Frames auf alle verfügbaren Kerne verteilen sprich jeder Kern berechnet einen Bruchteil des einzelnen Frames und erst wenn alle Fertig sind ist der Frame berechnet und kann gespeichert werden (HT schließt sich hier aus denn das Ergebnis muss ja vorgehalten werden bis alle fertig sind) oder aber ich lasse jeden verfügbaren Kern je einen Frame aus einer Abfolge berechnen (bei 12 Kernen 12 Frames, bei 14 Kernen 14 Frames) aber auch hier muss die Reihenfolge eingehalten werden sprich auch hier schließt sich HT aus denn es gibt schlicht keine Möglichkeit einen sinnvollen 2 Task zu eröffnen weil vollkommen unklar ist was als nächstes zu Berechnen ist bis nicht das Ergebnis aller gestarteten Berechnungen vorliegt.
Das alles ist jetzt natürlich sehr vereinfacht dargestellt denn in der Praxis spielt beim rendern von Bewegtbildern die GPU auch eine gewisse Rolle. FinalCut setzt bisher auf OpenGL bzw. OpenCL sprich lagert einen nicht unerheblichen Teil der nötigen Berechnungen auf die GPU aus sofern sich diese auf OpenCL versteht sprich dann spielt die CPU sogar eine untergeordnete Rolle weil sich die nötigen Berechnungen viel effizienter auf der GPU erledigen lassen. Premiere geht einen ähnlichen Weg setzt aber eher auf CUDA sprich auch hier werden, kompatible Karte vorausgesetzt und CUDA Treiber installiert nötige Berechnungen nicht auf der CPU durchgeführt sondern auf der für diese Zwecke wesentlich besser geeigneten GPU. Um das Ganze noch verwirrender zu gestalten bedienen sich moderne Videoschnitt Lösungen auch Hardwareseiig vorhandener Encoder bzw. Decoder so besitzen I5 oder I7 CPU´s zum Beispiel eine eingebaute Beschleunigung für den H.264 Codec welcher den XEONS fehlt usw.
-
Nein es macht kein Sinn. Handbrake ist zum Beispiel ein sehr optimiertes Programm was alle Threads nutzen sollte, Compressor sollte auch alle Kerne nutzen tun sie aber nicht (außer ich ändere die Thread anzahl bei Compressor manuell in der .plist). Premiere auf Windows nutzt 60-70% der CPU und alle 28 Threads, mit den selben Einstellungen nutzt Premiere unter Mac nur die hälfte und das sollte nicht sein da es nichts gibt das Premiere daran hindern sollte mehr Kerne anzusprechen weil es Cinebench und Geekbench auch können ungeachtet das es Benchmarks sind. Es würde Sinn ergeben wenn einfach nur 14 Threads vom System erkannt werden und dementsprechend auch nur 14 genutzt werden können. Der 2013 MacPro wird bei Final Cut auch mit mehr als 14 Threads ausgelastet, teilweise mit ALLEN 24 Threads die der MacPro hat. Ein weiterer Hinweis das etwas nicht stimmt ist das ich per Terminal-Loop auch alle Threads auf 100% bekomme. Heißt das die 14 Threads die nicht genutzten werden auch von nicht-Benchmarks angesprochen werden können.
-
Von Apple original gibt es maximal 24 threads / 12 cores.
Premiere auf dem Mac könnte max. dafür ausgelegt sein.Vielleicht orientieren sich manche Software Hersteller an der Geräte ID.
Kann ich mir nicht vorstellen - aber theoretisch könnte es so sein.
Unter Windows müssen sich die Hersteller an den verschiedenen
Kern-Anzahl orientieren - jeder hat ja was anderes. -
Eben, deswegen stell ich mir ja vor das es irgendwo ein kommunikations Fehler gibt. Bei "About this Mac" stand bei Prozessor "2.08 Ghz Unbekannt" und bei System Details steht alles richtig dar sogar der jeweilige level cache stimmt. Vom Grund System wird er also 100% erkannt, nur verpennen Final Cut etc da irgendetwas.. was mir halt nicht in den Kopf geht ist das selbst wenn jetzt auf Mac Premiere und alle anderen Programme auf 12 Kerne Hardgecoded sind, was ich aber bezweifle, sollten sie ja dann wenigstens 12 Kerne 12 Threads benutzen :/.
-
Lass spaßeshalber mal Luxmark laufen hier kannst Du wählen ob die Berechnung auf nur der CPU, nur der GPU oder auf beidem ausgeführt werden sollen und behalte dabei im Auge wie die Cores ausgelastet werden. Insbesondere Interessant ist das verteilte Rechnen auf CPU und GPU wenn da nicht alles Cores ausgelastet werden (und davon gehe ich aus) hast Du das Problem vermutlich schon eingegrenzt. FinalCut nutzt sowohl die GPU als auch die CPU zum Rendern. Selbst mit meinem 4 Kerner kriege ich unter FinalCut die CPU nicht ausgelastet da der größte Teil der Rechenarbeit auf der GPU läuft (Was bei der R9-270 auch gut zu hören ist wenn die Last bekommt)....
-
Alles klar mache ich gleich mal aber das wäre dann schon sehr enttäuschend und da muss man sich dann schon fragen was den der 12 Core Macpro für einen Sinn hat. Werde auch mal Cinema und Blender versuchen um das weiter einzugrenzen.
-
als was gibt sich denn Deine Konfiguration aus? Mac Pro , iMac ?
-
Das SMBIOS is momentan auf MacPro6,1. Habe jetzt LuxMark 3.0 auf Windows laufen lassen und auch auf Mac. Es hat sich wieder gezeigt, die Physischen Kerne waren alle auf 100% und die jeweiligen Threads nur auf knapp 50% Auslastung, bei Windows hingegen wurden alle Kerne und Threads auf 100% ausgelastet. Da stimmt definitiv etwas nicht, diesmal wurden die Threads zwar auch genutzt aber nicht ganz.. auffällig ist auch das die GTX 680 einen Score von 4800 unter Windows hat, unter Mac aber nur 3900?
-
Na das ist gar nicht so Auffällig.
Luxmark ist zumindest unter OS-X ein reinrassiges OpenCL Benchmark und die OS-X Nvidia Treiber sind alles andere als gut optimiert für OpenCL/OpenGL. Es kann hier schon einen erheblichen Unterschied machen ob man die stock Apple Treiber für die NVIDIA nutzt oder die Webtreiber (je nach Grafikkarte sind die Webtreiber in der Disziplin deutlich den Stock Treibern überlegen). Apple setzt bei macOS für die Grafikbeschleunigung auf offene Standards und dazu gehören eben OpenCL und OpenGL und selbst die mit ElCapitan eingeführte MetalAPI setzt im Grunde auf OpenGL auf.
Das eine NVIDIA Karte im selben Benchmark unter Windows vermeidlich besser abschneidet als unter OS-X ist also nicht weiter verwunderlich denn die NVIDIA Karte profitiert unter Windows zum einen von DirectX zum anderen von Ihren Treibern die auf diese Art von Benchmarks optimiert sind. Was die OpenCL und OpenGL Leistung angeht ist Windows also sicher kein wirklich guter Gradmesser zumindest nicht wenn es um die reine GPU Performance geht. Es gibt gute Gründe dafür das Apple bei dedizierten Grafikkarten zumeist auf AMD setzt denn AMD hat zumindest bisher darauf verzichtet die over all Performance zugunsten von Windows und dessen Treiberarchitektur zu verschieben sprich die AMD Karten liefern im reinen OpenGL bzw. OpenCL Bereich OS unabhängig konstant hohe Werte was letztendlich auch Apple in die Karten spielt. NVIDIA hat sich vor einiger Zeit dazu entschieden OpenGL/OpenCL zugunsten von Cuda nur noch in der Basis zu unterstützen was Sinn macht da NVIDIA sich auf den Gamer Markt konzentriert hat und hier die offenen Standards kaum eine Rolle spielen solange Windows die Plattform der Wahl ist. Selbst im Profibereich ist man damit fein raus denn mit CUDA gibt es ja eine alternative Lösung zu OpenGL/OpenCL sprich eine API die es ermöglicht die GPU performant anzubinden. Blöd an der Sache ist halt nur, dass sich zum Beispiel Apple dessen verweigert und lieber weiterhin sein heil in OpenGL/OpenCL bzw, deren Nachfolger (aus Apples Sicht) Metal sucht. Die AMD Karten mit ihrer bekannt starken OpenGL/CL Performance punkten hier natürlich enorm während die NVIDIA Karten in der Disziplin heftig abstinken da hier CUDA mal so gar nicht hilft....
Gut bringt Dir alles jetzt wenig bei der Frage warum nicht alle Threads voll genutzt werden gibt aber vielleicht zumindest ein wenig Aufschluss darüber wie OS-X tickt. Im Vergleich wäre es vielleicht mal interessant die selbe Übung unter Linux zu betrachten und wenn das durch ist mal eine Messung zu sehen wie fernab von jeder Core Nutzung Windows, Linux und macOS zum Beispiel unter Handbrake mit dem selben File performen also wirklich gestoppt und nicht gebechmarkt
-
Handbrake und Premiere habe ich schon getestet, da spiegelt die halbe Nutzung auch die Performance wieder. Ich habe ein test video (ohne Effekte damit die GPU nicht wirklich hilft) in Premiere unter Windows und unter macOS gerendert (FullHD, 10 Minuten, CBR 15mb/s, 60FPS). In Windows braucht das ganze nur 7 Minuten, unter macOS "ganze" 13 Minuten. Das Video war absolut identisch mit dem selben Einstellungen. Beim zweiten Test mit Handbrake habe ich ein Apple ProRes 422 File (19GB) in ein mp4 format konvertiert, das Ergebnis unter macOS war wieder knapp die hälfte der Performance unter Windows (macOS=80FPS;Windows=145FPS). Es ist einfach extrem nervig die Ursache zu finden, besonders wenn eigentlich wirklich alles Funktioniert (5GHZ Wifi, Bluetooth etc).
-
Mir fehlt hier weiterhin die 3. Komponente wie sieht die Performance unter Linux aus (Vergleich zwischen unixoiden Systemen untereinander und mit Windows)...
