Google vervangt compiler in Chromium door efficiëntere Maglev

Google heeft een nieuwe compiler in Chromium toegevoegd. Die heet Maglev, een just-in-timecompiler voor de JavaScript-engine van Chrome. Maglev is volgens het bedrijf sneller in benchmarks en kan veel accu besparen.

De nieuwe compiler is toegevoegd aan Chromium-versie 114, schrijft Google. Daarna kan die in nieuwe Chrome-versies worden toegevoegd, of aan alternatieve browsers op basis van Chromium. De nieuwe compiler is een just-in-timecompiler, die 'relevante code' al in de eerste honderdste seconde kan genereren, stelt Google. Dat verlaagt de cpu-last en kan volgens Google accuduur op laptops en smartphones verlengen.

Volgens Google is de nieuwe compiler een stuk sneller dan de eerdere compiler. Het bedrijf haalt daarvoor benchmarks van Speedometer aan, waar Maglev voor een verbetering van vijf procent zou zorgen. In andere benchmarks, waaronder JetStream, zou dat zelfs kunnen oplopen tot 7,5 procent meer efficiëntie. Een deel van die efficiëntie wordt volgens het bedrijf gehaald door verbeteringen aan de V8-JavaScript-engine.

Reacties (45)

sspiff 6 juni 2023 14:42

Het artikel is volgens mij niet juist in hoe het de verandering omschrijft.

Google gaat inderdaad een van de JavaScript compilers uit Chromium vervangen, maar het artikel en de commentaren lijken er van uit te gaan dat dit de volledige JavaScript compiler van Chrome/Chromium is.

De JavaScript compiler van Chromium bestaat uit 4 verschillende compilers, die door elkaar gebruikt kunnen worden. Twee ervan zijn niet optimaliserend met met als hoofddoel om snel JS te beginnen uitvoeren nadat deze gedownload is.

Daarnaast heb je nog een mid-tier en een end-tier compiler, die op basis van profiling informatie (zoals genomen paden in if-constructies, types van variabelen, etc) een meer geoptimaliseerde versie van het programma compileren terwijl het programma nog loopt met behulp de eerdere stage compiler. Het is een soort incrementele optimalisatie van de gegenereerde code dus.

De nieuwe maglev compiler is een vervanging van de eerdere mid-tier compiler in Chrome, dus enkel die derde/voorlaatste trap wordt nu vervangen. Met als hoofddoel dus snellere compilatietijden en op die manier energie te besparen, zonder een aanzienlijk snelheidsverlies tov de vorige mid-tier compiler.

vt220 6 juni 2023 09:44

Misschien een beetje offtopic. Maar toch nieuwsgierig..
k begrijp dit niet. Is sneller en minder cpu gebruik niet met elkaar in tegenspraak?
Ik bedoel in de 1ste 1/100 seconde zal die compiler toch cpu nodig hebben denk ik. Of is het zo dat, als je de twee compilers vergelijkt, het totale cpu verbruik bij de nieuwe compliler lager is omdat de nieuwe sneller is?

Iemand enige info?
(edit type)

[Reactie gewijzigd door vt220 op 23 juli 2024 11:57]

AlphaRomeo FP PowerMod @vt220 • 6 juni 2023 09:45

De JIT compiler is efficiënter dan de vorige. Met minder CPU cycles kun je dus schijnbaar meer bereiken. Zie het als een efficiëntere auto-motor. Met minder brandstof kun je toch verder komen. Google heeft dus een van de motoren van Chrome vervangen door een efficiënter exemplaar.

Killemov @AlphaRomeo • 6 juni 2023 09:55

Vreemde analogie met een automotor, het algoritme is gewoon verbeterd. Het zou me niets verbazen als Google hiervoor AI heeft ingezet.

Sk313t0r @Killemov • 6 juni 2023 10:07

Ik vind het eigenlijk een prima analogie, je kunt een automotor vast voor meer dingen gebruiken!

Dit is trouwens een fijne verbetering, toch nog een reden om deze browser (in ieder geval op het werk) te blijven gebruiken.

Remzi1993 @Killemov • 6 juni 2023 10:38

