Vroege Nightly's Firefox voor ARM-versie Windows 10 staan online

De eerste Firefox-Nightly voor de ARM-versie van Windows 10 is beschikbaar. Volgens Mozilla is deze Nightly wat onberekenbaarder dan een Nightly normaal al is, maar gewoon browsen moet desalniettemin mogelijk zijn, zoals tests van gebruikers ook uitwijzen.

De Nightly verscheen al op 20 december, maar ging tot nog toe grotendeels onopgemerkt. In de mailing legt ontwikkelaar Nathan Froyd van Mozilla uit dat deze versie niet door de geautomatiseerde tests van Mozilla is gelopen en daarom wat meer problemen kan hebben. Wat dat proces precies inhoudt en waarom deze versie er niet doorheen is gegaan, is niet duidelijk. Geïnteresseerden kunnen de Nightly vinden in het Mozilla-archief, de versie in kwestie wordt aangeduid met aarch64.

Froyd wil de verwachtingen duidelijk in toom houden: "de Gecko profiler werkt niet, de crash reporter ook niet, de JS JIT IonMonkey ook niet, WebRTC staat uit, EME werkt nog niet, ga zo maar door. Had ik al gezegd dat dit een Nightly is?" Het goede nieuws is wel dat deze Nightly gewoon een updater heeft en dat afgelopen zaterdag nog een update is uitgebracht.

Deze variant van de browser maakt gebruik van ARM's 64bit-architectuur en zal per tabblad een aparte processorkern gebruiken om prestaties te optimaliseren. Ook van het Chromium-project, bekend van Google Chrome, komt er schijnbaar een ARM-variant.

Reacties (29)

Kan iemand mij uitleggen wat het verschil is tussen deze arm versie voor Windows 10 en Firefox voor Android? Dat is beide ARM toch?

[Reactie gewijzigd door stijnos1991 op 6 januari 2019 10:46]

Even uit de bolle hoed hoor, het mag allebei wel ARM zijn, maar hoe FF zijn libraries aan moet spreken zal wezenlijk anders zijn op W10 als op Android.

Je kan windows 10 programma's ook niet zomaar draaien op een linux distro die allebei op AMD/Intel x86/64 draaien..... (of MacOS, terwijl daar exact dezelfde processors inzitten als de gemiddelde PC (tegenwoordig))

[Reactie gewijzigd door zion op 6 januari 2019 10:54]

Verder is de linux versie van firefox ook gewoon voor arm gecompileerd. In windows land ligt dit waarschijnlijk lastiger dan hercompileren.

[Reactie gewijzigd door qlum op 6 januari 2019 11:13]

Verder is de linux versie van firefox ook gewoon voor arm gecompileerd. In windows land ligt dit waarschijnlijk lastiger dan hercompileren.

Firefox wordt in rust geprogrammeerd zonder. NET ondersteuning, maar wel gecompileerd via Visual Studio. Als je in rust programmeer en alleen de. Net framework als libraries gebruikt, kon je wel gemakkelijker compileren voor ARM.

[Reactie gewijzigd door Bliksem B op 6 januari 2019 15:16]

In dat geval kun je het makkelijker naar Windows ARM compileren, maar niet makkelijk naar al de andere platformen.

[...]

Firefox wordt in C++ geprogrammeerd

Dat is dus niet hekemaal waar. Het grootste gedeelte wordt hedendaags in Rust geschreven

[Reactie gewijzigd door RoestVrijStaal op 6 januari 2019 14:30]

Ik zag het net voorbijkomen, maar kan de tab even niet terugvinden. Blijkbaar is Firefox voor Android ook geen native ARM-app.

*kuch*istemerken*kuch*

Blijkbaar is Firefox voor Android ook geen native ARM-app.

Dat slaat meer op dit verschil denk ik. Alle Mozilla apps draaien op de Gecko/Quantum engine die in een combinatie van C++ en Rust geschreven is. De meer gefocuste apps draaien op GeckoView, een custom WebView die ze delen om het zelf niet mee te hoeven leveren. In die zin zijn het dus Hybrid Apps. Maar het is wel degelijk gewoon ARM code die ze produceren, geen x86-emulatie ofzo. Er is ook gewoon een JIT-backend voor ARM.

*kuch*istemerken*kuch*

Vind ik persoonlijk wel meevallen? Firefox voor Android werkt wat mij betreft prettig.

[Reactie gewijzigd door Mitsuko op 6 januari 2019 12:39]

Nou dat valt opzich wel mee toch? Ik weet niet welke browser je anders gebruikt, maar standaard chrome is ook niet al te best hoor.

Ik zat net even een artikeltje op te zoeken over wat benchmarks en zag dat firefox in het algemeen wel een stuk rapper is dan chrome. Allicht zal dat ondertussen wel al weer anders liggen doordat men niet stil zit, maar tot dusver lijkt Puffin veruit de snelste te zijn in android land

https://www.google.nl/amp...roid-browsers-337802/amp/

Ander os, andere libraries.
Je kunt ook geen Windows x86 versie op een macos of Linux draaien, terwijl de processor hetzelfde is...

Je kunt ook geen Windows x86 versie op een macos of Linux draaien, terwijl de processor hetzelfde is...

Dat kan wel via bijvoorbeeld Wine, die een extra laag toevoegt om Win32 compatibiliteit mogelijk te maken. Het is dan nog steeds x86 code die op een x86 CPU draait.

tja, in dat geval zou Mozilla ook geen ARM versie voor Firefox uit hoeven brengen, want de ARM versie van Windows kan ook x86 windows programma's draaien via een emulator calls.

En waarom dan nog een losse Linux versie uitbrengen? Dat hoeft dan toch ook niet meer...

Tsja in IT is iets dat kan niet per se iets dat je ook moet willen. De grap is dat dingen vaak prima kunnen echter is de performance dan om te huilen of is het lelijk en/of niet onderhoudbaar. Dus worden er stukken uit geoptimaliseerd. Minder code -> minder onderhoud -> betere performance en/of minder bugs.

Dat je dingen kunt emuleren is in sommige gevallen erg handig (casual windows spelletje op je mac), maar niet iets wat je dan maar als beste oplossing moet zien.

De nieuwere Intel hardware draait meestal zowel windows, MacOS en linux. (Hier een NUC)
Maar da's off topic. Het gaat om de nieuwe engine voor Firefox.
o.t. Goed nieuws dat er een goed alternatief voor Chrome blijft!

Iets met twee verschillende besturing systemen die totaal niet op elkaar lijjken qua design.

Zit er dan zoveel architectuur-specifieke code in Firefox ? De JS JIT snap ik, aangezien die machinecode genereert, maar je zou verwachten dat de rest zo zou moeten werken aangezien het tegen dezelfde Windows API’s compiled als de x86 versie.

De genoemde onderdelen zijn precies de probleemgevallen. De crash reporter moet bijvoorbeeld een stack trace kunnen produceren, en de ABIs zijn anders op ARM64. De profiler heeft soortgelijke problemen. EME is een gedrocht van een standaard, gebruikt een soort blackbox dll-bestand die browsers onveranderd meeleveren en binnen een sandbox aanroepen, daarvan heb je dus ook een ARM64 versie nodig. WebRTC gebruikt waarschijnlijk onderdelen geschreven in assembly (met SIMD-instructies) voor de snelheid, dus daar heb je ook ARM64-specifieke versies van nodig.

Los daarvan schijnt de Nightly versie heel redelijk te draaien. OK, geen JIT dus hij zal niet supersnel zijn, Netflix zal waarschijnlijk niet werken zonder EME, en als je een crash krijgt stuurt hij geen informatie daarover op. Maar voor gewoon browsen werkt hij gewoon.

Directe link voor Windows:

• https://archive.mozilla.o...n64-aarch64.installer.exe

Zie echter ook: arm64 windows update #1

@redactie: Het zou ook tof zijn als er wat benchmarks gedraait kunnen worden, bijvoorbeeld in vergelijking met Edge of Chrome, en wellicht tegen een Intel Core i5-8265U, Core i5-8200Y en AMD Ryzen 5 2500U. Hier een aantal:

