Posts by Brumbaer

Alles IMHO:

"Mein" Auto ist "mein" Auto, nur weil ich es besitze, auch wenn ich es nicht selbst hergestellt habe.

"Meine" EFI ist "meine" EFI, weil ich sie verwende.

Ab wann kann man sagen, man habe etwas selbstgemacht ?

In der Industrie gibt es Förderungen, wenn etwas an einem bestimmten Ort produziert oder veredelt wird. Diese Förderung wird/wurde auch gezahlt, wenn das Produkt irgendwo anders gefertigt wurde und nur noch eine letzte Handlung z.B. die letzte Schraube reingedreht am "Geförderort" vollzogen wurde.

Unter dem Gesichtspunkt hat jeder der ein einzelnes Flag in einer Config oder einen Buchstaben in einer SSDT ändert, die EFI "selbst gemacht".

Oft ist es doch dieses eine Flag, dass die EFI plötzlich funktionieren lässt, und dann macht es den Unterschied, egal was alle anderen vorher gemacht haben. Dann hat "meine" Änderung es zum Laufen gebracht.

Solange jemand eine, egal wie klein sie auch sein mag, Änderung gemacht hat, die letztendlich die gewünschte Funktionalität herstellt, hat er das Recht zu sagen, dass er die EFI erstellt hat.

Und machen wir uns nichts vor niemand erstellt eine EFI komplett selbst. Es geht schon mit der Verwendung der in der Doku vorgeschlagenen Einstellungen los. Dann werden SSDT's und Kexte für bestimmte Probleme kopiert. Und Flags gesetzt, von denen man weiß, dass die in der gegebenen Situation "helfen". Kaum einer entwickelt so etwas von Grund auf, alle greifen auf bestehendes Wissen zurück. Oft startet man sogar mit einer existierenden EFI - ob eigene oder fremde.

Wenn jemand eine EFI nicht zu 100% kopiert hat und nur ein Flag geändert hat, das zur Funktionsfähigkeit führt, hat er das Recht zu sagen er habe sie gemacht.

Es ist IMHO ungerechtfertigter verletzter Stolz zu sagen "ich habe aber mehr dazu beigetragen". Zumal die eigene Vorarbeit ja auch wieder auf der Vorarbeit anderer beruht, was man gerne vergisst.

Und wenn jemand tatsächlich etwas einfach 1 zu 1 kopiert, und sich mit "fremden" Federn schmückt verletzt es den Stolz des "Urhebers" zurecht.

Dann kann sollte der Urheber es ignorieren oder ihn konfrontieren. Alles andere scheint mir schlecht fürs Karma

Und niemand will lesen:

EFI XYZ, Flags a, b, c von mir, d und e ursprünglich von x .... SSDT ursprünglich von .. geändert in Zeile 5 durch .... und in Zeile 7 von ....

Ich benutze momentan auch hauptsächlich meinen Mac Mini mit M1. Aber es ist eher Sturheit als eine rationale Entscheidung.

Dass der M1 Programme schneller öffnet kann ich nicht nachvollziehen - er startet sie gefühlt eher langsamer als mein Hack - Intel Programme vielleicht etwas deutlich langsamer. Das M1 System startet schneller - bei einem Kaltstart. Aus dem Deep Sleep ist es wieder schwer zu sagen. Ich könnte es messen, aber es fühlt sich nicht schneller an. Mein Hack baut nach jedem Neustart den Spotlight Index neu auf oder updated ihn zumindest. Ich dachte das läge daran, dass beim Original irgendwas anders wäre, aber der Mini macht das gleiche.

Zwei bestimmte Apps sind spürbar langsamer auf dem M1 und ich befürchte, da wird es so bald auch keine "Nativ Version" geben - ich hoffe auf mehr Performance Kerne im nächsten Jahr. Ansonsten gibt es gefühlt keinen bzw. keinen nennenswerten Geschwindigkeitsunterschied.

Die Anzahl an Anschlüssen genügt mir. Ich habe nur einen Bildschirm, Aktivboxen, Kartenleser, Backuplaufwerk, Keyboard Touchpad am Rechner. Die letzten zwei sind auch noch über einen Hub im Bildschirm angeschlossen. Ich brauche nicht einmal einen zusätzlichen Hub. Laser-Drucker, Scanner, 3D Drucker etc. sind über das Netzwerk (Ethernet) angeschlossen.

