Laut dem Artikel will Apple mehr RiscV benutzen
Die Begründung "Apple would save licensing fees if custom RISC-V cores were used" scheint mir sehr spekulativ zu sein - zahlt Apple wirklich pro Core oder gibts da eine Obergrenze ab der weitere Cores nichts mehr kosten?
weil ja Googles Konkurrenz-Funktion "Street View" in Deutschland reichlich nutzlos ist.
Finde ich nicht, das ist inzwischen eine tolle Möglichkeit um einen Blick in die Vergangenheit zu werfen 
Während das MacBook Pro in diesem Szenario nicht drosseln musste, machte sich die Wärme beim MacBook Air stärker bemerkbar.
Das Drosselproblem lässt sich scheinbar per Please login to see this link. deutlich reduzieren. Ich vermute mal, dass Apple das nicht ab Werk so verbaut um die Temperatur des Gehäusebodens nicht zu weit ansteigen zu lassen.
da schleppt Windows wahrscheinlich mehr Altlasten (16 Bit, 32 Bit, uralte APIs ...) mit sich herum
16 Bit gibts auf den 64-Bit-Windows-Versionen nicht mehr. Uralte APIs schleppt MacOS auch mit sich herum, sogar solche die vor Windows 1.0 entstanden sind.
(aber es gibt dafür Please login to see this link., die wohl einen CPU-Emulator und Teile von Wine verwenden)
Auch Apple Silicon kann Heiss+Laut im Notebookformat wenn man es nur mit genug Software quält
Please login to see this link.
Ich bin schon am überlegen, ob mir nicht auch ein M2-MacBook statt einem mit M1-Pro ausreichen würde – nur die Bildschirmgröße von 13" ist da ein Hindernis.
13" wären für mich kein Hindernis, aber die Beschränkung auf nur einen externen Monitor (wenn man kein Displaylink-Frickeltech will) ist schon unpraktisch.
Ich kann mir vorstellen, dass Apple, analog zum Studio, das Netzteil ins Gehäuse packt (der Platz wäre ja da).
Beim Mac Mini ist das Netzteil doch schon seit 2010 im Rechner integriert? Das war der erste Mini mit Unibody-Alugehäuse bzw. die dritte Generation insgesamt.
Was soll daran besser sein, wenn Samsung, Qualcomm und Hynix ARM übernehmen, als wenn Nvidia es getan hätte?
Warum muss ARM denn überhaupt von jemandem gekauft werden statt als eigenständige Firma zu existieren?
Es gibt jetzt ein Alpha-Release von Please login to see this link., dem Arch-Linux-Remix speziell für M1-Macs (ausser Mac Studio).
Stichwort: 3. Dimension.
Ich habe leider gerade nicht die Zeit um das Video zu schauen, aber reale gestapelte Chips funktionieren anders als der im Vorschaubild gezeigte Balken. Man hat dabei ja als potentiellen Bereich zur Chipverbindung deren komplette Oberfläche zur Verfügung und muss sich nicht auf eine Die-Kante beschränken. Xilinx hat zB seit einigen Jahren einige Highest-End-FPGAs, die aus gestapelten Dies bestehen um mehr Logik in einen Chip zu packen und TSMC hat schon 2020 angekündigt, dass sie bis zu 12 Dies Please login to see this link..
Von Visual Studio auf Windows wissen wir, dass das auch starke Rechner quält und die Lüfter rauschen lässt (schon ohne dass kompiliert wird). Mal gucken, wie sich da der kleine Mac (mit nur 8GB RAM und 512 GB SSD) verhält.
In meinem unwissenschaftlichen Test baut eine umfangreiche Desktop-C++-App auf einem Mac Mini M1 (16GB RAM) in weniger als der Hälfte der Zeit, die das normalerweise verwendete MBP 15" 2018 (6-Kern i7 2.6GHz, 32GB) benötigt. Das Macbook ist dabei kaum zu überhören, der Lüfter des Mac Mini dagegen kaum zu bemerken.
Die für die CI-Boxen der App Verantwortlichen wollten den dafür verwendeten älteren Intel-Mac Mini schon länger ablösen und haben am Mittwoch direkt einen Mac Studio bestellt. 
Lüfterrauschen gibts beim M1 quasi nicht, ich glaube ich habe ihn tatsächlich auch bei Vollast noch nie gehört.
Ich schon - bei längeren Videoencoding mit Handbrake konnte ich nach Ohrauflegen bestätigen, dass ein M1-Mac-Mini einen Lüfter besitzt.
Was mich interessieren würde: liegen die beiden M1-Max-SoCs auf einem Die oder sind 2 physikalisch getrennte Dies "zusammengesteckt"? Also ist der "UltraFusion" Fabric Teil des Dies oder verbindet er zwei Dies?
Das sind mit hoher Wahrscheinlichkeit zwei getrennte Dies, die mittels Please login to see this link. verbunden werden. Der M1 Max ist schon ein ziemlicher Riesenchip (420mm^2), das verdoppelt man nicht mal einfach so.
Wie nennt Apple dann einen 4x "M1 Max", der eventuell im Mac Pro Debut feiern wird?
Gar nicht, der Vier-Die-Chip ist eine Erfindung aus irgendeiner Bloomberg-Meldung, die dann intensiv abgeschrieben wurde. Laut den Asahi-Linux-Entwicklern konnte man schon beim Rumspielen an den Registern des M1 Max feststellen, dass Apple da die Zusammenschaltung von zwei, aber definitiv nur zwei und nicht vier Dies vorgesehen hat.
Als Ergänzung gibt es ein 27"-5K-Display, das mit einem eigenen ARM-Chip (iPhone-Klasse) ausgestattet ist.
Und zwei Lüftern!
Ultramodell mit M1 Ultra (20 CPU Cores, 48 GPU Cores, 32 Neural Engine Cores), 64 GB RAM, 1 TB SSD: 4.600 €
Geht etwas billiger mit 512GB-SSD für insgesamt "nur" 4370 EUR (M1 Max-Variante auswählen und Prozessor umstellen)
Es gibt einen neuen Please login to see this link. vom Asahi Linux-Projekt, der unter anderem erläutert, welche Hinweise auf zukünftige Chips man in der existierenden Hardware finden kann.
Umgekehrt gibt Apple für seine eigenen GPUs wahrscheinlich kaum Unterlagen heraus, weil die ja nicht an irgendwelche Dritten verkauft werden. Die Linux-Leute haben da einfach einen schwierigen Stand. Apple kennt jede schmutzige Ecke der eigenen GPUs, externe Entwickler halt nicht.
Das scheint kein unüberwindbares Hindernis zu sein, Please login to see this link. knobelt auch GPU-Features aus, die via Metal gar nicht verwendbar sind und daher von den MacOS-Treiber nicht genutzt werden.
dann hast du das doch wahrscheinlich irgendwo gelesen. Evtl. eine Quelle?
Puh, keine Ahnung mehr. Eventuell habe ich da auch was falsch interpretiert - spontan finde ich vor allem Hinweise darauf, dass man bei Vulkan deutlich mehr Boilerplate-Code braucht um ein erstes Dreieck rendern zu lassen als bei Metal. MoltenVK (Vulkan-auf-Metal-Wrapper) erwähnt in der Please login to see this link., dass einige Vulkan-Features nicht unterstützt werden können weil sie nicht performant auf Metal abbildbar oder nachbildbar sind.
Die ganzen Hardware-unterstützten Video-Codecs (H264, H265, ProRes ...) z.B. sind doch alle proprietär.
Warum sollte man das nicht analysieren und nachimplementieren können?
Auch die Grafikhardware wird doch vor allem von "Metal" ausgereizt – mit OpenGL/Vulkan wird man da wahrscheinlich auch nicht heranreichen.
Meines Wissens ist Metal - genauso wie OpenGL und Vulkan - eine hardwareunabhängige Grafikschnittstelle und es gibt GPUs von mindestens vier Herstellern, die via Metal angesprochen werden können. Da sehe ich erstmal keinen Grund, wieso man die GPU eines dieser Hersteller nicht auch mit Vulkan ausreizen können soll, was AFAIK sogar noch "low-levelliger" ist als Metal.
Zum einen glaube ich nicht, dass die Speichergeschwindigkeit unbedingt auf die von aktuellen PCs fallen müsste
Ok, da habe ich unsauber formuliert: Genaugenommen ist es die Latenz, die bei einem längeren Weg zum Speicher ansteigt.
andererseits kann das OS das sicherlich so steuern, dass das nur selten passiert – schließlich hätte jede Gruppe von 10 CPU- und 32 GPU-Cores bis zu 64 GB RAM zur Verfügung – da wird man nicht allzu oft ausweichen müssen
Ah, also doch endlich NUMA-Support in macOS
Beim Reversen wurden übrigens tatslchlich Hinweise auf eine Zwei-Die-Konfiguration gefunden:
FWIW, the macOS drivers have plenty of multi-die references, and the IRQ controller in the M1 Pro/Max is very clearly engineered with a (currently unused) second half for a second die.
Aber definitiv nur zwei, nicht vier:
The IRQ controller only has support for 2 dies. Maybe 4x something else, but not this one.
Wenn die folgende Darstellung stimmt
Das Bild ist zwar lustig, hat aber IMHO nicht so richtig viel mit der Realität zu tun - es deutet zB an, dass die grösseren Chips im Vergleich zum M1 mit der Hälfte der Neural-Engine-Kerne auskommen müssten. Ausserdem würde "two Jade-C dies in a package" bedeuten, dass es doch Unterschiede in der Speichergeschwindigkeit gibt, da manche Zugriffe auf direkt angebundenes RAM erfolgen können und andere erst zum anderen Die rübergeleitet werden müssen. Selbst wenn die Anbindung dahin schnell genug ist, Bonus-Latenz gibt es dadurch trotzdem.
Und wenn dann im nächsten Jahr irgendwann Rechner mit den wirklich großen M1-SoCs auf den Markt kommen und damit Lösungen, die statt 32 GPU Cores bis zu 128 davon haben, dann verschiebt sich das Leistungs-Niveau nochmals.
Dann wird Apple aber mit Sicherheit nochmals die Speicherbandbreite erhöhen müssen, wahrscheinlich durch noch mehr Speicherkanäle.
Ein Teil des M1-Performance-Vorteils liegt darin begründet, dass die GPU-Cores Teil des SoC sind und das RAM direkt angebunden ist. DIESE Teile kann man daher nicht einfach per PCIe o.ä. erweitern – ohne dass der SoC-Gedanke ad absurdum geführt wird und die Performance-Vorteile verschwinden.
Man könnte aber zusätzliches RAM oder eine weitere Grafikkarte extern dranhängen. Natürlich wäre Extra-RAM langsamer als On-SoC-RAM, aber letzteres könnte man dann auch als Software-gemanageten Cache betrachten. Bei Systemen mit mehreren CPU-Sockeln gibts das Problem ja schon länger, dass lokal angebundener Speicher schneller ansprechbar ist als Speicher, der an einer anderen CPU hängt und zumindest Windows und Linux haben APIs, damit Applikationen mit sowas umgehen können.
Ein Pro-Modell bekäme dann (neben Pro- und Max-SoCs) einen 3. Thunderbolt-Anschluss, sicherlich HDMI und vielleicht SD-Card-Slot (also ungefähr die MacBook Pro-Ausstattung).
Mindestens bei einem Mac Mini Pro würde ich aber noch die Option auf 10GBit-Ethernet erwarten - das kann man ja schon beim aktuellen M1-Mini dazuklicken.
