Notiz Browser für den M1-Prozessor: Auch Chrome und Firefox unterstützen Apple Silicon

Augen1337

Captain
Dabei seit
Apr. 2008
Beiträge
3.477
Was passiert eigentlich, wenn Intel nun mit dem LittleBig Ansatz den neuen Prozessor auf den Markt bringt und vielleicht einen Shrink hinbekommt.

Dann sieht es bestimmt nicht mehr so toll aus wie jetzt. Vor allem wird hier 5nm gegen 14nm(+++++) verglichen. SOLLTE Intel einmal auf 5nm kommen, .. ohje ;-)
 

7H0M45

Lieutenant
Dabei seit
Jan. 2010
Beiträge
603
Das wäre völlig egal. Die Märkte von ARM und x86 kollidieren aktuell kaum.

Die x86 Technik ist nicht wirklich geeignet für Ultrasparsame Chips und bis jetzt ist mir zumindest noch kein Hochleistungs ARM Chip bekannt, welcher es mit der Top Riege der x86 aufnehmen kann.

Ich vermute der Schnittbereich in der Mitte, also die Personal Computer, wird sich aufteilen in Apple=ARM und Linux und Windows beides wobei x86 hier vermutlich deutlichst stärker vertreten bleibt.

Wie das in 10 Jahren aussieht weiß natürlich keiner aber ich würde bis dahin nicht von einem Massiven Umschwung ausgehen.

Wenn Intel aber noch 10 Jahre mit ihrer Fertigung braucht, wird es für die Firma selbst problematisch. Oder sie geben die Eigenfertigung bis dahin komplett auf
 

Termy

Lt. Commander
Dabei seit
Mai 2007
Beiträge
1.517
Zuletzt von einem Moderator bearbeitet: (Komplettzitat entfernt)

N1nuzzo

Lt. Junior Grade
Dabei seit
Okt. 2016
Beiträge
272
nice.Welche DAW benutzt du denn? Auf einen Erfahrungsbericht / kleines Feedback wie der mini so läuft würde ich mich freuen.

Ich nutze Logic Pro X und Tracktion (je nach Anwendungszweck) - kann gerne, wenn der Mac (leider noch 3 Wochen, da BTO / 16GB Variante) da ist einen kleinen Erfahrungsbericht verfassen. Bin auf die Kompatibilität der Plugins gespannt und auch auf die Gesamtauslastung live Einspielen usw!
 

Turrican101

Rear Admiral
Dabei seit
Aug. 2007
Beiträge
5.664
MS hat es bis heute ja noch nicht mal geschafft sich von 32 Bit zu lösen.

MS hat auch einfach viel mehr und andere Kunden. Und die wollen ein System das funktioniert. Und keins, wo irgendwas nicht mehr läuft, weil man alte Zöpfe abgeschnitten hat. Seit Catalina wird z.B. mein Grafiktablet nicht mehr unterstützt, da müsste ich jetzt also viel Geld ausgeben und unnötig mein einwandfrei funktionierendes Gerät gegen was neues tauschen.
 

GrooveXT

Lt. Commander
Dabei seit
Jan. 2007
Beiträge
1.869
Wieso? Windows on ARM gibts doch als alternative.
Intel hat erfolgreich verhindert das AMD über Jahre im Laptop/Desktop Segment Fuß fassen konnte. Noch heute tun sich die Hersteller schwer vernünftige Geräte auf AMD Basis zu bringen. Solange Intel und AMD ihr Exklusivgeschäft in Gefahr sehen wird kein großer Hersteller irgendwas brauchbares auf den Markt werfen. Zu groß die Angst vor Sanktionen. Denn wenn AMD und Intel auf einmal "Lieferschwierigkeiten" haben, dann kann Dell den Laden schließen. Und wie du siehst reicht die bloße Existenz von Windows ARM nicht aus um Software Hersteller dazu zu bewegen umzuschwenken. Warum auch, der Windows Markt ist zu 99,99% x86/x64. Und ohne Software keine Hardware. Irgendeiner muss das Pendel anstoßen.
 

Turrican101

Rear Admiral
Dabei seit
Aug. 2007
Beiträge
5.664

chartmix