Also es gibt für mich keinen Grund meinen Hack durch den Mini zu ersetzen. Es wäre eher sinnvoll den M1 wieder zu verkaufen und auf den Nachfolger zu warten.

Auf der anderen Seite hat der Mini einen Vorteil

Zwei Systeme mit gefühlt vergleichbarer Leistung.

Der Hack ist in Multithread Benchmarks 1.5 bis über 2.0 mal so schnell, aber in Apps merke ich es nur selten. Bei der GPU ist der Unterschied noch krasser, aber ich habe bisher nur eine App benutzt bei der es deutlich zum Tragen kam. Es gibt bestimmt mehr, aber wenn keiner den Baum sieht wenn er umfällt ...

Und es ist absolut faszinierend, den Größenunterschied der beiden Systeme zu sehen.

Frohe und gesunde Feiertage

Gehe im Finder zu deinem Project. Mache einen Rechts-Click. Wähle "Paketinhalt zeigen".

_homm_

Ich nehme an, das sind die Netwerktransferraten laut Aktivitätsanzeige oder eines anderen Tools.

Die 480MB/s ist was deine System-Combo zu leisten vermag. Die 80MB/s kommen dadurch zu Stande, dass dein Projekt nicht eine Datei, sondern ein Verzeichnis ist. Immer wenn eine Datei zu Ende ist und die nächste gestartet wird, gibt es eine "Pause" weil verschiedene Verwaltungsarbeiten ausgeführt werden.

Wenn du dein Projekt zippsed und die Zip Datei überträgst, solltest du auf die volle Datenübertragungsrate kommen.

Wenn du die Zeit in Minuten misst, sollte der Unterschied nicht so deutlich sein.

Wie langsam ist denn langsam in (m:s) für wieviel GB ?

Um eins klarzustellen, das Ram ist nicht auf dem selben Wafer wie der M1, es ist nur im gleichen Gehäuse.

Man sieht es an den Bildern und auch in den Zahlen. Der M1 hat 16 Milliarden (amerik. Billionen) Transistoren. Eine 1 Bit dynamische Ramzelle braucht 1 Transistor. D.h. 16 GB Speicher brauchen 16 * 1024 * 1024 * 1024 * 8 Transistoren. Also mehr als 8 mal so viele Transistoren, wie ein M1 hat.

Es gibt also schon jetzt ein Interface zwischen "externem" DRAM und dem M1. Es ist bestimmt nicht identisch zu dem Interface, wie es für externes DRAM designed würde, aber es ist für Apple's Ingenieure kein Problem den Funktionsblock auszutauschen.

Es ist fraglich ob Apple für jede mögliche Speicherkonfiguration einen Extra Baustein anbieten wollte. Und aus logistischen Gründen ist es möglicherweise einfacher das Ram als getrenntes Bauteil auszuführen. Es ist nicht auszuschließen, dass das Interface mit "normalem" DRAM Performanceverluste mit sich bringen würde, weil das Interface dem "Standard" folgen müsste, während Apple mit DRAM im selben Gehäuse und dessen Anbindung Abläufe optimieren könnte.

Die Verwendung einer GPU mit externem DRAM ist dafür mglw. einfacher als mit "internem".

Wie man sieht weiß man nichts genaues.

Aber mir scheint sicher, wir werden mehr Performance Kerne in der CPU sehen. Bei der GPU bin ich mir kurzfristig nicht so sicher. Mein Tip wäre eine mittlere Konfiguration mit z.B. 32K Speicher fest und etwas schnellerer GPU; und eventuell eine "Pro" mit externem DRAM und externer GPU. Aber vielleicht sagt sich Apple auch die Mxe gibt es nur mit internem RAM und GPU und wer noch mehr Leistung will muss noch ein Jahr oder zwei länger warten.

Wir werden sehen, es bleibt auf jeden Fall spannend.

Nach den vielen Vielthreadern, mal was normales, ein 10900K.

TheWachowski

