News M1-Prozessor: Apples Notebook-SoC soll die Konkurrenz abhängen

[Darkseth88]

beziehungsweise, dass Apple's Chips weit mehr als nur "große ARM Kerne" sind. Die scheinen mit dem "standard ARM Design" fast soweit entfernt zu sein, wie Intel's x86 Plattform.

Edit: Daraus lässt sich schließen, dass man es durchaus Möglichkeiten gibt, die Vorteile von "ARM" mitzunehmen, ohne zu sehr auf die Vorteile von x86 verzichten zu müssen.
Zumindest scheint es bisher nichts zu geben, wo der M1 wirklich "abkackt" verglichen zu aktuellen x86 Chips.

 

[Forlorn]

Ich habe das hier schon einmal im Forum verlinkt: https://images.anandtech.com/doci/16226/perf-trajectory_575px.png

Wenn Apple (und davon ist auszugehen, da sie ja schon seit 10 Jahren daran arbeiten) in 2 Jahre die 3. Generation von M1 auf dem Markt wirft, sieht Intel kein Land mehr. AMD arbeitet ja an Unified Memory und plant auch GPU-Chiplets ab 2022. CPU kann AMD locker mithalten, aber bei Leistung/Watt dann eben doch (noch) nicht.

Hier wollen sich manche nicht vorstellen können, dass x86-PC-Systeme von großes SoC auf ARM Basis eigentlich gerade schon abgehängt sind und in nächster Zukunft ersetzt werden. Ich fasse mal grob zusammen: kann man nicht aufrüsten, zu wenig Speicher... Ich habe selbst noch kein M1 basierten Rechner, aber konnte schon mal an einem eine Weile arbeiten. Dieses null-input-lag Verhalten mit Multitasking bei einem lüfterlosen Air mit 8GB RAM (selbst im Vergleich zu meinem Rechner) hat mich echt umgehauen.

Ich hoffe ja ein wenig auf RISC-V wegen der Offenheit, aber das dauert auch noch.

 

[Piktogramm]

@Forlorn
Unified Memory ist so 2013-2015 in AMD und Intel CPUs integriert worden. Da ist Apple eher sehr spät mir dabei. Man muss nur sehr tief in die Doku und sehr nah am System programmieren, dass man damit in Kontakt kommt.

 

[foo_1337]

Apple ist sehr spät, weil es deren erster "PC" SoC kann? Und wenn du es so willst, ist Apple da auch schon länger mit Axy dabei.
Der M1 punktet halt damit, dass der Speicher direkt auf dem Package ist und mit sehr hoher Taktrate betrieben wird.

 

[Forlorn]

@Forlorn
Unified Memory ist so 2013-2015 in AMD und Intel CPUs integriert worden.

Stimmt, ich meinte eigentlich das Unified Memory SoC Package von Apple. Die Anbindung von AMD/Intel ist hier sehr viel langsamer.

 

[Piktogramm]

@foo_1337
Was ist Axy, die Suchmaschine meiner Wahl spuckt da nichts nützliches aus unter "Axy Apple"

Für sich genommen, ist Unified Memory ein Feature welches auch bei ARM seit Jahren weit verbreitet sein sollte: https://community.arm.com/developer...ry-management-on-embedded-graphics-processors

Was Apple mit seiner A-Reihe intern macht weiß ich nicht genau, aber sich im Jahr 2020 hinzustellen und unified Memory als großes Ding herauszustellen ist in meinen Augen lächerlich. Denn entweder loben sie sich da über den Klee für ein Feature welches sie selbst schon Jahre integriert haben oder aber sie sind extrem spät dran.

@foo_1337 & @Forlorn
Unified Memory und "On Package Memory" sind zwei komplett verschiedene Schuhe. Auch bringt LPDDRX on Package nur einen Vorteil, eine günstigere Fertigung[2]. Auf die Performance wirkt sich das überhaupt nicht aus, ob der Speicher nun eine Leitungslänge von 1 oder 10cm hat[1].
Ansonsten, ja richtig. Die dicke Speicherbrandbreite hilft. Imho ist das ein Leitmotiv vom M1. Speicherlimitierung wird auf allen Ebenen angegangen. Dicke Caches, viele Ebenen Cache und dicke Speicheranbindung zudem gleichzeitig anscheinend leistungsfähiges Prefetching + Sprungvorhersage.

