Hello, Guest the thread was viewed130k times and contains 1379 replies

last post from Retrofan at the

Apple Macs mit ARM-Prozessoren

  • Gemeines Video:




    Und ich bin ja in aktuellen Games und GPUs überhaupt nicht bewandert aber ich finde folgende Benchmark-Spiele-Grafik für einen Onboard-Chip durchaus gut anzugucken (auch wenn Nvidia-Fans jetzt wahrscheinlich lächeln werden):


  • Zu Intels Werbe-Kampagne passt auch folgendes, aktuelles, History-Video:



    Dass Intel so viel Dreck am Stecken hat, war mir auch nicht bewusst. Von Microsoft weiß man das ja – aber das bei Hardware ähnlich unsaubere Methoden gegen Konkurrenten (hier vor allem AMD) angewendet wurden, war mir noch neu. Naja, Intel ist immer noch Marktführer und hat es (noch) in der eigenen Hand, wie ihre Zukunft aussehen wird. Werbespots und Plakate alleine werden nicht reichen.

  • Intel wurde von Apples Desktop-Chips komplett auf dem falschen Fuß erwischt (ganz ungünstiger Zeitpunkt) und da sie wissen, dass sie nicht einfach in ein paar Monaten das Ruder bei der Chipfertigung rumreißen können, versuchen sie ihre Kunden mit Sprüchen bei der Stange zu halten.

    Das stimmt. Und gleichzeitig verstehe ich es nicht. Dass Apple auf ARM geht, stand seit Jahren so gut wie fest. Ab dem A7, dem ersten 64-Bit ARM, wurde es klar. Das war vor 5 Jahren. Mit jeder neuen Apple-ARM-Generation für das iPhone/iPad wurde diese Idee verfestigt. Aus "tun sie das wirklich?" wurde ein "wann tun sie es endlich". Als sie den Switch dann letztes Jahr verkündet haben, hat es niemanden mehr vom Hocker gehauen. Vom Hocker gefallen ist man erst, als der M1 lieferbar war und man gesehen hat, was das Ding, immerhin der langsamste Desktop ARM, den Apple je produzieren wird, so leistet.


    Worauf ich hinaus will: Wie kann Intel am falschen Fuß erwischt werden, bei dieser Vorlaufzeit, bei dieser Offensichtlichkeit, dass es darauf hinausläuft? Bei den Leistungsdaten, die das iPhone 5s (A7) bis iPhone 11 (A11), aufzuweisen hatte, muss ein CPU-Spezialist wie Intel damit rechnen, dass eine Desktop-Variante auf dieser Basis und mit dem mittlerweile erworbenen Know How (die Apple ARM-CPUs sind ja auch um 1-2 Jahre vor den ARM-CPUs von Qualcom), rocken wird. Dass wir, als außenstehende Technik-Interessierte, von der Leistung überrascht werden ist geschenkt. Aber der jahrzehntelange Marktleader mit dieser jahrelangen Vorlaufzeit und den frei zugänglichen "Kostproben" von Apples Fähigkeiten in den iPhones und iPads?


    Anstatt sich auf diesen Zeitpunkt vorzubereiten, gibt es nur Marketing? Das überrascht. Oder es heißt: Intel hat einfach keine Antwort darauf. Und wenn das so ist, dann heißt das nichts Gutes für Intel.

  • Ich denke im Halbleiterbereich sind Produktroadmaps nicht allzu flexibel, weil eher langfristig (immerhin müssen da Fertigungsverfahren umgestellt werden etc.). Wenn Intel sich vorbereitet hat (und das vermute ich eigentlich schon), dann sicher nicht so, dass sie eine passende ARM-Konkurrenz in der Schublade aufbewahren, um mit dem Veröffentlichen bis zum Apple-Umstieg zu warten. Es bleibt ihnen also erst mal gar nichts anderes übrig, als mit einer schnellen Marketingkampagne zu reagieren. Es bleibt für sie zu hoffen, dass ihre Roadmap dann mittelfristig etwas konkurrenzfähiges hergibt, oder sie ein für sie geeignetes Marktsegment anpeilen.

  • Dass wir, als außenstehende Technik-Interessierte, von der Leistung überrascht werden ist geschenkt. Aber der jahrzehntelange Marktleader mit dieser jahrelangen Vorlaufzeit und den frei zugänglichen "Kostproben" von Apples Fähigkeiten in den iPhones und iPads?

    Ich denke, fast alle (inkl. Intel) waren überrascht von der M1-Performance bei der Ausführung von X86-Code. Ich denke, dass das von niemandem so richtig vorhergesehen wurde. Und mit diesem "Trick" kann Apple halt die Zeit sehr komfortabel überbrücken, bis native 3rd-Party-ARM-Apps verfügbar sind. Wenn jemand gehofft hat, bei Apple gäbe es einen "App-Gap" in der Übergangszeit, dann hatte er sich geschnitten. Und ich denke auch, dass Intel vielleicht gehofft hat, dass viele potentielle Kunden vor den neuen Geräten zurückschrecken, weil Windows (X86) darauf nicht mehr läuft – zumindest aktuell nicht. Aber Windows ist für die meisten kein Argument mehr. Zum einen gibt es für macOS sehr viel native Software (vor allem die großen wichtigen Suiten im Business-Bereich (MS, SAP, IBM ...) und Kreativität (Sound, Foto, Video, Text, 3D ...)) und zum anderen benötigen immer mehr Kunden eigentlich nur noch einen schnellen Webbrowser.


    Intel und Microsoft hatten den PC-Markt Jahrzehnte lang perfekt im Griff – aber jetzt verlieren beide (auch noch gleichzeitig) ihre "Zwangsläufigkeit". Microsoft, weil vielen das OS egal geworden ist – und Intel, weil sie es nicht schaffen, ihre eigene Roadmap einzuhalten – und es Alternativen gibt (X86 und andere).


    Ich denke im Halbleiterbereich sind Produktroadmaps nicht allzu flexibel, weil eher langfristig (immerhin müssen da Fertigungsverfahren umgestellt werden etc.).

    Das stimmt – das ist ein Dampfer, den man nicht so schnell wenden kann. Aber was dazu kommt:


    Intel: 10-Nanometer-Prozessoren erst 2019


    Schon vor knapp 3 Jahren erschien dieser Heise-Artikel, der wartende Kunden vertrösten musste. Und der 10nm-Prozess funktioniert auch jetzt, 2021, immer noch nicht in großem Maßstab.



    Der 14nm-Prozess sollte nach dieser Grafik ursprünglich 2017 durch 10nm ersetzt werden. Aus eigener Kraft würde Intel es aber auch dieses Jahr wohl nicht schaffen. Weswegen sie jetzt ja auch TSMC beauftragen wollen, ihre (vor allem wichtigen) Chips zu produzieren. Das könnte Intel zwar kurzfristig "retten" aber man muss sich vorstellen, dass dieser Schritt die einstige Sperrspitze der CPU-Produktion im Innersten durcheinander würfelt. Es ist ja ein großer Unterschied, ob man als Firma bestimmte Sachen "nur" entwickelt aber aber auch selbst produziert (und dafür Know-how angesammelt hat). Wenn man zuvor anders gearbeitet hat, dann rüttelt das auch am Selbstverständnis. AMD oder Apple interessiert sowas nicht, die produzieren ihre Chips nicht selbst, die geben die in Auftrag. Und wenn ein Dienstleister seinen Prozess nicht in den Griff bekommt und ein Konkurrent doch, dann wechseln die einfach. Apple hat ja z.B. anfangs bei Samsung produzieren lassen – und ist dann irgendwann zu TSMC gewechselt.

  • Die x86 Emulation des M1 hat mich wirklich überrascht, und das konnte man auch kaum vorraussehen, weil es ja sowas auf den iDevices nicht gab.

    Aber schon als ich die Geekbench5-Werte des iPhone 12 sah, konnte ich kaum glauben, was da für die single-thread Performance stand.

    Da war schon zu erkennen, dass ein passiv gekühlter Mobile-Chip in dieser Hinsicht mit den neusten Intel Core ix-11xxxx und AMD Ryzen 5xxx mithalten konnte.

    Dinger die TDPs von >100 Watt und aufwändige Kühlsysteme haben.

  • Zahlen zur M1 Performance bei der Textur-Dekompression:

    https://aras-p.info/blog/2021/…-Compression-on-Apple-M1/


    Dass der M1 im Mac Mini nicht mit einem Core i9 als echtem 8 Kerner + Hyperthreading mithalten kann ist ok.


    Was aber wirklich beeindruckt ist, wie nah x64-Code mit Rosetta2 an die native ARM64 Performance kommt.

    Es gilt anscheinend nun für die x64 ISA, was auch für VM-basierte Sprachen mit JIT und AOT-Compilern erreicht wird: der Overhead ist verkraftbar.

    x64 Maschinencode ist auch nur noch ein (seltsamer) "Bytecode".

  • ass der M1 im Mac Mini nicht mit einem Core i9 als echtem 8 Kerner + Hyperthreading mithalten kann ist ok.

    Das denke ich auch. Was mich aber etwas wundert, ist, dass bei dieser speziellen Aufgabe ein einzelner M1-Core nicht an einen einzelnen i9-Core herankommt, obwohl die Single-Core-Performance eigentlich höher (zumindest nicht schlechter) ist. Ich denke, dass hier doch eher eine Kombination aus CPU- und GPU-Cores gemessen wird, oder? Macht bei Textur-Dekompression auch irgendwie Sinn, dass die CPU das nicht (alleine) macht. Und der Intel-Mac hat eine dedizierte Grafikkarte. Der Tester spricht allerdings vor allem von der CPU – kann er ausschließen, dass da die GPU nicht doch mithilft?


    Was aber wirklich beeindruckt ist, wie nah x64-Code mit Rosetta2 an die native ARM64 Performance kommt.

    Ja, das beeindruckt in der Tat. Ich frage mich, ob sich Intel da nicht Sorgen machen muss. Wenn man Nicht-X86-CPUs bauen kann, deren X86-Ausführung so nah an einem nativen Prozessor dran ist – und dabei keine Intel-IP verletzt – dann ist das doch eigentlich ein Riesen-Problem, oder? Das lädt die Konkurrenz doch förmlich dazu ein, einem die Hölle heiß zu machen. Und zehntausende von Patenten, mit denen man sich schützen wollte, werden zu Makulatur.

  • Da geht es um Texturkompression, und die macht auf der GPU wenig Sinn :freude

  • x64 Maschinencode ist auch nur noch ein (seltsamer) "Bytecode".

    Das ist schon seit dem NexGen Nx586, AMD K6 und Intel Pentium Pro so, das sind eigentlich RISC-CPUs, die erstmal x86-Code auf ihre interne Architektur übersetzen.

  • x64 Maschinencode ist auch nur noch ein (seltsamer) "Bytecode".

    Das ist schon seit dem NexGen Nx586, AMD K6 und Intel Pentium Pro so, das sind eigentlich RISC-CPUs, die erstmal x86-Code auf ihre interne Architektur übersetzen.

    Das ist klar. Aber das passiert dynamisch in Hardware, davon sieht das OS nichts (mal abgesehen von Transmete).

    Ausserdem haben die x86 CPU-Hersteller ihre "internen RISC" ISAs sicher dem angepasst, was für x86 am meisten gebraucht wird.

    Auch Probleme mit unterschiedlicher Endianess wird es nicht geben.

    Mit Rosetta passiert es aber als JIT/AOT in Software für eine völlig andere ISA, die nicht mit Hinblick auf optimale x86-Emulation entworfen wurde.


    Wenn man bedenkt, dass Intel selbst es damals beim Itanium nicht geschafft hatte, eine performante x86 "HW-Emulation" umzusetzen, ist das schon cool, wie Rosetta2 performt.

  • https://de.wikipedia.org/wiki/Transmeta


    Kennt die noch jemand? Hab das damals verfolgt, als Linus Torvalds dort gearbeitet hat.

    Ja, konnte damals aber halt auch nicht mit Intel mithalten. Glaube nur der Stromverbrauch war etwas besser als bei den damaligen x86 Mobile CPUs. Aber die Performance dafür eben zu schwach.

  • Da geht es um Texturkompression, und die macht auf der GPU wenig Sinn :freude

    Sorry. Ja es geht darum die Texturen zu komprimieren. Z.B. um Speicher bei der Übertragung für WebGL zu sparen, oder Platz auf dem Trägermedium.

    Da in modernen Spielen riesige Level mit Texturen völlig zugekleistert werden, muss man da was tun.

  • Ich denke, dass hier doch eher eine Kombination aus CPU- und GPU-Cores gemessen wird, oder? Macht bei Textur-Dekompression auch irgendwie Sinn, dass die CPU das nicht (alleine) macht.

    Bei Texturen braucht man auf der GPU wahlfreien Zugriff in konstanter Zeit, daher kommen da fest Blockkompressionen zum Zuge, die auch in Hardware in den Texture-Units implementiert sind.

    Aber die komprimieren nicht so gut, dass sie auch für Netzwerk-Transfer oder Speicherung auf dem Trägermedium gut wären.

    Im dümmsten Fall komprimiert man also z.B. JPEG für Transport/Medium, dekomprimiert dann mit CPU in RAM ( oder auch GPU in VRAM), hat dann aber wieder plain RGB und muss es wieder für die GPU-Kompressionsmethoden rekomprimieren.

    Das ist natürlich ein unsinniges Hin- und Her.

    Daher hätte man gerne starke Komprimierung für Transport/Speicherung, die sich direkt in GPU-komprimierte Texturen entpacken lassen. Im Idealfall auch direkt auf der GPU.


    Das Basis Universal Texture Format ist gerade so ein Versuch von Khronos, da einen Texture Supercompression Standard zu schaffen.

  • Es gab Builds von OSX in denen Verweise auf einen möglichen Umstieg auf AMD CPUs drin waren. Entweder hat Intel zu gut verhandelt, oder es gab sonst irgendwelche Gründe die in der Vergangenheit gegen einen Umstieg zu AMD sprachen. Den Beweis dass Big Sur mit guter Performance auf einem Ryzen5 3600 läuft habe ich in meinem Homerecording Studio stehen.

  • Mit Rosetta passiert es aber als JIT/AOT in Software für eine völlig andere ISA, die nicht mit Hinblick auf optimale x86-Emulation entworfen wurde.

    Wobei Apple in den M1 ein paar kleine Spezialitäten eingebaut hat, um das ganze performanter zu machen. Aber anscheinend so wenig, dass Intel dagegen nichts tun kann, also keine richtige X86-Kompatibilität gegeben ist. Und ich meine, dass dieser "Trick" Intel Sorgen machen müsste. Weil im Prinzip damit jede dahergelaufene Firma mit ARM-Architektur-Lizenz (wie Samsung, Qualcomm und diverse andere) eine CPU bauen könnte, die mit nur geringem Verlust X86-Code ausführen könnte – ohne ein einziges Intel-Patent zu verletzten. Das wäre doch quasi das Horror-Szenario für einen CPU-Entwickler, wie Intel, oder? Milliarden von Dollars in IP stecken und dann nützt das alles nichts.