News Browser für den M1-Prozessor: Mozilla Firefox 84.0 unterstützt Apple Silicon nativ

[Cool Master]

Womit wurde FF eigentlich für den M1 kompiliert?

Xcode.

 

[smalM]

Der M1 ist jetzt auch "nur" ein ARM Kern, an der ISA hat Apple hoffentlich nicht rumgeschraubt, daher kannste Dinge normal per GCC und Konsorten für compilen.

Apple hat an der ISA rumgeschraubt.
Das ist aber für Firefox irrelevant, denn diese Erweiterungen sind 'privat', d.h. sie sind für Dritte sowieso nicht direkt, sondern nur über ein Apple-Framework zugänglich.

Ich glaub der M1 hat nicht mehr so viel mit ARM Cortex gemein dass es sich lohnen würde einen generischen ARM-Build zu erzeugen, gegenüber der Ausführung des x86-Code. Dessen Emulation scheint ja sehr performant zu sein.

Muss ja einen Grund haben, warum alle anderen Hersteller mit ihren ARM-Kernen nicht an den M1 ran kommen. Ohne Befehlssatzerweiterung und andere Optimierungen wird man da kaum performanten Code erzeugen. Und das Apple den GCC Developern unter die Arme greift glaub ich erst wenn der Weihnachtsmann aus meinem Schwedenofen kriecht.
Dachte eher das Apple für Developer einen eigenen Compiler bereitstellt.

Der Firestorm-Core ist nicht soviel schneller als die Cortex-Cores, weil da irgendwelche Compilertricks helfen oder spezielle Optimierungen greifen. Er ist so viel schneller, weil er brutal groß ist und es Apple trotz der Größe geschafft hat, daß die CPU ihre Resourcen sehr gut einsetzt.

 

[Yuuri]

Wieso umgehen, wenn es dort gar nicht existiert.

Firefox hat genauso wie "jeder andere" Browser (/Chrome...) die Web Extension API implementiert. Auch die v3 API wird implementiert werden. Die Frage ist, was dann mit der alten API passiert bzw. wie die Limits für die v3 gesetzt werden. Quasi jede populäre Liste übersteigt bereits die 30.000 Filter.


Sonst siehe Link von @foo_1337: https://www.androidpolice.com/2020/...sions-spelling-real-bad-news-for-ad-blockers/

Theoretisch müsste die v2 API auch gar nicht deprecated werden, sondern könnte parallel weiterlaufen. Aber wenn Google v3 forciert und v2 in Chrome sterben lässt, gibts keine Wahl. Wieder ein Punkt gegen das Chrome Monopol. Google setzt seit einiger Zeit alleinig die Standards und nicht mehr das W3C oder sonst wer.

Soweit ich weiß, führt Google das "bald" ein. Hat aber noch ein paar Modifikationen vorgenommen.

Ist bereits mit 88 live gegangen. Canary läuft aktuell auf 89, heißt es läuft aktuell in der Beta und in ein paar Wochen wird es bereits als Stable ausgeliefert. Das Limit der 30.000 wurde AFAIK aber nicht erhöht. Aus "Sicherheitsgründen"...

 

[Piktogramm]

Seit spätestens drei Monaten werden PGO Builds verwendet. Ob und wie AVX u.ä. Instruktionen verwendet werden, weiß ich allerdings nicht... Spätestens bei Drittanbieter-Plugins (Codecs u.ä.) wird aber mit Sicherheit stark optimiert und der Build wird damit wohl nicht mehr "beliebig" sein. Höchsten mit Code als Fallback.

PGO sollte an den verwendeten Befehlserweiterungen nicht viel ändern. Es ändert ja nicht einfach das Target.

Du kannst clang ohne Xcode installieren. Damit du aber die ganzen Header bzw. die SDK für all das GUI Geraffel hast, benötigst du das fully fledged Xcode Paket. Man muss Xcode aber nicht installieren, sondern es reicht das SDK aus dem dmg rauszukopieren:
/path/to/mounted/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
Das sind hier ca 230MB (Big Sur)
Unter linux reicht dir auch nicht allein der compiler, sondern du brauchst mindestens gtk/glib und viele andere header.