Lieutenant
Dabei seit
Aug. 2011
Beiträge
864
Ganz im Gegenteil, der Markt würde sogar viel freier. Schließlich könnte dann so ziemlich jeder seinen eigenen SoC basteln und man wäre nicht nur der Marktmacht von Intel und AMD ausgeliefert.
Aber freier in Sachen Betriebssysteme wird's dann nicht. Eher unfreier.
Linux ohne Treiber geht schlecht. Und am wenigsten bei custom-socs.
 

GrooveXT

Lt. Commander
Dabei seit
Jan. 2007
Beiträge
1.869
Das wäre völlig egal. Die Märkte von ARM und x86 kollidieren aktuell kaum.

Die x86 Technik ist nicht wirklich geeignet für Ultrasparsame Chips und bis jetzt ist mir zumindest noch kein Hochleistungs ARM Chip bekannt, welcher es mit der Top Riege der x86 aufnehmen kann.
Hast du dich mit dem M1 Mal beschäftigt? Die CPU verbraucht gerade Mal 10 Watt und kann in viele Szenarien einem 9900k das Wasser reichen. Was denkst du denn was daraus kommt wenn Apple für ihre grossen Notebooks und iMacs Mal nen SoC mit 40 oder gar 65 Watt raus haut?
Nene, die Differenzierung von stromsparend und Hochleistung stimmte noch von 5 Jahren. Die Zeiten sind aber vorbei.

Aber freier in Sachen Betriebssysteme wird's dann nicht. Eher unfreier.
Linux ohne Treiber geht schlecht. Und am wenigsten bei custom-socs.
Linux für ARM gibt es auch schon. Treiber müssen auch bei x86 Linux vom Hersteller zur Verfügung gestellt werden. Warum sollte das dann bei ARM ein Problem sein?
 

Nixdorf

Captain
Dabei seit
Nov. 2009
Beiträge
3.515
Ein superschneller ARM-Chip hilft nicht viel, wenn für die Software darauf kriechend lahm X86 emuliert werden muss. Daher sind die viel wichtigeren zwei Puzzlestücke hier zum einen die konsequent portierten Bibliotheken, deren Nutzung Apple jahrelang stark forciert hat. Das ermöglicht bei vielen Programmen, schnell eine native Version zu liefern. Und zum anderen ist Rosetta 2 immens wichtig. Wenn man eine Schicht hat, mit der X86-Software bei 50-90% der regulären Geschwindigkeit läuft, dann kann man mit der IPC-Entwicklung in den letzten Jahren bei den Apple-Chips tatsächlich für viele ältere Software zur Not auch auf eine neue, native Version verzichten. Erst alle drei Komponenten zusammen bringen den Erfolg. Dummerweise ist all dies im Walled Garden des Apple-Ökosystems eingesperrt.

Den gleichen Versuch hat Microsoft komplett in allen drei Aspekten vergeigt. Zunächst einmal haben sie ARM-Prozessoren gewählt, die zwar effizient, aber nicht performanter als die X86-Pendants waren. Dann haben sie vorab zu wenig Anstrengungen geleistet, dass man Software "mal eben" auf Windows RT portieren kann. Und sie haben in der ersten Iteration nicht nur kein Pendant zu Rosetta geliefert, sondern nicht einmal eine langsame Emulation. So konnte das nur eine Totgeburt werden.

Geht das denn besser? Klar. Auch andere Firmen entwickeln flotte ARM-Prozessoren. Man braucht also nicht zwingend Apple, um schnelle Chips zu bekommen. AMD hat ja wie Apple eine Architektur-Lizenz für ARM und angeblich ist ihr K12-Projekt auch immer noch nicht gestorben, sondern liegt nur auf Eis. Sobald da ein ernsthafter Markt sichtbar wird, wären wohl viele dabei.

Es scheint zum gegenwärtigen Zeitpunkt allerdings illusorisch, einen Wechsel auf ARM auch bei Windows ins Auge zu fassen, einfach weil Microsoft völlig unfähig zu sein scheint. Die Firma hat es ja seit dem Start von Windows 10 vor mehreren Jahren nicht einmal geschafft, das Modern UI (Metro) konsequent durchzusetzen. Was soll man dann erst vom Rest des Systems erwarten? Ohne den Mut, ebenfalls harte Schnitte zu machen, und alte Programme bestenfalls in einem Legacy-Sandbox-Bereich laufen zu lassen, wird das nie was. Und eine vergleichbare Alternative zu Rosetta 2 ist weit und breit nicht zu sehen. Verdammt schade!
 

