Mozilla voegt JavaScript-optimalisatiemodule toe aan Firefox-nightly
Mozilla heeft de OdinMonkey-optimalisatiemodule voor JavaScript toegevoegd aan de laatste nightly build van Firefox. Volgens Mozilla kunnen de JavaScript-prestaties de prestaties van native code benaderen als developers C- of C++-code laten compileren door OdinMonkey.
De OdinMonkey-engine, die gebruik maakt van asm.js, kan 'low-level' JavaScript-code genereren dankzij ondersteuning voor de emscripten-compiler voor JavaScript. Deze compiler accepteert C- en C++-code, en laat deze draaien in een veilige JavaScript-sandbox. Door de optimalisaties van asm.js komen de prestaties van OdinMonkey-scriptcode volgens Mozilla dicht in de buurt van native code.
Volgens benchmarks zouden de prestaties een factor twee langzamer zijn, terwijl de huidige JavaScript-engines in Chrome en Firefox vele malen langer doen over het verwerken van de code. OdinMonkey moet het onder andere voor gamedevelopers mogelijk maken om complexere games te bouwen die in een webbrowser kunnen draaien.
Volgens Mozilla is een groot voordeel van de OdinMonkey-implementatie, naast de aanzienlijke snelheidswinst, dat JavaScript-code in andere browsers gewoon kan blijven draaien. De huidige implementatie van asm.js is opgenomen in de laatste nightly build van Firefox. Deze is beschikbaar voor de 32bit- en 64bit-versies van Firefox voor Windows en Linux. Testversies voor OS X en Firefox on ARM zijn in aantocht. Naar verwachting gaat OdinMonkey deel uitmaken van Firefox 22. Deze staat voor een release in juni op de agenda.
Reacties (25)
Cool, ik gebruik nightly dus dit zal er wel inzitten als ik vanmiddag/vanavondijn pc opstart. Offtopic: moet denk ik 64 ipv 6 bit zijn 
Het zal er wel in zitten, maar je hebt er niks aan behalve als je specifiek modules schrijft die "use asm"; gebruiken. En het feit is dat dat er momenteel nog praktisch geen zijn.
Wat ik me wel afvraag... is of dit wel of niet potentieel security implicaties heeft? Aan de ene kant klinkt dit alsof ze een volledig alternatieve compiler hebben die volledig anders werkt, wat potentieel veel trouble met zich mee kan brengen.
En daarnaast, dit gaat dus volledig in tegen de ECMAscript standaard, want het ziet er wel uit als javascript enzo, maar het is plotseling static typed en zelfs de variable types zijn niet exact hetzelfde.
Oh en trouwens, als je emscripten niet kent dan is dat echt een aanrader om te bekijken. De eerste keer dat ik die tegen kwam stond ik gewoon met open mond te gapen O:)
Wat ik me wel afvraag... is of dit wel of niet potentieel security implicaties heeft? Aan de ene kant klinkt dit alsof ze een volledig alternatieve compiler hebben die volledig anders werkt, wat potentieel veel trouble met zich mee kan brengen.
En daarnaast, dit gaat dus volledig in tegen de ECMAscript standaard, want het ziet er wel uit als javascript enzo, maar het is plotseling static typed en zelfs de variable types zijn niet exact hetzelfde.
Oh en trouwens, als je emscripten niet kent dan is dat echt een aanrader om te bekijken. De eerste keer dat ik die tegen kwam stond ik gewoon met open mond te gapen O:)
Zover ik begrepen heb is het gewoon backwards compatible met standaard JS, alleen mag je nog maar een beperkt aantal constructies gebruiken waardoor het veel makkelijker te optimaliseren is.
Klopt absoluut dat het 'backwards' compatible is, maar wat ze doen gaat veel verder dan "makkelijker optimaliseren", ze compileren het geheel voordat je de pagina gebruikt in tegenstelling van wat je met javascript doet, namelijk dat je een JIT compiler hebt, die terwijl je de code draait hem compileerd. En het gaat op zich wel degelijk tegen ECMA in, omdat als je var a = 3.0+1; schrijft met "use asm"; erboven, dan loopt hij daar op stuk.
Niet echt. Odinmonkey gaat niet blind er van uit dat "use asm" klopt. De "use asm" module wordt eerst gecontroleerd. Dan komt er in de javascript console een melding dat die var a = 3.0+1; regel niet aan de asm.js spec voldoet en wordt het geheel alsnog door de normale javascript engine afgehandeld.En het gaat op zich wel degelijk tegen ECMA in, omdat als je var a = 3.0+1; schrijft met "use asm"; erboven, dan loopt hij daar op stuk.
[Reactie gewijzigd door _V_ op vrijdag 22 maart 2013 15:34]
Firefox on ARM? Klinkt interessant, zou fijn zijn als ik gewoon Firefox onder Windows RT kan gebruiken! Voor Android is al een ARM versie van Firefox, dus de naam is wel wat onduidelijk.
Edit: Dit ging dus over de android-versie, waar een testversie met de nieuwe OdinMonkey voor uit komt. Firefox komt niet op Windows RT vanwege een verbod vanuit Microsoft.
Edit: Dit ging dus over de android-versie, waar een testversie met de nieuwe OdinMonkey voor uit komt. Firefox komt niet op Windows RT vanwege een verbod vanuit Microsoft.
[Reactie gewijzigd door Niet Henk op vrijdag 22 maart 2013 13:13]
Windows RT ondersteund geen 'externe software' buiten het spul voor de Metro interface om, wat in HTML5 of een gelimiteerde .NET omgeving (afaik) moet gemaakt worden.
Als dit betekend dat firefox wat sneller word, sta ik en ik denk meerdere mensen er open voor
Deze ontwikkeling zelf zorgt er niet direct voor dat Firefox zelf sneller wordt, hooguit vanwege optimalisaties in de IonMonkey JIT-compiler en het gevolg dat JavaScript in de chrome-laag sneller zal gaan werken.
Op dit moment is Firefox (Gecko) geschreven in C/C++ met het front-end in XUL/CSS en JavaScript. Wat mogelijk wel een interessante use case kan zijn is het schrijven van meer performance-kritieke code, die nu in 100% JavaScript geschreven is, in C/C++ en dan te compileren naar de asm.js-subset van JavaScript. Helaas kan ik zo niet 1-2-3 verzinnen welk deel dat dan zou zijn van de JavaScript die in chrome en add-ons gebruikt wordt...
Op dit moment is Firefox (Gecko) geschreven in C/C++ met het front-end in XUL/CSS en JavaScript. Wat mogelijk wel een interessante use case kan zijn is het schrijven van meer performance-kritieke code, die nu in 100% JavaScript geschreven is, in C/C++ en dan te compileren naar de asm.js-subset van JavaScript. Helaas kan ik zo niet 1-2-3 verzinnen welk deel dat dan zou zijn van de JavaScript die in chrome en add-ons gebruikt wordt...
Browsers als OS / VM / Sandbox... Toch slim dat Google, Chrome OS voor ogen had jaren geleden
Even kijken of ik het snap:
- OdinMonkey heeft los van de browser een tool die C++ omzet naar JavaScript
- De nieuwe Firefox met OdinMonkey support draait deze javascript bijna even snel als dat de C++ zou draaien op deze machine
Bottom line
- Voordeel is dus dat, als je in C++ ontwikkelt, je software erg snel in de browser kan draaien dankzij OdinMonkey
- Dit zegt niets over de snelheid waarmee huidige Javascript code door Firefox uitgevoerd wordt.
- Oftewel: dit helpt alleen bij nieuwe ontwikkeltrajecten, niet bij bestaande sites.
Klopt dit?
- OdinMonkey heeft los van de browser een tool die C++ omzet naar JavaScript
- De nieuwe Firefox met OdinMonkey support draait deze javascript bijna even snel als dat de C++ zou draaien op deze machine
Bottom line
- Voordeel is dus dat, als je in C++ ontwikkelt, je software erg snel in de browser kan draaien dankzij OdinMonkey
- Dit zegt niets over de snelheid waarmee huidige Javascript code door Firefox uitgevoerd wordt.
- Oftewel: dit helpt alleen bij nieuwe ontwikkeltrajecten, niet bij bestaande sites.
Klopt dit?
Odinmonkey is een implementatie van asm.js.
De tool die C++ code naar js code omzet heet emscriptem. hiermee kan je bestaande projecten in de browser laten draaien.
ja, zoals ik het begrijp klopt dat.
De tool die C++ code naar js code omzet heet emscriptem. hiermee kan je bestaande projecten in de browser laten draaien.
ja, zoals ik het begrijp klopt dat.
Enige wat niet klopt is de indruk dat asm.js een noodzakelijk deel hiervan is. Emscripten werkt dus net zo goed zonder asm.js, en asm.js samen met OdinMonkey zorgen er dus voor dat *nieuwe* emscripten compilaties die gebruik maken van asm.js veel sneller draaien.
En voor bestaande ontwikkeltrajecten helpt het alleen als je bijvoorbeeld een heel zware wiskundige berekening doet en die heel specifiek in een asm.js module stopt zodat ie sneller zal draaien in firefox.
En voor bestaande ontwikkeltrajecten helpt het alleen als je bijvoorbeeld een heel zware wiskundige berekening doet en die heel specifiek in een asm.js module stopt zodat ie sneller zal draaien in firefox.
https://blog.mozilla.org/...efox-nightly/#comment-576
Volgens deze ontwikkelaar helpt het project wel bij het verder optimaliseren van ionmonkey, dus wat dat betreft helpt het indirekt wel bij bestaande sites
Volgens deze ontwikkelaar helpt het project wel bij het verder optimaliseren van ionmonkey, dus wat dat betreft helpt het indirekt wel bij bestaande sites
Toch slim van IBM en kornuiten die dat met de mainframes voor ogen hadden deccenia geleden 
Daar wordt een stap over geslagen; de C/C++ wordt naar een javascript subset vertaald/gecompileerd (door bijvoorbeeld emscripten). Deze subset is gespecifeerd als asm.js. Dus je zou ook zonder tussenkomst van emscripten direct javascript kunnen schrijven die aan de specificatie voldoet.als developers C- of C++-code laten compileren door OdinMonkey.
Odinmonkey heet niet asm.js. asm.js is de "'low-level' JavaScript-code" die gegenereerd kan worden door emscripten. Odinmonkey test of de javascript aan de spec voldoet en, zo ja, zorgt dat deze Ahead of Time (AOT) ipv Just-In-Time (JIT) gecompileerd wordt.De OdinMonkey-engine, asm.js geheten, kan 'low-level' JavaScript-code genereren
De asm.js javascript code kan in andere javascript engines al voor een snelheidverbetering zorgen. Door AOT compilatie (door bijvoorbeeld Odinmonkey) kan die verbetering nog groter zijn.
Dat kan, maar is wel verre van praktisch. De subset is namelijk bijzonder strikt en beperkt, en om 't performant te maken maakt Emscripten gebruik van manual memory management (gemapped in een typed Array). Dus hoewel de syntax nog steeds JavaScript is, betekent het dat je met de hand asm.js-compliant code schrijven beter kunt vergelijken met handmatig assembly code schrijven dan JavaScript of zelfs C++ code schrijven.Dus je zou ook zonder tussenkomst van emscripten direct javascript kunnen schrijven die aan de specificatie voldoet.
Ik snap geen hout van dit artikel, moet maar even het bron artikel lezen denk ik..
Maar hoe zorgt emscriptem er voor dat firefox sneller wordt? het vertaalt c/c++ code naar javascript, om native applicaties in de browser te draaien. Maar het kan er m.i. niet voor zorgen dat de browser zelf sneller wordt.
edit:
Even verder gelezen, en het is nogal onhandig verwoord in het artikel
asm.js is een subset van javascript (minder functionaliteit), zodat het uitvoeren van asm.js code beter geoptimaliseert kan worden.
Emscriptem is een compiler die compileert naar javascript, emscriptem heeft een compiler optie voor asm.js, zodat de code nog sneller uitgevoerd kan worden.
En odinmonkey is een implementatie van asm.js die firefox nu heeft toegevoegd.
Maar hoe zorgt emscriptem er voor dat firefox sneller wordt? het vertaalt c/c++ code naar javascript, om native applicaties in de browser te draaien. Maar het kan er m.i. niet voor zorgen dat de browser zelf sneller wordt.
edit:
Even verder gelezen, en het is nogal onhandig verwoord in het artikel
asm.js is een subset van javascript (minder functionaliteit), zodat het uitvoeren van asm.js code beter geoptimaliseert kan worden.
Emscriptem is een compiler die compileert naar javascript, emscriptem heeft een compiler optie voor asm.js, zodat de code nog sneller uitgevoerd kan worden.
En odinmonkey is een implementatie van asm.js die firefox nu heeft toegevoegd.
[Reactie gewijzigd door neoeldex op vrijdag 22 maart 2013 13:58]
Volgens benchmarks zouden de prestaties een factor twee langzamer zijn, terwijl de huidige JavaScript-engines in Chrome en Firefox vele malen langer doen over het verwerken van de code.
Dit is toch juist niet gunstig, of zie ik iets over het hoofd?
Dit is toch juist niet gunstig, of zie ik iets over het hoofd?
Volgens mij moet je dat lezen als: volgens de benchmarks is JS met deze nieuwe methode slechts twee keer langzamer dan Native. De bestaande JS engines zijn vele malen langzamer (20x langzamer? 200x langzamer?) dan Native.
Het originele artikel noemt 3 benchmarks:
"skinning":
native: 1.00x
OdinMonkey: 2.46x
SpiderMonkey: 12.90x
V8: 59.35x
"zlib":
native: 1.00x
OdinMonkey: 1.61x
SpiderMonkey: 5.15x
V8: 5.95x
"bullet":
native: 1.00x
OdinMonkey: 1.79x
SpiderMonkey: 12.31x
V8: 9.30x
"skinning":
native: 1.00x
OdinMonkey: 2.46x
SpiderMonkey: 12.90x
V8: 59.35x
"zlib":
native: 1.00x
OdinMonkey: 1.61x
SpiderMonkey: 5.15x
V8: 5.95x
"bullet":
native: 1.00x
OdinMonkey: 1.79x
SpiderMonkey: 12.31x
V8: 9.30x
Top. Ik kon al geen wijs maken uit de benchmark-referentie...
Dit zat er al aan te komen, flash vervalt als standaard. Uitbreiding van javascript is een goed alternatief, op 1 ding na de sourcecode is gewoon zichtbaar
Wat is daar mis mee? Mensen stellen zich vaak voor dat hun code zo bijzonder of knap is, maar bij de meeste software kan een knappe programmeur gewoon door de werking ervan te kijken het eenvoudig nabouwen. Verder is het voor beveiliging van dingen ook niet nadelig, want dat open source software net zo veilig kan zijn bewijzen Mozilla en Linux dagelijks.
Nabouwen is niet zo'n probleem echter het kopiëren wel. Als jij daar vele uurtjes in heb zitten om het zo te maken als jij wilt is het nogal zuur dat iemand dat klakkeloos zou kopiëren. Leren is niet erg maar je moet het wel zelf maken.
@reconx86: Flash code (ActionScript) is in vele gevallen nog gemakkelijk leesbaar als je een decompiler gebruikt (zelfs met commentaar, plaatjes etc). Dus wat dat betreft zou je beter af zijn met javascript en bijvoorbeeld de Google enclosure compiler.
Wat open source betreft, heb je wel gelijk in maar uiteindelijk is het gecompileerde code wat moeilijker te analyseren is. En wanneer het om beveiliging gaat zit deze beveiliging niet aan de client/front-end zijde. Er zit meestal nog een extra 'deurtje' voor.
@reconx86: Flash code (ActionScript) is in vele gevallen nog gemakkelijk leesbaar als je een decompiler gebruikt (zelfs met commentaar, plaatjes etc). Dus wat dat betreft zou je beter af zijn met javascript en bijvoorbeeld de Google enclosure compiler.
Wat open source betreft, heb je wel gelijk in maar uiteindelijk is het gecompileerde code wat moeilijker te analyseren is. En wanneer het om beveiliging gaat zit deze beveiliging niet aan de client/front-end zijde. Er zit meestal nog een extra 'deurtje' voor.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