[1]
Geschwindigkeit von elektrischen Pulsen in Kupfer ist ~200.000.000m/s, Signallaufzeit je cm Leitungslänge entspricht 5*10^11s bzw. für 10cm dann 5e^10 wobei zufällige Zugriffe auf Speicher beim m1 grob 100ns (1*e^7s) dauern. Damit ist die einfache Signallaufzeit bei 10cm Leitungslänge ganze 3 Größenordnungen von der Gesamtlatenz weg. Das ist unbedeutend.

[2]
Es ist günstiger eine kleine Platine hoher Leitungsdichte zu fertigen die CPU und Speicher vereint. Richtig umgesetzt kann man so beim größeren Mainboard 1-3 Layer einsparen. Wobei Apple hier wirklich gut skalieren kann. An sich fertigen die ja drei verschiedene M1-Packages und haben damit drei verschiedene Mainboards zu versorgen. Wobei sichergestellt ist, dass jedes Package und Mainboars mindestens in 6-stelligen Stückzahlen fertigen und verkaufen werden.

 

[foo_1337]

@foo_1337
Was ist Axy, die Suchmaschine meiner Wahl spuckt da nichts nützliches aus unter "Axy Apple"

Die Apple A Prozessoren, A14, A13 usw

@foo_1337
Was Apple mit seiner A-Reihe intern macht weiß ich nicht genau, aber sich im Jahr 2020 hinzustellen und unified Memory als großes Ding herauszustellen ist in meinen Augen lächerlich. Denn entweder loben sie sich da über den Klee für ein Feature welches sie selbst schon Jahre integriert haben oder aber sie sind extrem spät dran.

Haben sie? Sie haben es im Zusammenhang mit ihrem high-bandwidth, low-latency package erwähnt. Ist das falsch?

Ansonsten, ja richtig. Die dicke Speicherbrandbreite hilft. Imho ist das ein Leitmotiv vom M1.

Und genau dieses Leitmotiv haben sie hervorgehoben. Und in dem Zusammenhang eben Unified Memory. Später in der Zusammenfassung haben sie diese Details weggelassen und nur noch unified Memory geschrieben.

 

[Piktogramm]

Haben sie? Sie haben es im Zusammenhang mit ihrem high-bandwidth, low-latency package erwähnt. Ist das falsch?

Zum Apple Event haben sie vor allem Buzzwords, Hohlphrasen und nichtssagende Folien abgefahren und alle möglichen Sachen zusammen geworfen. Erschreckend ist, dass viele Medien das relativ ungefiltert übernommen haben.
Was Unified Memory ist, ist klar definiert. Es bedeutet, dass verschiedene Komponenten eines Systems einen einheitlichen Speicherbereich mit einheitlicher Adressierung nutzen können. Das ist überwiegend etwas was in der MMU implementiert wird. Was davon völlig entkoppelt ist, ist die Bandbreite der Speicheranbindung, die Latenz der Anbindung, ob das ganze oder Teile des Packages von Apple designend sind.
Einzig, dass bei unified Memory der Speicher durch alle Komponenten des SoC' erreichbar sind stimmt, genau das ist ja der Witz bei UM..

Und genau dieses Leitmotiv haben sie hervorgehoben. Und in dem Zusammenhang eben Unified Memory.

Das Leitmotiv ist halt lächerlich. Denn entweder hatten sie UM sowieso schon die letzten 6Jahre in ihren Chips. Schlicht weil es Stand der Technik war und eine wirklich niedrig hängende Frucht, oder aber sie loben sich über den Klee, dass die 6Jahre nach allen Anderen das Feature auch endlich haben.
Ich Spekuliere jetzt mal frei heraus. Die Präsentation war darauf getrimmt leicht konsumierbar zu sein für Kunden, Investoren und Non-Tech Media. Entsprechend wenig genau waren alle Angaben zur Technologie. Funktioniert hat das ganz wunderbar. Es gibt zahlreiche Menschen und Medienoutlets die Apple UM als neuen heißen Scheiß hypen und es undifferenziert mit "on Package Memory" vermatschen. Obwohl es technisch komplett unterschiedliche Dinge sind.

 

