1. Foren
  2. Kommentare
  3. Sonstiges
  4. Alle Kommentare zum Artikel
  5. › Mac Mini mit M1-CPU: Apple baut das…

vor allem wegen ihrer Effizienz???

Über PC-Games lässt sich am besten ohne nerviges Gedöns oder Flamewar labern! Dafür gibt's den Freiraum!
  1. Thema

Neues Thema Ansicht wechseln


  1. vor allem wegen ihrer Effizienz???

    Autor: schnedan 25.02.21 - 13:06

    OK, alle Journalisten wiederholen diesen Blödsinn,

    Aber außer einem etwas einfacheren Befehlsdecoder hat ein ARM keinen Vorteil gegenüber einem X86.

    Mal bitte den Nachweis bringen das ein ARM bei gleichem Workload mehr Instructions / MHz schafft und dabei gleich oder weniger Energie benötigt. Und bitte nur Chips mit der gleichen Fertigungstechnikm gleichem RAM Interface gleich großen Caches, etc.. vergleichen.

    95% dessen was den M1 "besser" macht, hat nix mit den ARM Kernen direkt zu tun, könnte von einem X86iger genau so implementiert werden, aber dann wären die Chips wahrscheinlich teurer!

  2. Re: vor allem wegen ihrer Effizienz???

    Autor: nate 25.02.21 - 13:28

    Ich glaube, der Begriff "Effizienz" bezog sich auf die existierenden *Chips* mit Arm-ISA (und speziell den M1), nicht auf die ISA selbst.

  3. Re: vor allem wegen ihrer Effizienz???

    Autor: chrisku 25.02.21 - 13:51

    Wieso denn gleich so aggressiv? Intel Aktionär, oder was?

    Wenn der M1 unter Volllast nen Stromverbrauch von 30W hat und ein gleich schneller AMD oder Intel 120W verbrauchen, dann spricht das schon deutlich für die Effizienz.

    Übrigens, ein ARM Prozessor kann mit einem Clock Cycle etwa zweimal so viele Instruktionen abarbeiten wie x86.

  4. Re: vor allem wegen ihrer Effizienz???

    Autor: nate 25.02.21 - 14:57

    > Übrigens, ein ARM Prozessor kann mit einem Clock Cycle etwa zweimal so
    > viele Instruktionen abarbeiten wie x86.

    Was ist denn das für eine Quatschaussage? Die Breite des Backends hat mit der ISA rein gar nichts zu tun.

  5. Re: vor allem wegen ihrer Effizienz???

    Autor: unbuntu 25.02.21 - 15:17

    chrisku schrieb:
    --------------------------------------------------------------------------------
    > Wenn der M1 unter Volllast nen Stromverbrauch von 30W hat und ein gleich
    > schneller AMD oder Intel 120W verbrauchen, dann spricht das schon deutlich
    > für die Effizienz.

    Ja, der kommt aber eben nicht durch baugleiche Teile, sondern eine komplett andere Fertigung. Aber wer nur auf absolute Werte guckt, für den ist das halt effizienter.

    "Linux ist das beste Betriebssystem, das ich jemals gesehen habe." - Albert Einstein

  6. Re: vor allem wegen ihrer Effizienz???

    Autor: nate 25.02.21 - 15:36

    > Ja, der kommt aber eben nicht durch baugleiche Teile, sondern eine komplett
    > andere Fertigung. Aber wer nur auf absolute Werte guckt, für den ist das
    > halt effizienter.

    Ja, natürlich schaut man auf absolute Werte, denn nur die spielen eine Rolle. Mit welchem Halbleiterprozess ein Chip hergestellt wurde, ist doch völlig egal.

    Und ja: Durchaus möglich, dass die höhere Effizienz ausschließlich auf den neueren 5nm-Node zurückzuführen ist (auch wenn ich persönlich es bezweifle) und dass AMDs zukünftige CPUs dementsprechend dann gut mithalten können. Selbst dann muss man aber sagen: M1 ist heute(!) die effizienteste Notebook-CPU am Markt, Punkt.

  7. Re: vor allem wegen ihrer Effizienz???

    Autor: wasdeeh 25.02.21 - 15:50

    nate schrieb:
    --------------------------------------------------------------------------------

    > Und ja: Durchaus möglich, dass die höhere Effizienz ausschließlich auf den
    > neueren 5nm-Node zurückzuführen ist (auch wenn ich persönlich es bezweifle)
    > und dass AMDs zukünftige CPUs dementsprechend dann gut mithalten können.

    Der Node ist garantiert nicht der einzige Grund, Apple hat da schlicht eine verdammt gute CPU gebaut, die noch dazu mit beeindruckender Konsequenz auf den Anwendungsfall optimiert ist.

    ich trau mich wetten, dass die restlichen versammelten CPU-Hersteller (v.a. aber die ARM-Leute, da denen ein allfälliger "ISA-Schild" völlig fehlen würde) aktuell *sehr* froh sind, dass Apple ihre CPUs nicht an andere verkauft...

  8. Re: vor allem wegen ihrer Effizienz???

    Autor: schnedan 25.02.21 - 17:35

    "Der Node ist garantiert nicht der einzige Grund, Apple hat da schlicht eine verdammt gute CPU gebaut, die noch dazu mit beeindruckender Konsequenz auf den Anwendungsfall optimiert ist. "

    Stimmt ja auch.
    * die RAM Anbindung ist wohl sehr performant (dafür aber auch vom Ausbau her sehr eingeschränkt)
    * große und sehr effiziente Caches (OK, hier hilft die 5nm Node sicher noch zusätzlich, außerdem wundert es das Intel vor Jahren die Caches mal verkleinert hat weil man im Durchschnitt nicht mehr nutzt, aber der M1 profitiert von seinen großen Caches wohl sehr... hier muss man ggf. Umdenken [Zen3 hat ja wohl auch schon größere Caches...])
    * die 5nm Node scheint generell sehr gelungen zu sein, da wenn man sich die Werte so ansieht auch die Leckströme im Leerlauf gut sein müssen.
    * die Zusatzpheripherien außerhalb der CPU scheinen auch sehr gut Zu sein... Video-Codecs, GPU,...
    * ein weiterer großer Faktor ist der kleinere und effiziente Befehlsdekoder - davon hat der M1 mehr als jede X86iger CPU was dazu führt das er intern besser parallelisieren kann. --> das kann X86ig tatsächlich schwer kopieren da der Aufwand hier sehr hoch ist das technisch in den Griff zu bekommen. Langfristig wird man beim X86iger wohl wieder eine Befehlssatzerweiterung machen müssen - so das man einen schlanken, orthogonalen Befehlssatz hat, der ebenfalls wie die ARM-ISA einfacher zu dekodieren ist - Man wird also im Normalfall den effizienten neuen ISA nutzen, und für legacy Programme in den alten Modus schalten - so stelle ich es mir zumindest vor.

  9. Re: vor allem wegen ihrer Effizienz???

    Autor: violator 25.02.21 - 18:57

    nate schrieb:
    --------------------------------------------------------------------------------
    > Ja, natürlich schaut man auf absolute Werte, denn nur die spielen eine
    > Rolle. Mit welchem Halbleiterprozess ein Chip hergestellt wurde, ist doch
    > völlig egal

    Aber nicht wenns um nen Technologievergleich geht. Zwei verschiedene Techniken lassen sich eben nicht richtig vergleichen, wenn beide auch noch unterschiedlich hergestellt wurden.

  10. Re: vor allem wegen ihrer Effizienz???

    Autor: knabba 25.02.21 - 20:11

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > OK, alle Journalisten wiederholen diesen Blödsinn,
    >
    > Aber außer einem etwas einfacheren Befehlsdecoder hat ein ARM keinen
    > Vorteil gegenüber einem X86.
    >
    > Mal bitte den Nachweis bringen das ein ARM bei gleichem Workload mehr
    > Instructions / MHz schafft und dabei gleich oder weniger Energie benötigt.
    > Und bitte nur Chips mit der gleichen Fertigungstechnikm gleichem RAM
    > Interface gleich großen Caches, etc.. vergleichen.
    >
    > 95% dessen was den M1 "besser" macht, hat nix mit den ARM Kernen direkt zu
    > tun, könnte von einem X86iger genau so implementiert werden, aber dann
    > wären die Chips wahrscheinlich teurer!
    Einfach die Akkulaufzeit vergleichen. Das ist Fakt. Ich habe nie ein Apple Produkt besessen aber ein Air mit der Laufzeit würde ich in Betracht ziehen.

  11. Re: vor allem wegen ihrer Effizienz???

    Autor: nm4711 25.02.21 - 20:33

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > * ein weiterer großer Faktor ist der kleinere und effiziente Befehlsdekoder
    > - davon hat der M1 mehr als jede X86iger CPU was dazu führt das er intern
    > besser parallelisieren kann. --> das kann X86ig tatsächlich schwer kopieren
    > da der Aufwand hier sehr hoch ist das technisch in den Griff zu bekommen.
    Und genau das ist doch der Punkt. Wenn deswegen bei gleichem Takt mehr Befehle ausgeführt werden können, ist es im Umkehrschluss möglich die CPU bei gleicher Performance (deutlich, 30 %) niedriger zu takten und dadurch Energie zu sparen.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Langfristig wird man beim X86iger wohl wieder eine Befehlssatzerweiterung
    > machen müssen - so das man einen schlanken, orthogonalen Befehlssatz hat,
    > der ebenfalls wie die ARM-ISA einfacher zu dekodieren ist - Man wird also
    > im Normalfall den effizienten neuen ISA nutzen, und für legacy Programme in
    > den alten Modus schalten - so stelle ich es mir zumindest vor.
    Du sagst also, dass das, was die x86 Befehlssatzarchitektur ausmacht, nämlich Befehle mit unterschiedlichen Längen (CISC, bei x86 1-15 Byte) langfristig gesehen Mist ist. Deswegen soll eine mit ARM vergleichbare Befehlssatzarchitektur entwickelt, bei der die Befehle alle gleichlang (RISC, bei ARM 4 Byte) sind. Und was spricht jetzt dagegen einfach eine vorhandene RISC Befehlssatzarchitektur (z.B. ARMv8 oder RISC-V) zu verwenden und den Legacy Teil zu emulieren?



    4 mal bearbeitet, zuletzt am 25.02.21 20:36 durch nm4711.

  12. Re: vor allem wegen ihrer Effizienz???

    Autor: schnedan 25.02.21 - 22:00

    Das mit den Befehlsdekodern bringt sicher 3,4 vielleicht sogar 5%, aber keine 30% Irgendwo in einem der Artikel bei heise oder golem wurden die Zahlen sogar recht genau beziffert.

    und hinter dem Befehlsdekoder arbeitet ja auch ein X86 heute schon nicht mehr mit dem CISC Befehlssatz und ist eine RISC Maschine. Was läge also näher als auch einen RISC Pfad vor den Befehlsdecodern zu ermöglichen?

    "Und was spricht jetzt dagegen einfach eine vorhandene RISC Befehlssatzarchitektur (z.B. ARMv8 oder RISC-V) zu verwenden"
    Keine Ahnung wie gut bez. max. Effizienz ein RISC-V ist, bez. Lizenzkosten und Erweiterbarkeit wäre das klar mein Favorit. Natürlich würde es Sinn machen schon was existierendes zu nehmen.

    War mal vor 10-15 Jahren n Interview mit dem damaligen ARM CEO. Der meinte ein ARM mit X86iger Decoder in HW wäre kein Problem, würde weniger als 5% mehr Gatter aus machen. Natürlich ginge so was.

    Von solchen SW Emulationen halte ich nichts. Ich möchte X86ig zu 100% erhalten - sei es wg. alter SW aus meinen Studienzeiten oder alten Spielen. Die laufen teilweise selbst auf modernen X86igern nur zu 99%. Wenn Konzepte aus der ARM Welt zu mehr Performance führen schön. Aber Für mich zählt Kompatibilität mehr. Und wie gesagt, wenn man die rein konzeptionellen Vorteile nimmt sind diese da aber es ist nicht so das ein X86 deswegen schlecht wäre - technisch wäre das wohl sogar möglich diese Nachteile mit mehr Silizumfläche zu lösen. Es ist halt nicht wirtschaftlich.

    Man muss auch immer bedenken: das was Apple beim M1 macht ist auch teuer: bester Prozess und viel Siliziumfläche (z.B. für große Caches). Da Apple aber nicht den Chip einzeln verkauft, können die hier ggf. freier agieren als AMD und Intel

  13. Re: vor allem wegen ihrer Effizienz???

    Autor: schnedan 25.02.21 - 22:10

    Ja, wer den Use Case hat super mobil zu sein... OK.

    Meine Akkus sind schon immer am Netz kaputt gegangen.

    Rein aus meiner Erfahrung in der Firma muss ich sagen: 90% aller neuen SW bei uns kommt als hippe Webapp aus der Cloud. Wenn ich mit Word ohne Kabel da sitze: da zuckt der Akku auch nach 2-3 Stunden noch nicht. Aber bei den tollen Webapps ziehen die Javascript Teile so am Akku, dem kannst Minütlich beim sinken zu sehen.
    Also so viel schneller besser können die Prozessoren gar nicht werden wie schlechte SW diese Performancegewinne wieder auffrisst! Wenn man wirklich die Geräte für die Menschen besser machen will, würde es viel bringen mehr in gute SW statt gute HW zu investieren.

    Ist sicher nicht verallgemeinerbar, aber ich habe ein kleines Programm wo ich den gleichen Algorithmus mit verschiedenen Methoden implementiere. Mal so pauschal gesagt hat alleine der Sprung von GCC9 auf GCC10 bei 40% der Implementierungen 5-10% gebracht. In einem Spezialfall hat der sogar 90% geschafft! Auch auf meinem 10 Jahre alten Notebook!

    Auch hier: bevor man bei der CPU 5% rausquetscht: wahrscheinlich könnte man das gleiche auch mit besseren Compilern holen.

  14. Re: vor allem wegen ihrer Effizienz???

    Autor: nm4711 25.02.21 - 23:24

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Das mit den Befehlsdekodern bringt sicher 3,4 vielleicht sogar 5%, aber
    > keine 30% Irgendwo in einem der Artikel bei heise oder golem wurden die
    > Zahlen sogar recht genau beziffert.
    Sieht man doch an den Benchmarks. Bei gleichem Takt erreicht der M1 30 % mehr Performance als ein Zen3, weil er mehr Befehle auf einmal dekodieren kann, da er acht Dekoder pro Kern hat und nicht nur ~4. Das lässt sich mit der x86 Befehlssatzarchitektur schwer bis garnicht umsetzen, da die Befehle unterschiedlich lang sind. Die Komplexität der einzelnen Decoder ist hier nicht unbedingt das Problem. Mehrere Decoder gleichzeitig zu beschicken ist mit unterschiedlich langen Befehlen das schwierige, da der Prozessor nie wissen kann, wo der nächste Befehl anfängt.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > und hinter dem Befehlsdekoder arbeitet ja auch ein X86 heute schon nicht
    > mehr mit dem CISC Befehlssatz und ist eine RISC Maschine. Was läge also
    > näher als auch einen RISC Pfad vor den Befehlsdecodern zu ermöglichen?
    Richtig erkannt, Mikroarchitektur (intern, z.B. Skylake, Zen3, Firestorm, Cortex) und Befehlssatzarchitektur (extern, z.B. ARM, x86, RISC-V) haben bei einem modernen Prozessor nicht viel miteinander zu tun. Aber es wird ja auch nicht behauptet, dass AMD oder Intel keine vernünftige Mikroarchitektur entwickeln können, sondern dass durch die Nachteile der x86 CISC Befehlssatzarchitektur die internen Mikroarchitektur nicht so breit (wide) ausgeführt werden kann. Die interne Mikroarchitektur mit einer RISC Befehlssatzarchitektur (z.B. ARM oder RISC-V) zu beschicken wäre logisch. Aber solange der Prozessor noch x86 (CISC) Befehle verstehen soll, wird das nichts bringen, da er dann ein CISC Prozessor und kein RISC Prozessor ist und dieselben Probleme wie vorher hat.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > "Und was spricht jetzt dagegen einfach eine vorhandene RISC
    > Befehlssatzarchitektur (z.B. ARMv8 oder RISC-V) zu verwenden"
    > Keine Ahnung wie gut bez. max. Effizienz ein RISC-V ist, bez. Lizenzkosten
    > und Erweiterbarkeit wäre das klar mein Favorit. Natürlich würde es Sinn
    > machen schon was existierendes zu nehmen.
    Genau, nur der parallele support für x86 Befehle ist eine doofe Idee, weil das ganze dann wahrscheinlich nicht mehr viel bringt.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > War mal vor 10-15 Jahren n Interview mit dem damaligen ARM CEO. Der meinte
    > ein ARM mit X86iger Decoder in HW wäre kein Problem, würde weniger als 5%
    > mehr Gatter aus machen. Natürlich ginge so was.
    Das ist ein Widerspruch in sich. Dann wäre es ein x86 Prozessor und kein ARM Prozessor mehr. ARM oder x86 sagt nur aus, was für Befehle der Prozessor versteht und nichts über die Mikroarchitektur, die von den Decodern beschickt wird. Gemeint war sicherlich eine Mikroarchitektur, die normalerweise mit ARM Decodern verwendet wird, mit x86 Decodern zu verwenden.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Von solchen SW Emulationen halte ich nichts. Ich möchte X86ig zu 100%
    > erhalten - sei es wg. alter SW aus meinen Studienzeiten oder alten Spielen.
    > Die laufen teilweise selbst auf modernen X86igern nur zu 99%. Wenn Konzepte
    > aus der ARM Welt zu mehr Performance führen schön. Aber Für mich zählt
    > Kompatibilität mehr. Und wie gesagt, wenn man die rein konzeptionellen
    > Vorteile nimmt sind diese da aber es ist nicht so das ein X86 deswegen
    > schlecht wäre - technisch wäre das wohl sogar möglich diese Nachteile mit
    > mehr Silizumfläche zu lösen. Es ist halt nicht wirtschaftlich.
    Warum nicht, wenn es gut funktioniert und schnell läuft ist das doch in Ordnung. Eine Möglichkeit ist zum Beispiel den Code vor den ersten Start automatisiert von x86 zu ARM zu kompilieren.
    Dann wirst du auch CISC zu 100 % erhalten und musst mit den konzeptionellen Problemen von davon leben. Noch sind die absoluten Vorteile noch nicht so stark zu sehen, vorallem in der maximalen Performance. Ich bin aber neugierig, wie das in ein paar Jahren aussieht.
    Mich würde interessieren, wie viel mehr Silizium dafür benötigt werden würde.



    1 mal bearbeitet, zuletzt am 25.02.21 23:37 durch nm4711.

  15. Re: vor allem wegen ihrer Effizienz???

    Autor: schnedan 26.02.21 - 00:10

    "Sieht man doch an den Benchmarks. Bei gleichem Takt erreicht der M1 30 % mehr Performance als ein Zen3, weil er mehr Befehle auf einmal dekodieren kann"

    Nein, wie ich und andere hier schon mehrfach geschrieben haben sind die einfacheren Befehlsdekoder nur ein Bruchteil der Mehrperformance die der M1 hat.

    Einen Teil gewinnt er dadurch das er MEHR davon hat, das er MEHR Cache hat und das RAM Interface durch on Chip Anbindung SHER effizient ist.

    Und natürlich durchgehend 5nm gegen die Mischung von AMD 7nm/12nm

    Der eigentliche Anteil der Dekoder an den 30% Performance Plus sind halt nur irgendwas um die 3-5% und nicht 100%

    Und wenn man all diese technologischen Vorteile auch in einen X86iger reinbaut würde der Vorteil des M1 halt auf diese sagen wir 5% zusammenschmelzen.

    Das ist dann der WIRKLICHE Unterschied zw. ARM und X86iger - was aber teilweise je nach Compiler, etc... wieder egalisiert wird, das man ggf. im Alltag kaum einen Unterschied bemerkt.

    Und natürlich würde es Sinn machen auch einen X86iger Dekoder in einen ARM zu bauen, der könnte dann beide Instruction Sets sehr schnell aus führen. Und man weis ja das das Emulieren bestimmter Harwarefeatures des X86 die man für Rückwärtskompatibilität benötigt in SW teils recht aufwendig sind. Was bei Spielen wo es auf Timing an kommt ggf. schwierig ist.

  16. Re: vor allem wegen ihrer Effizienz???

    Autor: nm4711 26.02.21 - 08:15

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Nein, wie ich und andere hier schon mehrfach geschrieben haben sind die
    > einfacheren Befehlsdekoder nur ein Bruchteil der Mehrperformance die der M1
    > hat.
    Nochmal, es geht mir nicht darum, dass die Decoder einfacher sind, sondern dass man vergleichsweise einfach mehr Decoder pro Kern (8 beim M1 vs. 4 bei Zen3) verbauen kann, die dafür sorgen, dass mehr Befehle pro Takt ausgeführt werden können. Und das liegt an der RISC Befehlssatzarchitektur.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Einen Teil gewinnt er dadurch das er MEHR davon hat, das er MEHR Cache hat
    > und das RAM Interface durch on Chip Anbindung SHER effizient ist.
    >
    > Und natürlich durchgehend 5nm gegen die Mischung von AMD 7nm/12nm
    Das MEHR an Cache bringt dir nicht viel, solange du nicht auch mehr Befehle pro Takt verarbeiten kannst. Sieht man auch an Intels Mikroarchitekturen: Intel hat bei Sandy Bridge (32 nm) genauso viel Cache (L1, L2) verbaut, wie bei Cannon-Lake (10 nm). Erst mit Ice/Tiger Lake (10 nm) ist es mehr geworden. Einfach mehr Cache zu nehmen scheint hier nicht die Lösung zu sein.

    Die Strukturbreite beeinflusst aber nicht direkt die Performance pro Takt. Grund dafür ist die Mikroarchitektur (die natürlich in gewissen Grenzen breiter ausgeführt werden kann, wenn mehr Transistoren zur Verfügung stehen). Aber auch der A13 mit 7 nm hat schon eine höhere Performance pro Takt als ein Zen3.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Der eigentliche Anteil der Dekoder an den 30% Performance Plus sind halt
    > nur irgendwas um die 3-5% und nicht 100%
    Das halte ich für falsch. Wenn die Mikroarchitektur nicht ausreichend ausgelastet werden kann, da die Decoder zu langsam sind, bringt es nichts wenn sie schnell ist. Auch der Cache muss genutzt werden, was nur geschieht, wenn die Befehle schnell genug verarbeitet werden können. Wir können uns also darauf einigen, dass das ein ohne das andere nichts bringt. Blöd ist halt, wenn man die Decoder nicht mehr oder nur mit sehr großem Aufwand schneller machen kann.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Und wenn man all diese technologischen Vorteile auch in einen X86iger
    > reinbaut würde der Vorteil des M1 halt auf diese sagen wir 5%
    > zusammenschmelzen.
    Das funktioniert halt nicht oder nur sehr schwer, da der x86 Befehlssatz der begrenzende Faktor ist.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Das ist dann der WIRKLICHE Unterschied zw. ARM und X86iger - was aber
    > teilweise je nach Compiler, etc... wieder egalisiert wird, das man ggf. im
    > Alltag kaum einen Unterschied bemerkt.
    Da bin ich mal gespannt, wie das in ein paar Jahren aussieht.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Und natürlich würde es Sinn machen auch einen X86iger Dekoder in einen ARM
    > zu bauen, der könnte dann beide Instruction Sets sehr schnell aus führen.
    Nö, dann müsste man einen Decoder bauen der CISC Befehle versteht und der ganze Vorteil von RISC wäre nichts mehr Wert und man könnte die RISC Befehle nicht mehr so schnell ausführen.

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Und man weis ja das das Emulieren bestimmter Harwarefeatures des X86 die
    > man für Rückwärtskompatibilität benötigt in SW teils recht aufwendig sind.
    > Was bei Spielen wo es auf Timing an kommt ggf. schwierig ist.
    Das ist auf jedenfall einfacher als einen Prozessor zu bauen, der beide Befehlssätze versteht und einen Vorteil von RISC hat. Sonst gäbe es die Befehlssatzerweiterung sicher schon von Intel oder AMD. Emulatoren von x86 zu ARM gibt es jedenfalls.

    Hier ist der Vorteil einer RISC Befehlssatzarchitektur auch nochmal ausfühlich beschrieben:
    debugger medium com/why-is-apples-m1-chip-so-fast-3262b158cba2

    Und auch das ist interessant zu lesen:
    anandtech com/show/16226/apple-silicon-m1-a14-deep-dive

    (Sorry für die Leerzeichen, ich darf noch keine Links posten.)



    1 mal bearbeitet, zuletzt am 26.02.21 08:16 durch nm4711.

  17. Re: vor allem wegen ihrer Effizienz???

    Autor: wasdeeh 01.03.21 - 13:24

    >Nochmal, es geht mir nicht darum, dass die Decoder einfacher sind, sondern dass man vergleichsweise einfach mehr Decoder pro Kern (8 beim M1 vs. 4 bei Zen3) verbauen kann, die dafür sorgen, dass mehr Befehle pro Takt ausgeführt werden können. Und das liegt an der RISC Befehlssatzarchitektur.

    Jein, nein und nein.

    * Frontend-bottlenecks waren zuletzt bei Bulldozer ein ernsthaftes Problem. (Und das, weil 2 Module aus einem relativ schmalen Frontend bedient wurden...)
    * µop-Cache minimiert den Vorteil der einfacheren decoder weiter
    * Zen3 dispatched aus letzterem ebenfalls 8 instruktionen

  18. Re: vor allem wegen ihrer Effizienz???

    Autor: wasdeeh 01.03.21 - 14:02

    schnedan schrieb:
    --------------------------------------------------------------------------------

    > * ein weiterer großer Faktor ist der kleinere und effiziente Befehlsdekoder
    > - davon hat der M1 mehr als jede X86iger CPU was dazu führt das er intern
    > besser parallelisieren kann. --> das kann X86ig tatsächlich schwer kopieren
    > da der Aufwand hier sehr hoch ist das technisch in den Griff zu bekommen.
    > Langfristig wird man beim X86iger wohl wieder eine Befehlssatzerweiterung
    > machen müssen - so das man einen schlanken, orthogonalen Befehlssatz hat,
    > der ebenfalls wie die ARM-ISA einfacher zu dekodieren ist - Man wird also
    > im Normalfall den effizienten neuen ISA nutzen, und für legacy Programme in
    > den alten Modus schalten - so stelle ich es mir zumindest vor.

    Naja, du schreibst ja selber, dass die Unterschiede in der Praxis schon minimal sind - und seit sich µop caches sehr erfolgreich etabliert haben, rentiert sich so ein Zugang noch weniger:

    Wenn man ohnehin schon selten Decoding-limitiert ist, und man selbst in solchen Fällen überwiegend aus dem Cache dispatchen kann (und das eben z.B. auf Zen auch schon 8-wide), und wenn selbst das fehlschlägt der Verlust im Vergleich zu anderen Cache Misses trotzdem sehr gering ist...naja, wie gesagt: es rentiert sich einfach net. Diminishing Returns in Reinkultur.

  19. 42 vs 45W

    Autor: Crass Spektakel 08.03.21 - 11:30

    Die angebliche Effizienz der 5W-CPU löst sich in Luft auf wenn man direkt vergleicht. Starte prime, hair und pv gleichzeitig und der 5W-M1 braucht 42W.

    Das sind 3W weniger als mein Ryzen 4600 allerdings ist der dann auch 40% schneller. Und die Grafikkarte habe ich da noch garnicht dazugeschalten.

    Ja, das Air braucht weniger Strom. Aber das drosselt unter Last auch auf die Leistung eines Core2 9000 aus dem Jahr 2010.

  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. Rheinpfalz Verlag und Druckerei GmbH & Co. KG, Ludwigshafen am Rhein
  2. über Hays AG, Ulm
  3. ModuleWorks GmbH, Aachen
  4. Der Polizeipräsident in Berlin, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 279,99€ (Vergleichspreis 332,19€)
  2. 599€ inkl. Rabattgutschein (Vergleichspreis 699€)
  3. 99,90€
  4. (u. a. FIFA 21 für 27,99€, Battlefield V für 13,99€, Star Wars Jedi Fallen Order für 24...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme