Mozilla verbetert Javascript-prestaties met Tracemonkey

Volgens Mozilla-ontwikkelaar Mike Shaver kunnen nieuwe versies van Mozilla-producten zoals browser Firefox de scriptingtaal Javascript aanzienlijk sneller verwerken. Er wordt namelijk gewerkt aan een vernieuwde jit-compiler.

De vernieuwde just-in-time compiler heet Tracemonkey en zorgt ervoor dat javascript op het x86-, x86-64- en ARM-platform naar zogeheten native code gecompileerd wordt, die direct door de processors kan worden uitgevoerd. Dit levert aanzienlijke prestatie- en snelheidsverbeteringen op, schrijft Shaver op basis van enkele uitgevoerde benchmarks. Tracemonkey bevindt zich sinds deze week in de testversie van Firefox 3.1, maar staat standaard uit. Er moet namelijk nog een aantal fouten uit de software gehaald worden.

De ontwikkelaars hebben verschillende ideeën om Tracemonkey verder te verbeteren, meldt Shaver. Te denken valt aan een verbeterde codegenerator, efficiëntere datastructuren, de toepassing van parallelle compilatie, het gebruik van specifieke processorfeatures en het beter traceren van codepatronen. Bij de ontwikkeling van de vernieuwde jit-compiler is gebruikgemaakt van een techniek genaamd trace trees en van ideeën die bij het Tamarin Tracing-project vandaan komen. Vooralsnog is Mozilla de enige browserbouwer die jit-compilatie voor javascript toepast, maar Shaver verwacht dat andere ontwikkelaars zullen volgen.

Het is vanwege twee redenen noodzakelijk dat de Mozilla-producten zo snel mogelijk van Tracemonkey worden voorzien, schrijft Shaver. De eerste is dat websiteontwikkelaars en gebruikers vragen om een betere performance, omdat vertragingen bij hen irritatie oproepen. De tweede reden is dat er in de Mozilla-programma's intensief gebruikgemaakt wordt van Javascript. Prestatieverbeteringen op Javascript-vlak hebben daardoor direct gevolg voor de performance van bijvoorbeeld Firefox en Thunderbird.

Reacties (60)

[Vordreller]

Voor mensen die zich vragen stellen bij de standaardsnelheden van de loops in Javascript, hier een artikel dat een aantal weken geleden uitkwam:

http://blogs.sun.com/greimer/entry/best_way_to_code_a

is een uitgebreid overzicht van alle mogelijke loops op alle mogelijke browsers(op alle mogelijke systemen)

indien FF dit nog gaat versnellen zitten we goed voor de toekomst

[semicon]

Hoe verhoud dit zich tot Safari? Die volgens mij op dit moment nog wel een van de snelste is?

Dat zou misschien een reden kunnen worden om over te stappen namelijk!

[Verwijderd]

Tracemonkey vs Squirrelfish. Tracemonkey (Firefox) is beduidend sneller. Ten opzichte van de 'oude' engine is er op sommige vlakken en versnelling van ongeveer 40x gehaald.

Er is ook een (real-life) demo gemaakt, wat de nieuwe snelheidswinst gebruikt.

Om Tracemonkey te kunnen gebruiken, dien je eerst een recente nightly build (nieuw profiel is aangeraden!) te downloaden en daarna via about:config handmatig de waarde javascript.options.jit.content op true te zetten.

Tracemonkey is slechts het begin, meer snelheidswinsten liggen in het nabije verschiet.

There is still a ton of work to be done. The incredible speed-ups that we're seeing are only just the beginning. A lot can be done to improve how registers are currently being allocated which will provide even more speed-ups.

bron: http://ejohn.org/blog/tracemonkey/

[Reactie gewijzigd door Verwijderd op 27 juli 2024 07:37]

[sweetdude]

Om Tracemonkey te kunnen gebruiken, dien je eerst een recente nightly build (nieuw profiel is aangeraden!) te downloaden en daarna via about:config handmatig de waarde javascript.options.jit.content op true te zetten.

Ik heb hem toch weer netjes uitgezet. Het ding crashte steeds op de demo pagina. Wel natuurlijk netjes een crash report gestuurd.

[PPie]

Toch is er iets raars: Volgens de 2e grafiek hier doet de TraceMonkey versie 2.113 seconden voor een SunSpider run.