Also entweder Compiler und Bibliotheken gebündelt mit XCode oder händiges Gabastel bei dem automatisierte Updates der Abhänigkeit nicht möglich sind/fricklig werden.
Da könnte man so schön trennen.

 

[foo_1337]

@Piktogramm da stimme ich dir absolut zu. Das ist jedes mal ein Gefrickel.

 

[40l0so]

Ich frage mich wieso Firefox auf MacOS optimiert. Die meisten Mac User nutzen doch Safari darauf oder irre ich mich?

Ich nutze eigentlich auch kein Safari, sondern nur FIrefox. Habe die letzten Tage nur notgedrungen Safari genutzt, weil Firefox oft die Seiten nicht aufgebaut hatte !? Wahrscheinlich lag es daran, dass es nicht nativ lief..

 

[Guyinkognito]

Ich frage mich wieso Firefox auf MacOS optimiert. Die meisten Mac User nutzen doch Safari darauf oder irre ich mich?

Ein Haufen Webdesigner die ich kenne nutzen Mac, von daher ist das gar nicht so doof.

 

[uburoi]

Ublock gibt es doch für Safari... Nutze ich doch selbst..

Aber leider nicht uBlock Origin, weshalb ich auch fast ausschließlich Firefox auf dem Mac nutze.

Gruß Jens

 

[LukS]

Die meisten Mac User nutzen doch Safari darauf oder irre ich mich?

Meine Schwester nutzt am MacBook Pro, iMac und auf ihrem Hacintosh nur den Firefox.

 

[Miuwa]

Was nur bedingt stimmt, die besseren Videocodecs, Cryptobibliotheken etc. pp. unterscheiden alle nach Featureleveln der CPUs und gelegentlich kann man Performance Schinden, wenn man spezifisch für die Zielplattform baut (lohnt meist nur für kleine Teile des Codes, wo aber ein Großteil der Rechenzeit verbracht wird)

Natürlich kann man mehr aus einer CPU rausholen, wenn man code spezifisch für diese optimiert. Insbesondere, wenn die CPU neue Instruktionen mit sich bringt oder sich die Laufzeit/ der Durchsatz existierender Befehle drastisch ändert. Aber daraus folgt eben nicht der von @ghecko aufgestellte Umkehrschluss, dass Programme auf dem M1 nur deshalb deutlich performanter/effizienter als auf anderen ARM Prozessoren laufen, weil er spezielle Extensions mitbringt und/oder die Programme speziell für ihn optimiert wurden und es deshalb nichts bringt, den Firefox mit nem normalen GCC für ein generische ARM target zu kompilieren. SIMD gibts ja z.B. bei ARM schon länger, da muss Apple nix neues erfinden.

Ich hab ja nur darauf hingewiesen, dass es auch im x86 Lager deutlich Performance Unterschiede zwischen den Herstellern und CPU generationen gab. Und wenn ich mich richtig erinnere, waren viele Testprogramme (z.B. ältere Spiele, aber auch Anwendungen) mit nichten schon auf die neuen CPUs optimiert wenn diese vorgestellt wurden (sofern die Spiele überhaupt noch nachträglich für neue Architekturen optimiert wurden).

Davon ab siehts aber meines Wissens grundsätzlich so aus, dass gcc schlicht weg Aarch64 Darwin (noch?) nicht unterstützt (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168). Da gehts ja um viel mehr als nur den Beffehlssatz, was evtl. auch die Frage von @Fritzler beantwortet (falls das nicht schon später im Thread beantwortet wurde. Hab mir jetzt nicht alle Posts durchgelesen):

Warum nicht GCC?

 

[chartmix]

Firefox hat genauso wie "jeder andere" Browser (/Chrome...) die Web Extension API implementiert. Auch die v3 API wird implementiert werden. Die Frage ist, was dann mit der alten API passiert bzw. wie die Limits für die v3 gesetzt werden. Quasi jede populäre Liste übersteigt bereits die 30.000 Filter.

Das Limit der 30.000 wurde AFAIK aber nicht erhöht. Aus "Sicherheitsgründen"...