[foo_1337]

Klar war die Präsentation auf die genannte Zielgruppe ausgerichtet. Daher waren ja diverse Techmedien auch so überrascht, dass das Ding hält, was es verspricht. Unified Memory gabs mindestens schon 2016 im iPhone 6s und vermutlich auch vorher. Ich frage mich aber mehr, weshalb sie so hervorgehoben haben, dass entwickler nun erst auf den VRAM Adressraum zugreifen können. Das hat er nämlich bei der Keynote explizit so gesagt. Entweder war das vor Bigsur schlicht nicht möglich und ist es jetzt dann auch mit den Intels (oder auch nicht, künstliche beschränkung), oder es war dummes blabla. Da ich beides hier habe, könnte ich das mal testen, wenn ich sample code finde.

 

[Piktogramm]

Ich glaube halt schon nicht, dass Entwickler angesprochen wurden. Wenn bei solchen Präsentationen "developer" gesagt wird, dann dient das dazu Felder im Buzzwordbingo der Investoren und Journalisten zu treffen.
Das VRam direkt adressiert werden kann, ist alles nur nicht neu. Das muss unter OpenGL und OpenCL schon funktioniert haben.

Was Sample Codes angeht:
https://developer.apple.com/documen...g_calculations_on_a_gpu?preferredLanguage=occ

Gut, ich habe von der ganzen grafischen Programmierung keine Ahnung. Aber für mich wirkt das Beispiel für Metal so, als ob Programmierer unter Apple um Speicher kaum/nicht kümmern muss. Wobei https://developer.apple.com/documentation/metal/mtlbuffer/1515716-contents verweist auf func contents() -> UnsafeMutableRawPointer ohne darauf einzugehen, was da im Hintergrund abläuft.

 

[foo_1337]

VRAM ja, aber nur ein Fenster. Er meinte den gesamten VRAM adressieren, also ähnlich wie bei dGPU und der vergrößerten BAR.
Muss mir das nacher mal ansehen. getVRAMRange() klingt erstmal nicht verkehrt

 

[Forlorn]

Bei den Ergebnissen kann man aber nicht bestreiten, dass hier deutlich geringer Latenz und höhere Bandbreite bei Apple vorhanden sein muss, dass kann man nicht nur in Software lösen. Wie es denn mit PR genannt wird, ist letztendlich egal.

 

[foo_1337]

Ja das ganze ist als User brutal spürbar. Die Berichte zu lesen ist ja teils schon faszinierend gewesen, aber das ganze selbst zu erleben ist nochmal ne andere Nummer. Und dazu, dass das Ding ohne Lüfter oder gar Schlitze im Gehäuse kalt bleibt.

 

[Piktogramm]

? Aber der gesamte VRam ist doch sowieso immer als Gesamtheit in den virtuellen Adressbereich eingeblendet. rBar ändert doch "nur" die Größe der Zugriffe. Was im Großen und Ganzen mit wenig mit Unified Memory bzw. dem damit möglich werdendem ZeroCopy zwischen CPU, GPU, NeuralEngine oder sonstigen Componenten zu tun hat. Vor allem müssen bei ZeroCopy sowieso nicht viel Daten übertragen werden (das ist ja der Witz..). Das sind zwei Pointer (startAdress, length) und gegebenenfalls etwas Statusinformationen. Wenn da mehr als 512bit übertragen werden müssen würde mich das schon verwundern. Ob da BAR nun 1MB oder 12TB groß ist, ist egal, die Nutzlast muss ja "nur" von der MMU gemappt werden und eben nicht über irgend einen BUS kopiert werden.