Volgens http://webkit.org/blog/189/announcing-squirrelfish/ doet WebKit + SquirrelFish er 30.6/minuut = 1.96 sec per run.

Dat lijkt me sneller?

[Verwijderd]

Je kan de sunspider test niet vergelijken tussen meerdere PC's aangezien het sterk afhankelijk is van de hardware (CPU). M.a.w: ze (webkit) hebben dus een snellere PC gebruik en geeft daardoor een vertekend beeld.

[Fuzzillogic]

Leuk. Maar ik zou echt VEEL liever zien als er een eens een fatsoenlijke taal van Javascript gemaakt zou worden, met een normaal objectmodel en strong/static typing, en een betere runtime library.

[OddesE]

Och en javascript is juist zo'n prachtige taal omdat je geen static typing hebt. Neem nou deze code:

String.prototype.trim = function() {
return this.replace(/^\s+/,'').replace(/\s+$/,'');
}

die voegt aan alle strings die na dit statement worden gealloceerd een extra functie toe die strings eerst niet hadden. Hierna kun je dus dit doen:

var s = new String(" Hello world ").trim();
alert("[" +s + "]"); // alerts "[Hello world]"

Da's toch juist prachtig? In drie regels code een functie toevoegen aan een standaard object. Kijk anders eens naar prototype js, een geniaal geschreven javascript framework, misschien dat je anders tegen javascript aan gaat kijken.

[al-ahlex]

C# heeft static types, en laat dit ook toe via extensions methods. Het ene sluit het andere dus niet uit.

[Marcks]

Persoonlijk heb ik het niet zo op client-side code die ongevraagd wordt uitgevoerd. Wat mij betreft mag javascript zo minimalistisch mogelijk zijn.

[boe2]

Wat doe je dan juist op tweakers? Nog maar simpelweg om die commentaar te typen werd er al een hele zooi javascript aangestuurd

[Verwijderd]

die ongevraagd wordt uitgevoerd

Marcks heeft het over popups, prompts, alerts (vooral bij het verlaten van een pagina ofzo), Muziek,...

[boe2]

dan zie ik niet hoe zijn reply ook maar enige relevantie heeft op de stelling van fuzzilogic

[Jaap-Jan]

Voor Firefox is er de NoScript extensie, die zorgt ervoor dat JavaScript standaard op geen enkele site wordt uitgevoerd. Als het nodig is kun je zelf sites toevoegen aan de uitzonderingen. Op die manier wordt er alleen JavaScript uitgevoerd als je het zelf wilt.

[mor0n]

Goed nieuws.

Vooralsnog is Mozilla de enige browserbouwers die jit-compilatie voor javascript toepast, maar Shaver verwacht dat andere ontwikkelaars zullen volgen.

Nu hopen dat Microsoft hier ook eens een blik opwerpt. Is het nu zo dat Microsoft dat Tracemonkey ook zo zou kunnen implementeren? Of is dat zoiets als water en vuur.

Ik zie zo graag dat de browser-giganten hun krachten bundelen. Eén platform... *plop* Ik stop met dromen.

[MBV]

Doe mij maar concurrentie: Firefox moet tegen IE opboxen, en verzint steeds iets nieuws om onderscheid te maken. IE8 wordt (als ik de geruchten goed begrijp) de eerste IE die standards-compliant is, zonder FF was dat niet gebeurd. En mede omdat Opera en Safari de ACID-testen wonnen is men bij FF heel hard aan het werk gegaan

Microsoft zou tracemonkey trouwens zo kunnen overnemen, maar dan moeten ze wel een licentie kopen bij Mozilla, of IE onder de Mozilla Public Licence (of zelfs GPL) moeten uitbrengen. En dat zal waarschijnlijk allebei niet gebeuren
Het zou me trouwens niks verbazen als je dit binnen een paar jaar in IE terug vindt, als blijkt dat dit zo goed werkt als beloofd.

[OddesE]

Microsoft zou tracemonkey trouwens zo kunnen overnemen, maar dan moeten ze wel een licentie kopen bij Mozilla, of IE onder de Mozilla Public Licence (of zelfs GPL) moeten uitbrengen.

Nee hoor:

3.7. Larger Works.

You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code.

Mozilla Public License Version 1.1