Many developers initially spoke out against the declarativeNetRequest API, saying it was too limited, but Google has been improving it. It now supports more types of wildcard operators, similar to how most content blockers formatted their own lists. However, Google is still keeping a relatively-low cap on the number of rules an extension can have. Extensions can only apply a maximum of 30,000 rules, which sounds like a high number, but EasyList (one of the more common blocklists) alone has over 60,000 rules. Google told 9to5Google that the limit will be raised to 300,000 in Chrome 89, which is better, but still not enough to have more than a few common blocklists activated at once.

Firefox has its own extension API implementation, and as of 2019, has "no immediate plans to remove blocking webRequest."

Nicht böse gemeint, aber hast du dir deine Quelle auch durchgelesen?
Webextension ist nicht standardisiert. Firefox orientiert sich dabei an Chrome. Weicht aber auch davon ab.

 

[Miuwa]

bzgl.: Verwendung von AVX und anderen SIMD Instruktionen in Firefox: Prinzipiell können Compiler diese auch bedingt nutzen. D.h. der Code z.B. für ne Funktion oder auch nur eine Schleife wird zweimal compiliert, einmal mit AVX, einmal ohne und der Code entscheidet dann zur Laufzeit welche Version aufgerufen wird. Ob und von welchen Compilern das in der Praxis so gemacht wird weiß ich nicht.

 

[retireduser]

Zudem unterstützt der Firefox jetzt auch unter macOS den 2D-WebRender auf Basis von Rust.

Sehr gut, hierauf hatte ich schon lange gewartet. Der alte WebRenderer hatte massive Performanceprobleme mit Transparenzen und Hintergründen. Konnte direkt auf einer bestimmten Seite sehen, dass das behoben ist.

 

[hurcos]

Kann denn jemand eine gute Alternative für ublock origin für Safari empfehlen? Oder mir sagen, wie es für Safari installiere?

 

[uburoi]

Kann denn jemand eine gute Alternative für ublock origin für Safari empfehlen? Oder mir sagen, wie es für Safari installiere?

Aufgrund der vor einer Weile geänderten Plug-in-Politik von Apple lässt es sich nach derzeitigem Stand in Safari nicht installieren.
Und ich habe etliche Alternativen ausprobiert, aber keine gleichwertige gefunden. 🤷‍♂️

Gruß Jens

 

[foo_1337]

Der Bugreport zum angeblichen Chrome Problem ist auch nett: https://bugs.chromium.org/p/chromium/issues/detail?id=1158402
Der Autor kann das ganze plötzlich nicht mehr reproduzieren Und die wenigen, bei denen es angeblich geholfen hat, hatten vor dem reboot sehr lange uptimes und andere lustige Dinge.
Ich sag ja: Placebo.

 

[Ravenstein]

Bisher hält mich davon hauptsächlich die Tatsache ab, dass das ding nach wie vor kein Pinch to Zoom kann

Also auf meinem iPad und auf meien android smartphone klappt das problemlos mit firefox

 

[Bart1]

Hier geht es aber nicht um iPads oder Android.

 

[foo_1337]

Jup, es ging natürlich um ffox unter macOS. Aber es geht seit Firefox 83 tatsächlich hab ich eben gesehen
https://www.theverge.com/2020/11/17/21569559/firefox-pinch-to-zoom-support-windows-mac
Und es funktioniert sogar.

 

[ReactivateMe347]

Dir ist aber mittlerweile aufgefallen, dass Apple ARM enorm pusht und alsbald ausschließlich Macs mit ARM existieren werden, oder? Lieber die komplette, zukünftige User Base auf Macs ignorieren? Warum sollte Mozilla nicht gleich dicht machen?

Apple-Nutzer sind zumeist Fanboys, die eh Safari nutzen. Der Rest nutzt Chrome - die Nutzungszahlen von Firefox auf macOS sind selbst gemessen an dem inzwischen erreichten Tiefstand unter Windows gering. Andererseits gibt es Bugzilla-Tickets die seit 5 oder sogar 10 und mehr Jahren offen sind und für die man "nicht die Ressourcen" hat, sich darum zu kümmern. Wegen mehrerer solcher Probleme liebäugele zumindest ich zunehmend mit Alternativen wie Vivaldi - und ich nutze seit 0.7 fast ausschließlich Firefox.