Een betere algoritme kan je vergelijken met een betere motor. Dit soort vergelijkingen heten analogieën, namelijk het vergelijken van twee ongelijksoortige ideeën of elementen om een principe uit te kunnen leggen.

Het principe hier is dat iets sneller is geworden doormiddel van een verbetering van de werking van een onderdeel van het geheel en dat onderdeel werkt: sneller efficiënter of gewoonweg beter.

mphilipp @Killemov • 6 juni 2023 10:58

Als ik een motor verbeter, door bv de injectie te optimaliseren, verander ik toch in wezen het/een algoritme van de motor. Het is een perfecte analogie.

Bouwer21000 @Killemov • 6 juni 2023 16:09

Niet elk algoritme is een AI

killerdemon @Bouwer21000 • 7 juni 2023 17:04

De meeste algoritmen zijn geen AI denk ik

laurxp @vt220 • 6 juni 2023 10:14

Nee, juist niet!

De truc hier is dat Javascript een taal is met dynamische types. Dit zorgt er voor dat je iets als "function keertwee(x) { return x + x }" kan schrijven. Als je dat aanroept met het nummer 2, krijg je 4 terug. Maar als je het aanroept met het woord "hoi", krijg je "hoihoi" terug! Het werkt dus op álle soorten argumenten, zolang er maar een "+" voor het argument bestaat.
En het heeft óók nog eens "zwakke" types, waardoor "function plustwee(x) { x + 2 }" bij het aanroepen met het woord "123" het woord "1232" terug geeft, want het zet dynamisch het nummer om naar een woord, zodat het de twee woorden aan elkaar kan plakken.

Hierdoor is de taal niet direct om te zetten naar machinecode, want er is meer dan één optie mogelijk. De oplossing is om het te interpreteren: hierbij lees je de code regel voor regel uit, kijk je wat de types van alle variabelen zijn, en voer je de bijbehorende machinecode voor die regel uit. Dit werkt heel goed en is vrij simpel te implementeren, maar het is vrij langzaam. En dat moet je iedere keer doen, want de types kunnen bij de volgende aanroep compleet anders zijn.

De oplossing is om het "Just-in-time" te compileren. Hierbij hou je bij wat de types van de variabelen zijn bij iedere aanroep, en als je ziet dat een bepaalde combinatie vaak voorkomt, genereer je een gespecialiseerd blok machinecode. Dit blok machinecode uitvoeren is een héél stuk sneller dan het interpreteren omdat je alle typecontroles binnen dat blok weg kan laten, en je hoeft alleen maar bij het aanroepen van het blok te kijken of de types kloppen, of dat je terug moet vallen op interpretatie. In de loop van de tijd zal dus al je code worden omgezet naar machinecode, maar dat kan best wel een tijdje duren.

Hoe sneller de JIT compiler kan achterhalen wat de types zijn, hoe eerder het de gespecialiseerde machinecode in kan zetten - die efficienter is en dus minder CPU cycles nodig heeft om uit te voeren.

[Reactie gewijzigd door laurxp op 23 juli 2024 11:57]

MrMonkE @vt220 • 6 juni 2023 10:34

Een compiler is ook gewoon een programma/code. Ik heb in groot project op een performance team gezeten en soms vind je code die gewoon 100x sneller kan. Dat is niet erg als het 1x in de run-time wordt aangeroepen maar als je het 100000x per uur doet begint het aan te tikken.

Gropah @MrMonkE • 6 juni 2023 10:55

Ja, die fout heb ik ook wel eens gemaakt

Stukje code in scala zo idiomatic mogelijk willen schrijven, dus redelijk functioneel. Moest uit een subcollectie uit een map trekken, kreeg een lijst van keys. Dit gedaan met wat filters en dergelijke. Werkte best leuk, maar was niet snel. En toen ging ik nadenken

De map waar een subset uit moest komen, kon miljoenen items bevatten. En voor elke key die ik er uit moest trekken, filterde hij de lijst apart. Dus even herschreven zodat het gebruik maakte van een hashmap, ookal was de code minder idiomatic. De speedup zat richting factor 500, omdat alle keys voor de map natuurlijk niet in de cache konden blijven en ik enorm veel cache misses veroorzaakte.

Oeps

MrMonkE @Gropah • 6 juni 2023 10:58

Gelukkig zijn er tegenwoordig hele slimme code analyse en re-factor tools die dat gewoon zien voor ons.

Quo @vt220 • 6 juni 2023 10:10

De snelheidswinst zal wel bereikt zijn met efficienter werkende code.

Een opgave van de verbruikte energie voor een specifieke taak zou wel helpen om de vergelijking te maken tussen hoge cpu voor korte tijd en lage cpu voor langere tijd. Maar die wordt vaak niet gegeven.

Gropah @vt220 • 6 juni 2023 10:20

Heel veel dingen kun je op verschillende manieren bouwen. Een (dom) voorbeeldje: iets opzoeken in een lijst.

Skippable als je enigzins kennis van algoritmen en optimalisaties hebt:
Je kan nieuwe items gewoon achteraan in je lijst zetten. Als je dan wilt weten of het getal 7 in de lijst 1,2,3,4,5,6 voorkomt, moet je door alle items heen. Opzich niet zo'n probleem bij kleine lijsten, maar hoe langer je lijst word, hoe meer items je moet controleren.

Je kan ook een berekening maken van waar hij zou moeten staan. Bij een lijst van cijfers zou dat het cijfer zelf kunnen zijn. Als je het getal 7 toe wilt voegen, komt die op plek 7. Zoeken is nu heel makkelijk. Je kijkt gewoon op plek 7 in de lijst. Staat er niets? Dan komt ie niet voor in de lijst. Het nadeel is bij deze berekening, dat je al snel een grote lijst nodig hebt. Dat valt op andere manieren op te lossen, maar dat is niet zo heel relevant voor dit voorbeeld.

Alles heeft zijn voor- en nadelen. Soms denk je van te voren dat oplossing A beter is, maar kan in de praktijk blijken dat het toch anders word gebruikt dan je denkt, waardoor oplossing B beter is. Zoiets als in het voorbeeld is een relatief kleine wijziging, en zul je waarschijnlijk gewoon als bugfix doen. Maar een opeenstappeling van dit soort dingen, of dit soort verbeteringen op een hoog niveau kan om een grote herschrijving of nieuwe library vragen. En dat is wellicht wat hier gebeurd is.

[Reactie gewijzigd door Gropah op 23 juli 2024 11:57]

jorisporis @vt220 • 6 juni 2023 11:30

Stel je programmeert een robot die boeken gaat halen in een bibliotheek. Je kan hem zo programmeren dat hij alle rekken afloopt tot hij het juiste boek vind, of meteen naar de juiste afdeling loopt, de juiste letter en vervolgens het juiste boek.
Er zijn veel trucs om iets te doen met minder cpu cycles. Gewoon slimmere algoritmes (zoals hierboven), specifieke instructies (bv SIMD) of zorgen dat je cpu niet hoeft te wachten op data van netwerk of geheugen, ssd(veel cycles doet je cpu gewoon niets ookal draait hij op full speed)

TheMak @vt220 • 6 juni 2023 11:24

De JIT-compiler is bedoeld om de snelste/kortste route te berekenen naar het einddoel.

MaglevNL 6 juni 2023 09:51

Goeie naamgeving

Nu maar hopen dat websites ook lichter worden onder 'green coding'. Zoveel bloat overal.

laurxp @MaglevNL • 6 juni 2023 11:31

Developers krijgen simpelweg niet betaald om snelle en efficiënte code te schrijven. Voor de frontend is het goed genoeg als de gebruiker niet klaagt dat het traag is, en voor de backend is het meestal goedkoper om er gewoon een extra server tegenaan te gooien.
CPUs zijn goedkoop, ontwikkelaars zijn duur: de manager heeft liever een paar extra features dan een optimalisatie die 25% minder CPU gebruikt en daardoor €30 / maand aan serverkosten bespaart.

DdeM @laurxp • 6 juni 2023 17:43