Das Luxmark zeigt, dass zumindest nichts offensichtlich falsch ist mit der Config deiner Karten.

Ich sach ma so.

Der BRT zeigt auf meinem System im Normalfall 57/87

Ich kann die Anzahl Lanes nicht verändern, aber ich kann Gen2 statt Gen3 als Übetragungsmodus wählen.

Die Übertragungsgeschwindigkeit der 16 Lanes sinken von 15,5GB/s auf 8GB/s. Der Wert sollte nun auf 57/46 fallen, tut er aber nicht. Er fällt nur auf 57/67. Also hat die Datenübertragungsgeschwindigkeit eine Auswirkung.

Schauen wir uns die oben geposteten Screenshots an.

Was gemessen wird ist die Anzahl der Frames/s.

Man kann erwarten daß innerhalb einer Testgruppe BRAW12:1 in einer Sekunde immer die gleiche Datenmenge durch die GPU geht.

Innerhalb einer Gruppe werden FPS Raten für verschiedene Formate angegeben. 4K hat 4 * so viele Pixel wie HD, also sollte die Datenrate auch nur ein Viertel betragen. Analog 8k zu HD ein Sechszehntel.

Und siehe da es passt.

Wir können uns also auf einen Wert jeder Testgruppe beschränken, ich nehm den ersten den HD Wert.

12:1 hat die höchste Rechenzeit, aber die geringste zu übertragene Datenmenge.

3:1 hat die kürzeste Rechenzeit, aber die größte zu übertragene Datenmenge.

Das Datenaufkommen zwischen den Gruppen Datenaufkommen 1,0; 1,5; 2,4; 4. Der genau Faktor hängt vom Datenstrom ab, aber generell passt es.

Ich habe mal den Anteil der Datenübertragung bezogen auf den theoretisch möglichen Wert bestimmt.

Man sollte annehmen, dass mit abnehmenden Kompressionsfaktor, der Prozentsatz steigt. Denn die zu übertragenden Daten wachsen und die Rechenzeit pro Bild sinkt.

Auffällig ist, dass díes nur für die Vega Frontier mit 10900K zutrifft. Bei den anderen Systemen sinkt der Prozentsatz für BRAW3:1.

Beim 8700K ist auch BRAW 5:1 niedrig.

Meine erste Vermutung war, dass es am Treiber liegt, falsch.

Ich habe den 10900K auf 6 Kerne beschränkt und siehe da, der Prozentsatz sinkt nun auch bei der Vega.

D.h. Der Prozessor ist der Bottleneck. Das würde auch das Verhalten des 8700K bei BRAW5:1 erklären.

Ok zurück zum Ausgangsproblem.

Schauen wir uns die Systeme mit Vega 64 und Vega 7 an, sehen wir, dass der Grad der ausgenutzten Datenübertragung sich im selben Bereich befindet. D.h. eine Vega 7 schafft es bei BRAW12:1 etwa 66% der theoretischen Datenübertragungsrate der der GPU zur Verfügung stehenden Lanes zu nutzen. Das System mit 8700K auch etwas weniger, weil der Prozessor langsamer ist, weshalb er auch schon bei BRAW5:1 einknickt.

Dass das System mit den 2 Vega 64 bei 62% liegt kann an der Vega selbst oder der Aufteilung der Berechnungen auf 2 GPUs liegen. Ist aber unwesentlich.

Hat man zwei Vegas, so können sie immer noch 66% der Bandbreite nutzen. Das Problem ist im 9900K System ist die Bandbreite 15.5GB/s egal ob man eine oder zwei Karten verwendet, weil sie sich 16 Lanes teilen. Beim 10980XE ist es anders. Da sind es 66% von 31GB/s (natürlich nur wenn man zwei Karten hat).

Da der FPS Wert sich direkt aus der Datenübertragungsrate ergibt bedeutet 66% von 31,5 ergibt den doppelten Wert wie 66% von 15,75.

Also ja, ich denke es liegt nicht an der Konfiguration, sondern nur an den Lanes.

TheWachowski

Die Anzahl Threads der CPU spielt vermutlich ein wenig rein.

Aber die Anzahl, der an den Prozessor angebundenen PCIe Lines dürfte in diesem Falle den Unterschied machen.

