Door Anoniem: Ik zal dan wel de enige zijn die positief ben over deze wijziging. Ik draai al een hele tijd de Nightly builds van Firefox en merk in mijn ervaring alleen maar verbetering.
Nee, je bent niet de enige, ik ben er ook positief over. Ik gebruik overigens 52.3.0 ESR omdat dat de versie is die Debian Stable voert, dus ik ben nog een eindje verwijderd van het zelf zien van de verbeteringen.
Wat de meeste mensen die het maar niets vinden niet door zullen hebben is dat parallele verwerking verdomd moeilijk is, dat is niet iets wat je even achteraf toevoegt aan een systeem. Als je daar bij het ontwerp niet van begin af aan rekening mee hebt gehouden is het een verbouwing die lijkt op de fundamenten onder je huis vervangen én ook nog eens allerlei onderdelen van je huis heel anders plaatsen ten opzichte van elkaar om ze op die nieuwe fundamenten te laten passen.
De reden dat dat zo lastig is is dat onderdelen van een verwerking afhankelijk zijn van elkaars resultaten. Je kan niet zomaar deelverwerkingen over meerdere CPU-cores verdelen, de onderlinge afhankelijkheden maken dat nog steeds allerlei deelverwerkingen echt klaar moeten zijn voor je andere deelverwerkingen kan starten. En als je daar als ontwikkelaar steekjes bij laat vallen zit je meteen met ongeveer de moeilijkst oplosbare categorie bugs te worstelen, omdat het optreden van de fouten en de precieze manier waarop ze zich manifesteren sterk afhangt van allerlei subtiele timingverschillen tussen de parallelle deelprocessen, en die zijn sterk afhankelijk van hoe het besturingssysteem besluit CPU-tijd over processen te verdelen en dus van wat er nog aan andere processen op het systeem actief is. En het menselijke brein blijkt behorlijk slecht te zijn in beredeneren hoe parallelle processen op elkaar inwerken, wat betekent dat probelemen daarmee niet alleen voor de gebruikers maar ook voor de ontwikkelaars van de software heel ongrijpbaar zijn.
Firefox is bezig een achterstand op dat gebied in te lopen, en ze zijn zo ver gegaan om er een nieuwe programmeertaal voor te ontwikkelen die het soort problemen dat ik beschrijf helpt te reduceren. Daarnaast is een van de pijnpunten dat het oude addon-model domweg niet ontworpen is voor parallelle verwerking en er ook niet geschikt voor te maken is. Als ze dat handhaven hebben ze de keuze uit een browser die aan alle kanten crasht en dus zo instabiel is als de pest of een browser die allerlei dingen sequentieel blijft uitvoeren en CPU-kracht onbenut laat.
Ter illustratie is het misschien verhelderend om wat cijfers voor heel andere software te geven. Het gaat om zelf ontwikkelde fotobewerkinsgssoftware die interactief of batchgewijs foto's kan verwerken. De batchgewijze verwerking voor een bepaalde serie foto's, met ook hetzelfde resultaat, kan in drie smaken, met de doorlooptijd op een quad-core systeem:
• 741 seconden voor puur sequentiële verwerking, de foto's worden achter elkaar verwerkt gebruik makend van 1 CPU-core;
• 255 seconden voor verwerking waarbij elke foto sequentieel wordt verwerkt maar foto's over de 4 cores verdeeld worden (de computer is steeds met 4 foto's tegelijk bezig en elke foto wordt net als in de vorige variant op 1 core verwerkt);
• 381 seconden voor verwerking waarbij de foto's een voor een verwerkt worden, maar elke fotoverwerking verdeeld wordt over de 4 cores.
Dat de snelste variant niet 1/4 maar ongeveer 1/3 van de puur sequentiële verwerking kost komt vermoedelijk omdat ook veel meer data tegelijk van en naar de CPUs getransporteerd moet worden, ik denk dat de geheugenbus verzadigd is en de beperkende factor vormt. Maar ik krijgt de foto's wel het snelst verwerkt door domweg vier onderling onafhankelijke verwerkingen naast elkaar te laten draaien. Als ik steeds de verwerking van één foto over vier CPU-cores verdeel is mijn snelheidswinst veel lager, ongeveer 1/2 van de puur sequentiële verwerking. Dat komt omdat allerlei deelverwerkingen afhankelijk zijn van elkaars resultaat. Om bijvoorbeeld het contrastbereik van de hele foto te kennen moet het proces wachten op de alle resultaten voor delen van de foto. Dan pas kan het verder met de contrastcurve, die daarvan afhankelijk is. Het is daardoor onmogelijk om voortdurend op 100% CPU voor alle cores te opereren. Dit is wél de snelste manier om minder dan 4 foto's te verwerken en om bij interactieve verwerking de gebruiker een snelle respons te kunnen geven. Om het te kunnen ondersteunen moest de software ingrijpend herschreven worden, dat was geen kleinigheid.
Bij een webbrowser kan je verschillende tabbladen als onafhankelijke processen over CPU's splitsen, maar omdat heel vaak maar één tabblad tegelijk bezig is met laden is het voor een browser die sneller reageert ook nodig om de opbouw van één pagina te parallelliseren. En daar liep men bij Firefox stuk op het oude addon-model. Om dat geschikt te maken voor parallellisatie, aangenomen dat dat te doen is, zullen de wijzigingen zo groot zijn dat addons zlef ook ingrijpend herschreven moeten worden. En als addons dan toch ingrijpend herschreven moeten worden is het een goed moment om te kijken of in plaats van een opgelapt addon-model een geheel nieuw model niet makkelijker is om addons mee te ontwikkeln én een betere performance oplevert. Dat dat de conclusie is verbaast me totaal niet, een oud model oplappen levert namelijk meer restricties op dan met een schone lei beginnen, en met minder restricites kan je agressiever optimaliseren.
Het is zinloos om én op de traagheid van Firefox te kankeren én op de incompabiliteit van het oude en nieuwe addon-model. Het een sluit het ander uit, je kan het onmogelijk allebei hebben. Bij Mozilla heeft men voor snelheid gekozen. De overgang doet pijn, maar het is een legitieme keuze.