• SunSpider 1.0.2
• Basemark Web 3.0
• Octane 2.0
• Speedometer 2.0
• MotioMark 1.1
• JetStream 1.1

[Reactie gewijzigd door Balance op 6 januari 2019 11:06]

Waarom zou je benchmarks willen draaien tegen een testbuild die helemaal niet geschikt is voor dagelijks gebruik en waarvan niet geweten is hoe het met optimalisaties zit voor de architectuur

Nulmeting misschien? Leuk om te zien hoe een ARM nightly zich staande tegenover het andere.

Niet echt interessant als je als programmeur al weet dat er nog dingen gefixed moeten worden die de performance zullen verbeteren, zoals de JS JIT compiler, waar over gesproken wordt. Ook voor eindgebruikers niet interessant want dan krijgen ze alleen maar een verkeerde indruk.

Pas als de bouwer zegt dat nu alle basis-dingen klaar zijn kan het interessant zijn om echt te gaan benchmarken.

Om te meten of de testbuild geschikt is voor dagelijks gebruik en om te kijken of er nog verbeteringen doorgevoerd kunnen worden in de optimalisaties van de architectuur. Ook kan nu benchmarken helpen om latere verbeteringen aan te tonen.

* The Zep Man kijkt naar de naam van deze site...

Als er specifieke builds moeten komen voor ARM processoren dan wordt die Windows versie een kat in een zak voor kopers die niet beter weten dan dat alles werkt op Windows.

In principe kan je de 32-bit versie gebruiken via x86-emulatie, maar dat zal natuurlijk wel langzaam zijn. Op termijn verwacht ik dat ze deze ARM64-versie aan zullen bieden via de Microsoft store en/of via de universele installer die ze zelf aanbieden (die dan waarschijnlijk via x86-emulatie werkt maar gewoon de ARM64-versie downloadt).

Ik ben niet zo bekend met Windows maar is er op het Windows platform niet zoiets als een ‘fat binary’ zodat je meerdere executables voor verschillende architecturen in één bestand kunt stoppen?

Zo is MacOS al twee keer van architectuur gewisseld (PPC -> X86 -> AMD64) zonder dat de gewone gebruikers iets hoefde te doen of er zelfs maar iets van hoefde te merken.

Ik ben niet zo bekend met Windows maar is er op het Windows platform niet zoiets als een ‘fat binary’ zodat je meerdere executables voor verschillende architecturen in één bestand kunt stoppen?

Nee, maar dat is ook niet meer nodig met het gebruik van centrale repositories waar men software vandaan haalt.

Vergelijk bijvoorbeeld Arch Linux met Arch Linux ARM. De eerste betreft een x86-64 distributie, de laatste een onofficiële ARM fork. Het installeren van software gaat op beide via exact dezelfde manier, transparant voor de gebruiker. Het wordt pas een probleem als de gebruiker x86-only software probeert te installeren. Door de grote beschikbaarheid van open-source software komt dat nauwelijks voor. De onder houders van de distributies zorgen voor actuele packages. Voor randgevallen is er de Arch User Repository (AUR), met recepten on andere software te installeren voor de gebruikte architectuur.

Vergelijk nu Windows 10. Microsoft heeft dezelfde Store voor x86-64 en ARM. Het verschil met Linux voor native apps is dat softwareontwikkelaars zelf hun software voor alle architecturen moeten aandragen, omdat de distributiebouwer (Microsoft) dit niet doet/kan doen.

Betekent dit dat FF ook gaat werken op windows 10 mobile of is dit puur bedoeld voor (krachtigere) laptops met arm (in de toekomst)?

In theorie wel, maar ik denk dat Mozilla deze ARM versie heeft gemaakt met het oog op de nieuwere ARM laptops die her en der al verschijnen.

Nee totaal niet. Windows 10 Mobile staat geen eigen render engines toe dus Firefox kan (mag) daar nooit op werken.
Daarnaast heb je natuurlijk een andere interface nodig om te draaien op smartphones en dat wordt hier ook niet mee ingebouwd.