Dein 9900K hat nur 16, die sich die GPUs teilen.

Nicos CPU hat genug Lanes, so dass jede GPU mit 16 PCIe Lanes an der CPU angebunden ist.

Da viele Daten auf die Karte und wieder runter kopiert werden, macht sich das bemerkbar.

Führ mal einen Luxmark aus und schau, was dabei rauskommt.

Ich habe meinen M1 Mini seit Donnerstag letzter Woche und die Ergebnisse sind - wie ich finde zu erwarten war - gemischt.

Die Benchmarks haben einen vermuten lassen, dass Single Thread Anwendungen schnell laufen und Multithread Anwendungen im Vergleich dazu langsam sind - es sei denn irgendeine Spezialfunktion auf dem M1 hilft - und dass die GPU besser als eine Intel GPU und schlechter als eine dedizierte Mittelklasse GPU sein würde.

Erstmal merke ich keinen Unterschied zu meinem 10900K System. Wenn man mit der Stoppuhr misst ist der M1 hin und wieder schneller aber nicht spürbar. Ein paar Anwendungen für den 3D Druck und auch Cinema 4D haben Funktionen die von vielen Kernen profitieren und die sind auf dem M1 massiv langsamer (grob Faktor 2) als auf dem 10900K. Eine App verwendet die GPU in starkem Maße und auch da ist der M1 ganz weit weg vom Hackintosh mit einer Vega Frontier.

Ich bin fasziniert von dem Potential und der Leistungsfähigkeit des M1 und Rosetta - denn machen wir uns nichts vor er zielt auf den i3 und i5 nicht auf den i9 mit dedizierter GPU.

Selbst Apps unter Rosetta laufen flüssig mit ausgezeichneter Performance. Bisher habe ich nur zwei Apps gefunden, die Probleme zeigen. Aber Rosetta - ganz Dame - lässt die Apps nicht abstürzen sondern zeigt nur Fehler.

16 GB genügen für das was ich tue und 4 Ports sind auch ausreichend.

Bei meinen Anwendungen ersetzt der Mini noch nicht meinen Hack, aber wenn mein System ein i5 oder älterer i7 wäre, würde ich wohl wechseln.

ich bin etwas überrascht, was hier erwartet wird.

Der M1 ist gegen den i3 oder einen niedrig getakteten i5 positioniert.

Schließlich tauchen sie nicht im iMac oder im MacPro auf.

Der M1 lässt keine echten Rückschlüsse auf die Performance des M2 oder wie auch immer die auf mehr Leistung getrimmte Version heißen wird, zu.

Der schlechte Multithreatingwert liese sich ganz leicht anheben, indem man die 4 Efficiency Kerne durch 4 Performance Kerne ersetzen würde. Was bei Tischgeräten kein Problem sein sollte.

Ja es wird interessant sein zu sehen wie der M1 in Benchmarks abschneidet, aber wichtiger ist, wie er sich im System verhält und wie im Vergleich zur alten Version des Rechners den er ersetzen soll abschneidet. Man beachte zu einem vergleichbaren Preis ersetzen soll.

CMMChris

Gibt es zu dem Benchmark den kompletten Report, damit man sehen kann wie der M1 in den Einzeltests abgeschnitten hat ? Das liese zum Beispiel Aufschlüsse über die Integer, Floating Point und Memory Performance zu.

Was interessant ist, wenig Aussagen über echte Performance.

Alles nur Performance/Power Verhältnis.

Das Ding kann die doppelte Performance/Power haben, aber wenn die TDP nur ein Drittel ist - verkackt.

Wenn die angegeben Werte pro Kern sind, dann sind die L1 Kerne sehr groß.

Der L2 Cache ist etwas klein, aber nicht sehr klein. Vielleich ist der L2 Cache auch nur was für die "schnellen" Kerne oder sie bekommen eine größere Scheibe ab.

Die GPU hat laut Video

128 Execution Units, liefert 2,6 TFlops (hoffentlich SP), 82 GTtexel und 41 GPixel. Im Vergleich die nicht mehr aktuelle Vega Frontier

64 Compute Units, liefert 13 TFlops (SP), 353 GTextels und 88 GPixel und die RX580

