Mozilla ha integrato in SpiderMonkey (il suo motore JavaScript) alcune ottimizzazioni che ne hanno accresciuto le performance in determinati contesti di un fattore tra 20x e 40x. Queste ottimizzazioni includono l’utilizzo di un compilatore Just-In-Time (JIT) e l’adozione di una tecnica sviluppata presso l’University of California, Irvine chiamata “trace trees” che consente di “riciclare porzioni di codice da eseguire”, migliorando in maniera sensibile i tempi di esecuzione.
Il CTO di Mozilla Brendan Eich (padre di JavaScript) e il vice presidente del reparto ingegneristico di Mozilla, Mike Shaver, hanno affermato che queste ottimizzazioni “porteranno le performance JavaScript al prossimo livello” e “faranno in modo che la gente veda JavaScript come un linguaggio più generico (general purpose)”. L’obiettivo ultimo è quello di rendere l’esecuzione di codice JavaScript veloce quanto quella di codice C.
Un video dimostrativo è disponibile a questo indirizzo mentre i blog di Eich e Shaver offrono benchmark ed approfondimenti sull’argomento.
via | Slashdot
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
Conad il Rabarbaro
26 ago 2008 - 00:57 - #1“L’obiettivo ultimo è quello di rendere l’esecuzione di codice JavaScript veloce quanto quella di codice C.”
Un bel proposito, ma io ci credo poco. Alla fine hai sempre tra le scatole una vm che esegue il codice compilato dal jit.
Invece, un programma C compilato ha solo il S.O. tra le scatole (se trascuriamo la cosa che sta tra la tastiera e la sedia, ma questo è un problema comune a tutti i programmi).
Però mi auguro arrivino a dei buoni risultati…
tteo
26 ago 2008 - 04:38 - #2Beh, in alcune situazioni Java è più veloce dei programmi in c… e questo per due motivi principalI: la gestione della memoria e la possibilità di fare profiling e ottimizzare meglio il codice.
Concordo però che sarà difficile (e inutile) che programmi in javascript abbiano una tale velocità!
Aska
26 ago 2008 - 08:57 - #3se js diventa più veloce, migliorano le performance di siti con tabelline da 4.000 righe che eseguono js su ogni riga. o sbaglio?
@go
26 ago 2008 - 09:37 - #4Complimenti davvero se ci riescono.
albertino80
26 ago 2008 - 09:42 - #5tteo,
1 java != javascript
2 java è scritto in c, quindi per ciascun algorimo esisterà sempre una implementazione c almeno veloce quanto quella java
3 possiamo dire che il codice delle implementazioni java sono più brevi o leggibili…
anche se con tutti gli i framework di astrazione che vanno di moda oggi avrei qualcosa da dire sulla brevità o semplicità…
spidernik84
26 ago 2008 - 10:09 - #6Penso che l’esecuzione di JS sia il tallone d’achille di FF in ambiente linux. All’apertura delle pagine pesantemente scriptate si vedono picchi paurosi della cpu.
Speriamo che il buon lavoro fatto in termini prestazionali con FF3 si completi con questi accorgimenti.
DevURandom
26 ago 2008 - 10:18 - #7@Aska
sbagli.. il javascript piu’ veloce serve per fare andare meglio applicazioni come google maps oppure
http://www.gwt-ext.com/demo/
Fabioo
26 ago 2008 - 11:34 - #8#5 : tutto vero quello che dici, ma la compilazione JIT di Java permette di ottenere(almeno teoricamente) prestazioni migliori di UN EQUIVALENTE algoritmo C per via del profiling(come già detto nel commento #2)
Fabioo
26 ago 2008 - 11:36 - #9sempre #5 : come la metti tu sembra che ogni programma Java venga tradotto in C e quindi compilato… fosse così avresti ragione sul fatto che per ogni prog Java ne esiste uo C migliore.
Tornando IT, se JS migliora => le applicazioni Ajax possono migliorare.
Michele Artoni
26 ago 2008 - 15:04 - #10Per ogni programma in java ne esiste SEMPRE uno in c altrettanto veloce, nel caso limite scrivi un interprete java e lo usi per eseguire il tuo programma.
albertino80
26 ago 2008 - 15:05 - #11scusa se insisto (poi chiudo).
nessuno mi vieta di scrivere un sw in c che esegue le stesse operazioni in modi diversi e un algoritmo che decide volta per volta qual’è la migliore opzione in base a
variabili, sistema, carico cpu, traffico rete, ecc…
ripeto al massimo mi puoi dire che è più lungo da scrivere… ma nella pratica questa toeria si affema molto più semplicemente (basta compare una app java con una c, che in teoria dovrebbero essere comparabili, ma nella pratica…)
Scusa se sono andato così OT.
Ciao
fabio.80
26 ago 2008 - 16:16 - #12infatti, la frase > è *concettualmente* inoppugnabile. credo che Fabioo si sia spinto un po’ troppo in là con l’interpretazione ;-)
spero che l’interprete js cresca sempre più in termini di prestazioni, perché oramai js è un po’ come il prezzemolo, soprattutto nei siti più avanzati
fabio.80
26 ago 2008 - 16:26 - #13scusatemi, ho inserito il segno di minore doppio per iniziare la citazione ed è stata tagliata la frase. sostituire “almeno veloce quanto” a “>”
pardon :p
guiodic
27 ago 2008 - 12:59 - #14@spidernik: non ho la tua stessa impressione. Comunque già attualmente FF3 è il browser più veloce nell’esecuzione di JS come dimostrano diversi test (a partire da quello di Apple-webkit).
Aska
27 ago 2008 - 15:15 - #15@spidernik: Da quello che posso constatare quotidianamente, FF2 e FF3 sono nettamente più veloci di IE5.5 e IE6 nell’elaborazione di pagine web con tabelle da 2000 - 4000 righe con js su ogni riga. (l’utente non vuole la paginazione su quelle tabelle).
qui internet explorer 7 non lo posso installare (grazie alle strategie microsoft) perchè ho windows2000.
Quindi tra l’altro è un bene che FF continui ad essere compatibile anche con windows2000.