@Forlorn
Geringe Latenzen von was im Verleich zu was? Apple M1 L1 und L2 Cache sind vergleichbar schnell wie das was sich auch bei Intel/AMD findet. Apples SLC Cache wirkt vom Verhalten wie ein Victim Cache und die Latenz vom Memory entspricht genau dem, was man von LPDDRX-4266 erwartet...
Wenn es dir um die gefühlte Reaktionszeit als Anwender geht. Das ist ein Wust aus div. Latenzen der Hardware und Software. Wobei der Software Part in der Regel maßgeblich ist, gefolgt von Latenzen vom Festspeicher und erst zu aller Letzt die Latenzen von Memory oder gar Caches[1]. Darauf zu schließen, dass das System "snappy" wirkt, dass die CPU irgendwie besonders toll ist stimmt auch nicht. Die geringsten Latenzen und den kleinsten Jitter haben in der regel kleine µController/CPUs ohne dickes OS

[1]Caches werden erst interessant wenn die CPUs buggy sind als Mitigation reguläre Caches sowie TLB Cache bei jedem Kontextwechsel invalidiert werden. Das macht für einzelne Klicks von Nutzern nicht viel, verhagelt Serverbetreibern aber definitiv die Laune..

 

[Forlorn]

Stimmt. Ich stecke nicht so tief in Hardware drin, damit habe ich vor mehr als 20 Jahren aufgehört. Feeling old right now...

Nachdem was ich so gelesen habe, muss der Aufwand bestimmter Assembler/Machinencode sehr gering sein und dadurch Dinge, die aufwendig in AMD/Intel durch höhere Anforderungen ans Kopieren länger dauern, sehr beschleunigt. Schwächen kann Apple natürlich durch deren kompletten vertikale Kontrolle durch Hard- und Software ausgleichen. Intel und AMD können das nicht leisten, da sie keine Kontrolle über das Endprodukt haben.

Da ist meiner Meinung auch in den nächsten Jahren der deutliche Nachteil bei AMD, Intel und Microsoft. Ich verstehe auch persönlich nicht, warum im Mobilbereich Google sich nicht dicker mit Qualcomm abspricht. 🤷‍♂️

 

[Piktogramm]

@Forlorn
Ja gelesen, es steht halt so massiv viel Bullshit auf vielen Kanälen. Es mag einige x86-Befehle geben die komplex sind und aufwendig zu dekodieren sind. Real läuft die meiste Software mit ordinären load,store,add,multiply,xor Befehlen. Da nimmt sich ARM und X86 beim zeitlichen Aufwand der Decoder nichts/nicht viel. Und selbst wenn X86 Decode mal länger braucht, sollte die Befehle in einem Loop laufen (was meist der Fall ist), wird das über Caches geregelt.
Imho ist der Hauptgrund, dass der M1 so gut ist, der, dass Apple auf alle bekannten, klassischen Flaschenhälse massiv Transistoren geworfen hat und gleichzeitig die Kontrolle über das Ökosystem der Software hat.

 

[foo_1337]

Auch Anwendungen und Compiler, die nicht viel, außer der libc, mit dem Apple Ökosystem zu tun haben laufen sehr schnell.

 

[Piktogramm]

Das stimmt, das letzte bisschen Leistung holt man dennoch darüber raus, wenn man Apples Implementierungen der Bibliotheken und deren propritär erweiterten LLVM nutzt. Wobei sich Apple auch viel Mühe gibt, das Entwickler nicht all zu sehr von Apples Infrastruktur abweichen. Eben weil Funktionalitäten teils nur so nutzbar sind (Apples Matrix Instruktionen gibt es nur über die Nutzung von Bibliotheken)

 

[Forlorn]

dass Apple auf alle bekannten, klassischen Flaschenhälse massiv Transistoren geworfen hat und gleichzeitig die Kontrolle über das Ökosystem der Software hat

Und die anderen können (AMD/Intel) oder wollen (Qualcomm) das nicht im Moment. Die Einführung von neuen Technologien wie DDR5 oder AMDs Chiplets für GPUs könnte das ausgleichen, aber solange das alles Einzelkämpfer sind, wird das nichts werden. Die Produktionskette erlaubt zu viele Sonderwege.

 

[foo_1337]

Eben weil Funktionalitäten teils nur so nutzbar sind (Apples Matrix Instruktionen gibt es nur über die Nutzung von Bibliotheken)

Danke, das war mir bisher so nicht bewusst. Bin gerade dabei, die Kommentare hier https://news.ycombinator.com/item?id=25559145 zu lesen