Als de Technical Debt zo hoog is dat het nauwelijks nog te fixen is tenzij je een complete rewrite moet doen ben ik het wel met je eens. Maar dat is het korte termijn denken wat het vergif is van de software organisaties vandaag de dag.

Als je van de meet af fatsoenlijk kwaliteit inbouwd dan is die optimalisatie, als die nodig is, goedkoper dan een server er bij te mikken.

Dat lost ook het probleem wat @P_Tingen beschrijft op. Goede development technieken en goede automated tests en code wijzigen is een low risk activiteit.

Dit kan je ook zelf uittesten door gebruik te maken van de Wall of Technical Debt: https://verraes.net/2020/01/wall-of-technical-debt/

laurxp @DdeM • 6 juni 2023 18:57

Het gaat hier niet eens om technical debt. Snelle code schrijven is gewoon een compleet ander beestje.

Als je snelle code wil schrijven, kom je per definitie bij een lage programmeertaal uit. Gooi Javascript, Python, en C# maar de deur uit, en gebruik C of Rust. En Object-Oriented Programming kan je ook doei tegen zeggen, want een Structure-of-Arrays structuur is een heel stuk sneller dan een Array-of-Structures. Alle "hot loops" moet je uiteraard handmatig herschrijven met SIMD intrinsics.

Maar ja, je ontwikkeling duurt nu 5x zo lang, de code is niet herbruikbaar, en onderhoud is een nachtmerrie. Je UI rendert nu in 10ms in plaats van 20, maar is dat het écht waard?

DdeM @laurxp • 7 juni 2023 15:45

Wat dat betreft ben ik het ook wel eens met je comment ansich:
"Voor de gemiddelde gebruiker is het goed genoeg als de applicatie niet te traag is" - nuance door mij.

En over het algemeen (vandaar het stuk ", als die nodig is, " in mijn originele comment) zijn gebruikelijke (web) programmeertalen als JavaScript en C# dan ruim snel genoeg, aannemende dat de developers fatsoenlijke kwaliteit inbouwen en niet zoals dus te vaak gebeurd, de boel een beetje afraffelen om de korte termijn doelen maar te halen. En als het dan echt nodig is, kan je altijd het te langzame deel in bijv. rust schrijven, en die code vanuit bijvoorbeeld een c# applicatie aanroepen om dan dus nog extra snelheid te krijgen. Maar ook dan is het wel belangrijk dat je dus fatsoenlijke kwaliteit en test automation hebt zodat je vanuit die c# app zeker weet dat het gedrag van de code nog hetzelfde is. Been there, done that, met applicaties waarbij c# naar c++ omgezet werd ivm simulaties.

P_Tingen @laurxp • 6 juni 2023 15:17

En hoewel vaak onbevredigend (ik ben zelf ook ontwikkelaar) is het vaak nog het verstandigste ook. Meer ijzer is domweg meer snelheid zonder risico's. Code wijzigen betekent mogelijk fouten introduceren en dus herstellen en dus hoge kosten.

sfranken @MaglevNL • 6 juni 2023 10:44

Ik verwacht het tegenovergestelde. Omdat deze compiler beter z'n taak doet is het voor webdevs nóg minder belangrijk om lean code te schrijven, want de compiler pompt het toch wel uit (even plat gezegd).

bzzzt @sfranken • 6 juni 2023 10:49

Precies, kan je nog een extra tracker toevoegen zonder dat gebruikers het merken

CPV 6 juni 2023 10:03

een stuk sneller

En dat blijkt 5% te zijn? Best leuk, maar bij een stuk sneller zou ik 20% verwachten.

MrMonkE @CPV • 6 juni 2023 10:41

Ja dat is duidelijk 'een beetje' en niet 'een stuk'.
'stukje' zou nog kunnen in deze context.

Kenhas @CPV • 6 juni 2023 10:42

Je moet natuurlijk niet enkel kijken naar een paar procent sneller. Het is tegelijkertijd ook een stuk efficiënter en zorgt dus voor minder verbruik.

Dus sneller met een lager energieverbruik is een mooie vooruitgang.

Ik vind 5% trouwens toch niet slecht

