1. Foren
  2. Kommentare
  3. Sonstiges
  4. Alle Kommentare zum Artikel
  5. › Apple: Macbook Pro mit M1X-Chip und…

RAM

  1. Thema

Neues Thema Ansicht wechseln


  1. RAM

    Autor: Crass Spektakel 16.01.21 - 15:21

    Interessant ist daß bei diesen Geräten das RAM nicht mehr als Multi-Die neben der CPU angebracht wird sondern ganz regulär als normales DDR4-RAM verbaut wird. Die schlechtere Leistung konventionellen RAMs will man wohl durch mehr Breite im Bus ausgleichen. Das ist auch dringend nötig da ARM-Architekturen durch dickeren Code mehr Bandbreite brauchen.

    Ob trotzdem RAM auf dem Träger direkt verbaut wird - vieleicht als Level4-Cache - wird interessant denn AMD plant mit Zen4/Epyc mit High Bandwidth Static Memory ja etwas ähnliches: Da sitzen dann 1-4GByte 6T-SRAM als zusätzlicher Die neben CPU- und IO-Die auf dem Träger.

    Interessanterweise wird das wohl wirklich 6T- oder sogar 8T-SRAM obwohl 4T-SRAM eigentlich simpler ist und weniger Transitoren braucht. Aber 6T/8T-SRAM kann man enorm stromsparend implementieren, 4T-SRAM hingegen braucht fast so viel Strom wie normales DRAM.

    Die von Samsung bisher verfügbaren 6T-SRAM-Zellen auf HBSM-Dies mit 1024MByte sind dabei schon recht beeindruckend: Zugriffszeiten unter 3ns, linearer Durchsatz von fast 1TByte/s und das bei einem Verbrauch um 5W. Gerade die Zugriffszeiten sind unglaublich, die Bandbreite hingegen ist Perlen vor Säue, ich kenne keine einzige Anwendung die auch nur 100GByte/s wuppt.

    Wobei, bei den Preisen von Apple könnte Apple natürlich gleich HBSM als alleinigen Hauptspeicher verbauen. Das wäre wirklich mal ne Ansage ;-)



    1 mal bearbeitet, zuletzt am 16.01.21 15:24 durch Crass Spektakel.

  2. Re: RAM

    Autor: ms (Golem.de) 16.01.21 - 16:03

    Wieso gehst du von regulärem DDR4 aus?

    Davon ab nutzt HBM(2) keinen SRAM, sondern DRAM.

    Marc Sauter, Sr Editor
    Golem.de



    1 mal bearbeitet, zuletzt am 17.01.21 09:30 durch ms (Golem.de).

  3. Re: RAM

    Autor: dh99 17.01.21 - 08:23

    und warum hat ARM "dickeren Code"?

    Gibts da eine Quelle?

  4. SRAM # DRAM

    Autor: Crass Spektakel 17.01.21 - 11:10

    Ich rede nicht von HBM(2) sondern von HBSM(1).

    Die Vor- und Nachteile von Static Memory kann man bei Wikipedia nachlesen.
    TL;DR DRAM braucht viel Strom, lange Zugriffszeiten aber wenig Transistoren, SRAM braucht wenig Strom, kurze Zugriffszeiten und braucht 3-8mal so viele Transistoren.

    Das 256MByte-Die verwendet Samsung bereits als schnellen Speicher für High-End-DSPs in Funkanlagen. Technisch gesehen war HBSM unter anderem Namen sogar lange vor HBM verfügbar.

  5. ARM=Lahm

    Autor: Crass Spektakel 17.01.21 - 11:25

    dh99 schrieb:
    --------------------------------------------------------------------------------
    > und warum hat ARM "dickeren Code"?
    > Gibts da eine Quelle?

    Weil die Opcodes dicker sind?

    Bei ARM besteht ein Opcode grundsätzlich immer aus einem 32Bit-Befehl sowie gegebenenfalls Paramter die ebenfalls 32Bit groß sind.

    Ein simples "addiere 8 auf Register 1" braucht bei ARM 64Bit.
    Bei x86 16 Bit.
    Dann kommt noch dazu daß ARM abseits von SIMD nur umständlich mit Daten umgehen kann die nicht 32Bit-Aligned sind. Da wird eine 8Bit- oder 16Bit-Operation eigentlich cache-intern immer zu einer Load-Modify-Store-Operation.

    Das ist ja auch der Grund warum ARM-Lösungen bisher immer unterirdisch schlecht performen. Man muß mindestens die doppelte Busbreite, die doppelte Cache-Menge und das doppelte RAM für Code vorsehen.

    Intern verarbeiten sowohl die besseren ARM als auch alle x86-CPUs sowieso keinen ARM/x86-Code sondern einen spezifischen Microcode. Es geht eigentlich nur um die Übersetzung und die kostet auf beiden Plattformen exakt Null Leistung. ARM is not Magic.
    Mich wundert es daß Apple überhaupt auf ARM zurückgreift. ARM hat ein paar inherente Nachteile und Apple wäre sehr wohl in der Lage eine eigene Architektur zu entwickeln. Die Kunst sind ja nicht die Opcodes sondern die Microcodes.

    Apple hat das simpel und brutal gelöst und einfach sehr schnelles und teures Spezial-RAM direkt auf den Träger gebondet. Von der Leistung her entspricht das RAM einer konventionellen Lösung mit 256Bit und 8ns. Das ist sauschnell, selbst ein Overclocker-Threadripper kommt da kaum ran. Damit kommt der M1 grob auf Ryzen 5600-Niveau der üblicherweise RAM mit 128Bit und 12ns verwendet. Hätte er normales DRAM würde das locker 30% Leistung kosten.

    Das begrenz natürlich die Aufwuchsfähigkeiten. Eine Apple-CPU mit 64-Kernen und 256GByte RAM bräuchte dann einen 1024Bit-Bus mit 5ns. Dazu müßte Apple 64 RAM-Dies direkt neben die CPU bonden. Das geht nicht.

    Das begrenzt zwar den Gesamtspeicher und macht das Gerät süffisant teuer aber da Apple sowieso nicht im Highend- sondern im Accessory-Segment konkurriert ist das erstmal wurscht. Nur so als Beispiel, das was Apple momentan als High-End verkauft (8 Cores, 16GByte RAM) das hatte ich schon 2007 unterm Tisch stehen. Hat damals kaum mehr gekostet als das was Apple heute anbietet. Heute hat selbst mein Spielerechner 64GByte RAM und 2000GByte SSD. Und der ist fünf Jahre alt.

    Und genau da kommt HBSM ins Spiel: Das ist sogar noch schneller aber so teuer daß es als RAM kaum taugt, als Cache aber sehr gut läuft. Der 1GByte-6T-Die kostet in 1000er Stückzahl ca. $65.

    Normales HBM taugt hier nichts denn das hat zwar einen hohen linearen Durchsatz aber einen ziemlich lahmen wahlfreien Zugriff. Für Grafik toll für Caches Pfui.



    4 mal bearbeitet, zuletzt am 17.01.21 11:41 durch Crass Spektakel.

  6. Re: RAM

    Autor: Gamma Ray Burst 17.01.21 - 11:40

    dh99 schrieb:
    --------------------------------------------------------------------------------
    > und warum hat ARM "dickeren Code"?
    >
    > Gibts da eine Quelle?


    Der ARM Code für den Linux Kernel ist wohl kleiner als der Code für x86.

    Argument ist, dass die Binaries für ARM (RISC, R wie reduced) kleiner sind weil weniger Instruktionen benötigt werden bzw die Instruktionen einfacher sind. (Verstehe ich allerdings nicht so ganz).


    Needless to say, the same code compiled in ARM will always be (far) smaller because the ARM machine code is a RISC platform code. It has a smaller subset of machine code instructions too, that result in a smaller code.

    https://unix.stackexchange.com/questions/254418/difference-between-size-of-binaries-x86-64-vs-arm#254434

  7. Re: RAM

    Autor: Crass Spektakel 17.01.21 - 11:51

    Gamma Ray Burst schrieb:
    --------------------------------------------------------------------------------
    > Der ARM Code für den Linux Kernel ist wohl kleiner als der Code für x86.

    Das liegt schlicht daran daß in einem ARM-Linux-Kernel massiv weniger Funktionalität als in einem x86-Kernel steckt. Unterstützt Dein ARM-Kernel eine TC2-TV-Karte? Nope. Kommt sie mit RT-fähigen DSP-Erweiterungen zurecht? Nope. Aber wen juckt das? Das sind alles Module die nur zur Laufzeit geladen werden.

    Nimm VLC, Firefox, Libreoffice, das ist als Linux-ARM-Binary mehr als 50% grösser als das Linux-x86-Binary. In der MacOS-M1-Version sogar noch grösser weil hier Kompatibilitätsbibliotheken statisch eingelinkt werden.

    Übrigen, der m68-Kernel meines Amigas ist sogar nur 400k groß. Der kann zwar nur Textmodus und Ethernet und kann nichteinmal Module laden aber hey, wäre ja kein Vergleich wenn es nicht hinkt.

    > Argument ist, dass die Binaries für ARM (RISC, R wie reduced) kleiner sind
    > weil weniger Instruktionen benötigt werden bzw die Instruktionen einfacher
    > sind. (Verstehe ich allerdings nicht so ganz).

    Du verwechselst RISC und CISC und zwar komplett. RISC kennt wenige Operationen und braucht daher mehr Befehle um das gleiche zu erreichen als CISC.

    > Needless to say, the same code compiled in ARM will always be (far) smaller
    > because the ARM machine code is a RISC platform code. It has a smaller
    > subset of machine code instructions too, that result in a smaller code.
    > “
    > unix.stackexchange.com#254434

    Der Mann ist ein bekannter Troll oder ein Idiot. Kann man nicht beschönigen. Lies Dir mal seine anderen Beiträge durch, mein persönlicher Favorit: "Why does True and False take up so much memory?". Seinen älteren Beiträge zum Thema "Repartitionieren von /dev/null" sind auch lesenswert. Das hätte der seelige Ludwig Catta nicht besser trollen können..



    1 mal bearbeitet, zuletzt am 17.01.21 12:45 durch sfe (Golem.de).

  8. Re: RAM

    Autor: dh99 17.01.21 - 11:59

    Ok, danke fuer die Ausfuehrungen!

  9. Re: RAM

    Autor: Crass Spektakel 17.01.21 - 12:08

    Achja, einen Nachtrag noch, die Executable-Komprimierung von MacOS verschleiert das ein wenig. Wenn man das gleiche Linux-x86/Linux-arm Binary mit xz komprimiert sind sie anschliessend fast gleichgroß denn komprimieren lassen sich ARM-Binaries hervorragend. Sind ja genügend Nullen drin. Im RAM liegt es aber natürlich nicht komprimiert und dann haben wir wieder das genannte Schlamassel.

    Das gleiche gilt für Debugging-Infos, die sind oft zigfach grösser als das eigentliche Binary, ich gehe daher beim Vergleich davon aus daß die gestrippt wurden.



    1 mal bearbeitet, zuletzt am 17.01.21 12:09 durch Crass Spektakel.

  10. Re: ARM=Lahm

    Autor: luuukas 17.01.21 - 12:23

    Crass Spektakel schrieb:
    --------------------------------------------------------------------------------
    > Bei ARM besteht ein Opcode grundsätzlich immer aus einem 32Bit-Befehl sowie gegebenenfalls
    > Paramter die ebenfalls 32Bit groß sind.

    Erik Engheim schrieb:
    --------------------------------------------------------------------------------
    > Die größten und fiesesten Mikroprozessoren von Intel und AMD haben insgesamt vier Decoder, die damit beschäftigt sind, Maschinencode-Befehle in Mikro-Ops zu zerschneiden. Aber das ist kein Vergleich zum M1, der eine absolut unerhörte Anzahl von Decodern hat: Acht. Deutlich mehr als jeder andere in der Branche. Das bedeutet, dass er den Befehlspuffer viel schneller füllen kann.
    > Um damit umzugehen, hat der M1 auch einen Befehlspuffer, der 3x so groß ist, wie es in der Industrie üblich ist.

    > Warum können Intel und AMD nicht mehr Befehlsdecoder hinzufügen?
    > Hier sehen wir endlich die Rache von RISC und die Tatsache, dass der M1 Firestorm-Kern eine ARM RISC-Architektur hat, beginnt zu zählen.
    > Eine x86-Anweisung kann zwischen 1 und 15 Bytes lang sein. RISC-Befehle haben eine feste Länge. Jede ARM-Anweisung ist 4 Byte lang. Warum ist das in diesem Fall relevant?
    > Weil es trivial ist, einen Bytestrom in Anweisungen aufzuteilen, die in acht verschiedene Decoder parallel eingespeist werden, wenn jede Anweisung die gleiche Länge hat.

    Übersetzt aus dem Artikel von Medium why-is-apples-m1-chip-so-fast-3262b158cba2 (Darf kein Link Posten)

    Das klingt danach das der dickeren Code nicht zwangsweise so ein Flaschenhals ist.

  11. Re: ARM=Lahm

    Autor: randfee 17.01.21 - 12:54

    Crass Spektakel schrieb:
    --------------------------------------------------------------------------------
    > Apple hat das simpel und brutal gelöst und einfach sehr schnelles und
    > teures Spezial-RAM direkt auf den Träger gebondet. Von der Leistung her
    > entspricht das RAM einer konventionellen Lösung mit 256Bit und 8ns. Das ist
    > sauschnell, selbst ein Overclocker-Threadripper kommt da kaum ran.
    und genau das ist doch auch legitim und gut. Bin sau froh, dass sie den Weg gehen, der PC Markt wird nachziehen müssen.

    > Das begrenz natürlich die Aufwuchsfähigkeiten. Eine Apple-CPU mit
    > 64-Kernen und 256GByte RAM bräuchte dann einen 1024Bit-Bus mit 5ns. Dazu
    > müßte Apple 64 RAM-Dies direkt neben die CPU bonden. Das geht nicht.
    das hatte ich mich auch schon gefragt, ich kann mir aber vorstellen, dass Apple entweder viel breiteren Custom RAM "entwickelt" bzw. in Auftrag gibt oder wie du selber sagst (mindestens) sehr schnellen Level4 maximal ausbaut. Ich denke wir haben im PC-Markt auch zuerst jetzt bei AMDs "Smart Access Memory" gesehen, wohin die Reise geht. Die ganze IO Kette muss breiter/schneller und mit weniger overhead bedacht werden!

  12. Re: SRAM # DRAM

    Autor: ms (Golem.de) 17.01.21 - 13:13

    Lustig, bei *Samsung HBSM* findet man direkt deine Posts bei uns und Heise ^^ ich vermute beim M1X wird weiterhin LPDDR4X oder LPDDR5 an 128 Bit verwendet.

    Marc Sauter, Sr Editor
    Golem.de



    2 mal bearbeitet, zuletzt am 17.01.21 14:01 durch ms (Golem.de).

  13. Re: ARM=Lahm

    Autor: nm4711 17.01.21 - 15:01

    luuukas schrieb:
    --------------------------------------------------------------------------------
    > Das klingt danach das der dickeren Code nicht zwangsweise so ein
    > Flaschenhals ist.

    +1

    Die dynamische Länge der Befehle scheint in Zeiten von Superkalarität und Out-of-Order Instructions eher ein Problem zu sein, wie man schön in dem Artikel lesen kann.

  14. Re: RAM

    Autor: Myxin 17.01.21 - 20:48

    Stimme dir in allen Punkten zu und es macht aus Spaß deine schönen Erklärungen zu folgen, nur eins sollten wir korrigieren: Apple hat mit dem M1 kein High-End Produkt vorgestellt, weder behauptet, noch so beworben. Die kommen wohl erst noch. :-)

  15. Re: SRAM # DRAM

    Autor: harald.1080 18.01.21 - 20:41

    Ein Trick von Apple ist anscheinend, den Arbeitsspeicher in schmalen Kanälen anzusprechen, also 8 Kanäle à 16 Bit. Siehe „The 2020 Mac Mini Unleashed: Putting Apple Silicon M1 To The Test“ von Anandtech. Beim M1 ist es LPDDR4X

    Mit DDR5 kommt auch eine Möglichkeit, breite Kanäle zu splitten, also 32-bittig anzusprechen. Das kommt dem Multithreading entgegen.

    Die mitgelieferten binaries in Big Sur sind auf der Arm-Seite etwas kleiner als die Intel-Versionen der gleichen Apps. Ob‘s an der Kompression liegt oder nicht — egal, die Binaries sind im Vergleich zum Rest sowieso winzig (MS Teams braucht mit der Electron-Umgebung bei mir 1GB).

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Carl Roth GmbH + Co. KG, Karlsruhe
  2. ALDI International Services GmbH & Co. oHG, Mülheim an der Ruhr, Duisburg, Düsseldorf, Dortmund
  3. Method Park Holding AG, Erlangen
  4. HYPE Softwaretechnik GmbH, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Code Vein - Deluxe Edition für 23,99€, Railway Empire - Complete Collection für 23...
  2. (u. a. Phoenix Point: Year One Edition für 24,99€, Project Cars 3 für 19,99€, Project Cars 2...


Haben wir etwas übersehen?

E-Mail an news@golem.de