De meeste Open Source licenties hebben niet de beperking die de GPL heeft. Bij de Mozilla licentie vallen alleen wijzigingen / contributies aan de Mozilla code onder de Mozilla license. Niets weerhoudt MS ervan om Tracemonkey te integreren in IE onder de licentie van IE. Ze moeten dan wel ook een Mozilla licentie meeleveren voor het Tracemonkey stukje. Dat is juist de spirit van Open Source, beschikbaar voor iedereen, ook voor developers en onder / in combinatie met andere licenties. Behalve bij de GPL dan.

[Verwijderd]

Mozilla heeft inmiddelsCanvas voor Internet Explorer ontwikkeld.

[Pietervs]

Ik zie zo graag dat de browser-giganten hun krachten bundelen. Eén platform... *plop* Ik stop met dromen.
En daarmee de concurrentie-slag om zeep helpen zodat we weer tien jaar met dezelfde browser zitten terwijl de markt zit te springen om nieuwe dingen te kunnen implementeren?
Nee, dan heb ik liever 3 grote, goede spelers en een aantal kleintjes. Dat houdt de ontwikkelaars scherp

[Hadron]

Hmm, converteren naar native code is leuk en aardig, en waarschijnlijk een goede mogelijkheid om de performance op te krikken.
Maar ik ben wel benieuwd hoe mozilla de veiligheid hierin garandeert.
Want, wetende dat je script naar native code wordt geconverteerd, is het misschien wel interessant voor hackers om te kijken of daar geen misbruik van gemaakt kan worden.

Misschien zie ik de dingen te donker, want als een dergelijke engine onder een gebruiker zonder al teveel rechten binnen een sandbox draait, wordt't al een stuk lastiger.
Desondanks, iets om in het hoofd te houden, zeker nu firefox populairder wordt (en dus interessanter om te hacken).

Edit: In een geinterpreteerde omgeving ben je gelimiteerd tot de commando's die de interpreter kent. De truuk hier is om de interpreter te foppen of handig gebruik te maken van de mogelijkheden van de commando's, om zo je truukjes uit te halen.

Native code heeft veel meer mogelijkheden, en dus ook meer risico's. Ik zeg niet dat het per se mis moet gaan, ik denk alleen dat het verstandig is goed na te denken over wat er mis kan gaan, en hoe dat afgevangen gaat worden. Daarin kunnen inderdaad technieken als DEP, minimale gebruikersrechten en sandboxing meehelpen, maar ze veranderen niet alles. Zeker gezien DEP niet altijd ondersteund wordt, en er nog steeds veel gebruikers met 'Administrator/leeg wachtwoord' werken. Daarom moet de compiler ook goed opgezet zijn, en moet er rekening gehouden worden met de veiligheid.
Da's zeker geen onmogelijke taak, maar wel eentje die gedaan moet worden

Overigens denk ik dat de vergelijking met PHP, ASP.Net en JSP niet nuttig is is: Die draaien op de server. Interpretatiefouten en moedwillige hacks daarin werken op de server, niet (zoals javascript) op de client. Van de beheerder van een server mag je voldoende kennis verwachten om een en ander veilig op te zetten, van de gemiddelde pc-gebruiker (helaas) niet

[Reactie gewijzigd door Hadron op 27 juli 2024 07:37]

[MBV]

Ten eerste moet je je browser toch al zonder root-rechten draaien. Ten tweede heb je nu processors met DEP en dergelijke. En ten derde: in welk opzicht is het makkelijker native code te hacken dan 'gewone' code?

Er zijn zat scripttalen (PHP, Java, .NET) die met JIT-code werken, en vziw is die conversie niet het stuk wat het grote risico met zich mee brengt.

Trouwens, ik denk dat er toch wel een voordeel mee te halen is qua veiligheid: eval-statements worden nu pas echt traag

[sirdupre]

Maar DEP werkt toch juist niet in combinatie met JIT, of ben ik nou gek? Volgens mij is het principe van JIT dat je in plaats van de javascript te interpreteren deze naar machine code compileert, die dus ergens in het programmageheugen van de browser terecht komt. Om deze uit te voeren wordt vervolgens het geheugenadres van de gecompileerde code in het programmapointer register van de uitvoerende thread gezet en wordt de code uitgevoerd. Als DEP aanstaat krijg je echter het probleem dat dit gedeelte van het geheugen niet als programmageheugen staat gemarkeerd, maar als datageheugen en de processor dus zal weigeren de gecompileerde code uit te voeren.