Alex3 @CPV • 6 juni 2023 10:17

Ja, 5% is marginaal, geen artikel waard.

svennd @Alex3 • 6 juni 2023 10:42

Die 5% (of meer naargelang de workload) is absurd veel, gezien hoeveel gebruikers Chromium (en varianten) kent, daarbij is JavaScript al jarenlang door Google geoptimaliseerd, als je dan nog eens 5% eraf haalt dan is dat absoluut een artikel waard.

bzzzt @svennd • 6 juni 2023 10:52

Het is natuurlijk vooral interessant waar die 5% vandaan komt. Code wordt niet ineens een aantal procent sneller in het algemeen. Ik neem aan dat die benchmarks een aantal bottlenecks lieten zien waar met wat handiger constructies winst kan worden geboekt.
Het risico van optimaliseren voor een benchmark is dat code 'in de praktijk' juist langzamer kan worden...

TheVivaldi

Google Chrome

@bzzzt • 6 juni 2023 11:24

Aan de andere kant zeggen benchmarks ook niet zoveel. Een Snapdragon Gen1 zal over een paar jaar ook niet meer in de top 5 snelste soc's staan, maar in de praktijk ga je dat echt niet merken.

svennd @bzzzt • 6 juni 2023 14:56

Klopt, het hangt uiteraard af hoe goed de benchmarks zijn, maar vrijwel alle benchmarks verbeteren omdat het ook niet om één change gaat : "In addition to Maglev, the V8 team has achieved this score through both small adjustments, such as optimized function calls, and major, multi-quarter projects."

Nark0tiX @svennd • 7 juni 2023 12:52

javascript geoptimaliseerd?

laurxp @Alex3 • 6 juni 2023 11:24

5% voor code die op miljarden apparaten draait en waar al 20 jaar aan optimalisatie in zit? Dat is een enorme verbetering!

uiltje @laurxp • 6 juni 2023 14:24

Het is 5% op de JavaScript functionaliteit. Het is geen 5% over het geheel. Ik weet niet wat de verhoudingen zijn. JavaScript wordt wel veel gebruikt, maar als je het over bijvoorbeeld video decoding hebt zal het maar een klein deel van het geheel zijn.

svenk91 @uiltje • 6 juni 2023 16:18

En 5% in benchmarks is niet persé 5% op je meest gebruijte sites, afhankelijk van je benchmarks. Als de benchmark moeilijke problemen test die webdevs al vermijden in hun site omdat het traag gaat, dan schiet je weinig op. Neem daarbij mee dat een groot deel van de internet gebruikers voornamelijk bij een paar sites blijft (youtube, facebook, twitter, etc.). Als benchmarks juist die populaire sites testen dan is het misschien aardig accuraat.

Vinnie.1234 @CPV • 6 juni 2023 10:15

Ligt toch wel een beetje aan wat de vorige snelheid was.

Voorbeeld:
Heb je 100 euro en je krijgt er 5% bij krijg je inderdaad maar een paar euro en ben je niet echt rijker. Had je 1.000.000 euro en je krijgt er 5% bij krijg je 50.000 wat toch wel weer aanzienlijk is.

Lamith @Vinnie.1234 • 6 juni 2023 10:31

Daar ligt het volgens mij helemaal niet aan. Procentueel is de toename gelijk in je vergelijking. Voor iemand die 1miljoen euro heeft, voelt 5% verhoging hetzelfde als voor iemand die 100 euro heeft. Je zou zelfs kunnen stellen dat die 5% verhoging voor degene met 100 euro meer impact heeft, dan voor degene met 1 miljoen, puur op basis van koopkracht. Diegene met 1miljoen kan toch al alles kopen wat 'ie wil en voor degenen met 100euro kan het juist een extra dag eten betekenen.

Wanneer er een claim is dat het een "stuk sneller" is, dan verwacht je meer dan 5% lijkt me.

IrBaboon79 @Vinnie.1234 • 6 juni 2023 10:50

En hoe vaak die snelheidswinst triggered - veelgebruikte functies die vaker aangeroepen worden kan best het eea opleveren immers. Afijn, elke winst is meegenomen iig.