36 Compute Units, liefert 6,175 TFlops (SP), 193 GTextels und 42,88 GPixel und die Vega 8 Laptop Graphic

8 Compute Units, liefert 1,1 TFlops (SP), 35 GTextels und 8,8 GPixel und die UHD 630

24 Execution Units, liefert 0,4 TFlops (SP), 25 GTextels und 3,1 GPixel .

Somit ist sie weit von der Frontier und weit von der UHD 630.

Die Vega 8 passt ganz gut zum Faktor 2 zur leading laptop GPU

und der Faktor 6 zur UHD630 ex Mac Mini.

Wenn es so wäre, wäre der momentan Abstand zur Frontier grob Faktor 4,5 bis 5.

Der Abstand zur RX580 nur etwa 2.5.

Wie lange sie brauchen um den Abstand aufzuholen weiß man nicht, ist aber eh irrelevant, da man nicht weiß wann sie mit der Entwicklung des M2 angefangen, nur eins ist sicher - bestimmt nicht erst heute.

Basiert Alles nur auf Vermutungen, da man nicht weiß was genau als Referenz genommen wurde und wie was genau getestet wurde.

karacho

Sag doch mal ob der Lag im Video stärker oder schwächer ist als bei dir. Sonst kann ich die Schwere des Problems nicht einschätzen. Außerdem Kritik ist erlaubt.

Ok, ich habe von 1.1 zu 1.2 nichts geändert außer der Farbauswahl und neu kompiliert.

Um mir den Lag mal anzuschauen habe ich auf meinem alten iMac Catalina installiert und OCMerge 1.2 laufen lassen. Die config ist eine normale config von mir, als Full Sample dient die Sample.plist aus dem 0.63 nightly build von irgendwann.

Das video ist eine Quicktimeaufzeichnung eines Bildauschnittes (zur Not downloaden und dann anschauen). Im Original scrollt er etwas flüssiger als in der Aufzeichnung. Ist das der Lag den ihr meint ?

Bildschirmaufzeichnung

Beachtet, das ist eine alte Kiste mit einer GTX780

karacho

Das Tool ist als Fingerübung für SwiftUI entstanden.

Ich sehe keinen Grund dafür dass sich das Tool auf Catalina und BigSur unterschiedlich verhalten sollte - außer, dass das SwiftUI Framework für Catalina träger ist.

Ich werde das Tool nicht wegen Catalina Performance ändern oder von SwiftUI auf normale UI Elemente umstellen. Catalina ist für mich passé. Sorry.

LuckyOldMan

Die App im ersten Post, ist sozusagen die Release Version. Die, die später im Thread kommen, sind Testversionen. Erst wenn die Beta Version bestätigt wurde, wird sie in die erste Post übernommen. Das vermeidet, dass sich einFehler in der Testversion verbreitet.

Ich habe noch keine Aussage ob das Problem von Kuko behoben ist.

Sollte das geschehen, wird die Datei im ersten Post ersetzt.

Ich werde aber einen entsprechenden Vermerk in der ersten Post machen.

kuko

Schau mal ob das besser ist

OCListMerge.app.zip

???? Es ist doch die selbe Datei. Ich hatte sie ersetzt, nachdem ich das Feedback von den Benutzern hatte.

Wenn ich das richtig sehe, geht es darum XHCIPortLimit zu verwenden und damit USBInjectAll und andere Methoden der Portbeschränkung überflüssig zu machen.

Ich bitte dabei zu bedenken, dass im OCConfig davon abgeraten wird.

1. XhciPortLimit
   Type: plist boolean
   Failsafe: false
   Requirement: 10.11 (not required for older)
   Description: Patch various kexts (AppleUSBXHCI.kext, AppleUSBXHCIPCI.kext, IOUSBHostFamily.kext) to remove USB port count limit of 15 ports.

   Note: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in locationID format and there is no possible way to workaround this without heavy OS modification. The only valid solution is to limit the amount of used ports to 15 (discarding some). More details can be found on AppleLife.ru.

Lässt mich kalt. Ich biete etwas an, nimm es oder lass es.

Wenn es dir wichtig ist, schreib's halt neu und pack es zu deinen anderen GitHub Projekten.