KitKat::new()

Lt. Commander
Dabei seit
Okt. 2020
Beiträge
1.031
Und eine vergleichbare Alternative zu Rosetta 2 ist weit und breit nicht zu sehen. Verdammt schade!
Was fehlt denn an der ARM-Emulation von Windows außer, dass Windows erst beim ersten Starten das Programm schrittweise übersetzt und cached statt direkt bei der Installation?

Sobald der x86-64 Emulator final rauskommt (d.h. nicht nur noch für Insider zur Verfügung steht), sehe ich kein Problem mobil auf ARM zu wechseln.
 

Nixdorf

Captain
Dabei seit
Nov. 2009
Beiträge
3.515
Was fehlt denn an der ARM-Emulation von Windows außer, dass Windows erst beim ersten Starten das Programm schrittweise übersetzt und cached statt direkt bei der Installation?
  • Pluspunkt: Immerhin übersetzen sie inzwischen überhaupt, anstatt die Befehle einzeln zu interpretieren.
  • Minuspunkt: Das Übersetzen beim Start verlangsamt eben diesen. Und wenn sie das nicht wegspeichern, dann wird das auch nie besser. Hoffentlich liefert man das nach.
  • Minuspunkt: Die Emulation ist immer noch nicht verfügbar. Der erste Anlauf von Windows RT war vor acht (!!!) Jahren. Bei Apple kam beides zeitgleich raus. So macht man das.
Zur Performance der Emulation kann man noch nichts Genaues sagen. Erste Stimmen sind aber nicht so ermutigend wie bei Apple.

Ergänzung: Und wie gesagt bleibt selbst bei funktionierender Emulation immer noch der Malus der nicht standardisierten Umgebung. Dass jetzt nur wenige Tage nach Launch des M1 sowohl Chrome als auch Firefox schon mit frühen Versionen von nativen Browsern (die komplizierteste Softwaregattung überhaupt) am Start sind, ist mehr als ein kleines Wunder.

Bitte nicht falsch verstehen: Ich will dringend, dass ARM (und am besten auch RISC-V) zu gleichberechtigten Architekturen im Desktop-Markt heranwachsen. So löst man sich mittelfristig endlich von dem ekligen Ungetüm "X86" mit all seinen Legacy-Ineffizienz-Eskapaden. Daher bin ich knatschig, dass ausgerechnet Apple zuerst etwas Brauchbares bringt. Die eine Firma, die niemals nie Lizenzen dafür vergeben wird.
 

KitKat::new()

Lt. Commander
Dabei seit
Okt. 2020
Beiträge
1.031
  • Pluspunkt: Immerhin übersetzen sie inzwischen überhaupt, anstatt die Befehle einzeln zu interpretieren.
Wann haben sie das gemacht?
Wäre mir neu, dass das mal anders war
Minuspunkt: Die Emulation ist immer noch nicht verfügbar. Der erste Anlauf von Windows RT war vor acht (!!!) Jahren. Bei Apple kam beides zeitgleich raus. So macht man das.
Ist sie doch.
Sogar x86-64 in der Insider-Version.
Minuspunkt: Das Übersetzen beim Start verlangsamt eben diesen. Und wenn sie das nicht wegspeichern, dann wird das auch nie besser. Hoffentlich liefert man das nach.
Einmal. Dafür dauert die Installation bei Apple länger.
 

mae

Ensign
Dabei seit
Feb. 2020
Beiträge
139
Man muss sich auch die Frage stellen, wie wichtig es ist, dass ein Browser nativ auf dem Gerät läuft.

"Nativ" ist sogar etwas zu kurz gegriffen: Den Browser neu zu compilieren ist einfach, den JIT-Compiler fuer JavaScript und WebAssembly auf Aarch64 zu retargeten ist schon deutlich mehr Aufwand (wobei das von Android und iOS her schon da sein sollte). Das bringt aber auch einiges, wen diese JIT-Compiler nicht AMD64-Code produzieren, der dann von Rosetta in Aarch64 uebersetzt werden muss, sondern direkt Aarch64 rauskommt.
 
Top