Ik kan me in elk geval herinneren dat toen ik onder Windows XP een streng DEP beleid voor alle programma's had ingesteld, dat ik voor bijvoorbeeld de Java Virtual Machine en de Glasgow Haskell Interpreter (die ook met JIT werkt, jawel) DEP uit moest zetten omdat ze het anders niet deden.

[Verwijderd]

Je kan ook geheugen alloceren waar je wel mag schrijven en executen tegelijk. Die problemen met Windows waren alleen met oude programma's die niet netjes geprogrammeerd waren, waardoor ze in de problemen kwamen toen opeens W^X wel geforceerd werd.

[MSalters]

Je bent niet gek. Ik vermoed alleen dat je geen concrete ervaring met DEP hebt. DEP staat geen gelijktijdige Write en Execute bits toe. Je moet dus simpelweg twee bits omzetten nadat je code hebt gecompileerd. DEP beschermt je toch omdat alleen eerder gecompileerde code die bits kan omzetten, niet de nieuw gecompileerde code.

Een JVM of Haskell Interpreter die de Write/Exceute bits incorrect zet is knullig geprogrammeerd, en DEP beschermt je dus terecht tegen dat soort knoeiers. Runtimes die dit soort elementaire zaken vergeten horen niet op productieomgevingen.

@DOT: Zelfs als je het kunt, zet nooit de Write en Execute bits tegelijkertijd. Of je schrijft nieuwe code, of je executeert code, maar self-modifying code is tegenwoordig niet meer nodig.

[Springuin]

Inderdaad, code van het web die naar native code compileert? Toch wel een soort van spelen met vuur lijkt me...

[_Thanatos_]

Waarom? Het maakt niet uit hoe een bepaalde functionaliteit wordt uitgevoerd, uiteindelijk MOET het native code zijn, anders snapt je CPU het niet. Dus of je nou regel voor regel naar native code omzet en uitvoert, of voor een heel script in 1 keer. Boeit het?

Java(-applets) doen dit al jaren trouwens.

[Verwijderd]

bizarre snelheidsverbetering. In sommige gevallen zelfs 40 keer sneller.

bron

[Verwijderd]

Ik lees hier en daar wat kritiek op javascript als taal. Hebben die mensen maar de helft van JS begrepen? Javascript is imho een van de meest underrated programmeertalen. Het zit echt goed in elkaar.

[user109731]

Dit is erg interessant voor de mobiele markt, waar Mozilla zich ook op wil richten. Zeker op telefoons zal zo'n snelheidswinst op websites als GMail goed te merken zijn denk ik.

Erg mooi is ook dat dit de snelheid van de browser en addons ten goede komt. Nu kunnen ze in de browser zelf meer code in JavaScript schrijven, dat maakt het ook weer veiliger.

[Cameleon73]

Erg mooi! Ik vond dat de Javascript prestatie's in FF3 al aardig vooruit gegaan waren. Jammer genoeg heb je te maken met verschillende browses ... dus kan je de FF3 (en zeker de Tracemonkey) prestatie's niet als baseline gebruiken. Nou ja, daarvoor hebben we IE ...

[Verwijderd]

Netjes! Nou was firefox natuurlijk als één van de browsers met de beste geheugen prestaties, maar javascript was toch vaak nog wel een probleem (ook in andere browsers overigens).

[roy-t]

Huh Firefox had toch juist het slechtste geheugen prestaties? Vooral bij meerdere tabbladen waar IE (en vooral Opera) had echt significant beter deden.

Hmm het wordt tijd voor het opzoeken van een test of een test door t.net.

[HolaGanz]

Zeker niet:

nieuws: Test: Firefox 3 heeft minste geheugenhonger - update

[OddesE]

Firefox 2 was wel redelijk slecht met geheugen, maar niet veel slechter dan IE, die lekte ook als een mandje. Ik geloof dat ze nu FF2 ook verbeterd hebben.

[Verwijderd]

Firefox heeft nogsteeds de slechtste geheugenprestaties, weet het nu alleen te maskeren. Beetje lullig van de ontwikkelaars.

[iKiddo]

ROFLMAO

Alsof ze nu effies kernel hooks hebben zodat alle geheugen-meet-programma's lekker stiekem niet gaan laten zien dat Firefox eigenlijk veul meer geheugen gebruikt dan er staat.

Haha, hoe kun je geheugenprestaties nou weer maskeren. Het wordt beter, of niet. Een tussenweg lijkt mij niet mogelijk.