Motori JavaScript Vantaggi

Question

Sono confuso sui motori JavaScript in questo momento. So che V8 è stato un grosso problema perché ha compilato JavaScript nel codice nativo.

Poi ho iniziato a leggere su Mozilla SpiderMonkey, che da quello che ho capito è scritto in C e può compilare JavaScript. Quindi, com'è diverso dal V8 e se questo è vero, perché Firefox non lo fa?

Infine, lo Rhino compila letteralmente il codice byte JavaScript in Java in modo da ottenere tutti i vantaggi di velocità di Java? In caso contrario, perché le persone non eseguono V8 quando scrivono script sui loro desktop?

Answer 1

V8 è il più veloce, perché compila tutto il JS al codice macchina.

SpiderMonkey (ciò che FF utilizza) è troppo veloce, ma viene compilato su un byte-code intermedio, non su un codice macchina. Questa è la principale differenza con V8. MODIFICA - Le nuove versioni di Firefox sono disponibili con una variante più recente di SpideMonkey; TraceMonkey. TraceMonkey esegue la compilazione JIT di parti critiche e forse altre ottimizzazioni intelligenti.

Rhino compila le classi Javascript in Java, consentendo così di scrivere fondamentalmente applicazioni "Java" in Javascript. Rhino è anche usato come un modo per interpretare JS nel backend e manipolarlo, e avere una comprensione completa del codice, come la riflessione. Questo è usato ad esempio dal compressore YUI.

Il motivo per cui Rhino viene utilizzato al posto di V8 è probabilmente dovuto al fatto che V8 è relativamente nuovo, quindi molti progetti hanno già utilizzato Rhino/Spidermonkey come motore JS, ad esempio i widget di Yahoo. (Suppongo che sia ciò a cui ti stai riferendo con "script sui loro desktop")

edit- Questo collegamento potrebbe anche dare qualche idea del perché SpiderMonkey sia così largamente adottato. Which Javascript engine would you embed in your application?

Answer 2

Per rispondere alla domanda, perché il codice nativo Vs codice Byte ...

Il codice nativo è più veloce e per Google una scelta strategica perché hanno intenzione di JS uno di loro, almeno, è ChromeOS.

Un buon video a questa domanda è pubblicato su Channel9 con un colloquio con Lars Bak l'uomo dietro V8 può essere trovato here

Answer 3

Se volete vedere come i vari nel browser motori JavaScript stack up, installare Safari 4 (sì, funziona su Windows ormai troppo!), Chrome V8, Firefox 3.5 e IE 8 (se siete su Windows) ed eseguire il benchmark:

http://www2.webkit.org/perf/sunspider-0.9/sunspider.html

credo, come ha detto a punta sopra, la il nuovo Firefox 3.5 utilizza TraceMonkey che compila anche per l'intermediazione del codice al volo usando alcuni f orm di JIT. Quindi dovrebbe comparare a V8 in qualche modo favorevolmente. Almeno non sarà 10 volte più lento del V8 come lo era Firefox 3 SpiderMonkey (senza JIT).

Per me ... Safari 4.0.3 era 2.5 volte più veloce di Tracemonky in Firefox 3.5.3 su Win XP. IE8 era molto più lento. Al momento non ho installato Chrome.

Non conosco la compilazione di Rhino in codice byte java. Se sta ancora interpretando le caratteristiche dinamiche di Javascript come essere in grado di aggiungere attributi alle istanze dell'oggetto in fase di esecuzione (ad esempio obj.someNewAttribute = "someValue" che è consentito in Javascript) ...Non sono così sicuro che sia interamente "compilato" in bytecode, e potresti non ottenere prestazioni migliori se non che non devi compilare dal testo del codice sorgente di Javascript ogni volta che viene eseguito il tuo Javascript. Ricorda che Javascript consente la sintassi molto dinamica come eval ("x = 10; y = 20; z = x * y"); il che significa che puoi creare stringhe di codice che vengono compilate in fase di runtime. Ecco perché penserei che Rhino sia interpretato/compilato in modalità mista anche se hai compilato il bytecode JVM.

JVM è ancora un interprete, anche se molto buono con supporto JIT. Quindi mi piace pensare a Rhino-on-JVM come a 2 livelli interprete (interprete-interprete) o interprete^2. Mentre la maggior parte dei tuoi altri motori Javascript sono scritti in C, e come tale dovrebbe essere più simile all'interprete^1. Ogni livello di interprete può aggiungere un degrado delle prestazioni di 5-10 volte rispetto a C o C++ (ad esempio Perl o Python o Ruby), ma con JIT la performance può essere molto inferiore nell'ordine di 2-4x. E la JVM ha uno dei più robusti motori JIT & di sempre.

Quindi il tuo chilometraggio varierà sicuramente e probabilmente trarrai vantaggio da alcuni benchmark importanti se desideri una risposta reale per l'applicazione desiderata sul tuo hardware operativo &.

Rhino non può essere troppo terribilmente lento, dal momento che so che molti lo usano. Penso che l'attrattiva principale non sia la sua velocità, ma il fatto che sia facile da codificare/leggero/integrabile/interprete che ha accesso alle librerie Java, il che lo rende perfetto per lo scripting/configurazione/estensibilità del tuo progetto software. Alcuni editor di testo come UltraEdit incorporano anche Javascript come motore di scripting macro alternativo. Ogni programmatore sembra essere in grado di incappare in javascript abbastanza facilmente, quindi è facile da imparare.

Un vantaggio di Rhino è che viene eseguito praticamente ovunque venga eseguita la JVM. Nella mia esperienza, provare a ottenere TraceMonkey o SpiderMonkey stand-alone per creare & eseguire dalla riga di comando può essere un po 'doloroso su sistemi come Windows. E l'incorporamento nella tua applicazione può richiedere ancora più tempo. Ma il risarcimento per avere un linguaggio embeddabile varrebbe la pena per un grande progetto, rispetto alla necessità di dover eseguire il rollover della propria mini soluzione di scripting se è quello che stai cercando di fare.

Script con Rhino è davvero facile se si dispone di Java e del vaso di rhino, basta scrivere il javascript ed eseguirlo dalla riga di comando. Lo uso sempre per compiti semplici.

Answer 4

Ci sono vari approcci per l'esecuzione di JavaScript, anche quando si fa JIT. V8 e Nitro (precedentemente noto come SquirrelFish Extreme) scelgono di eseguire un JIT a intero metodo, il che significa che compilano tutto il codice JavaScript fino alle istruzioni native quando incontrano lo script, e quindi lo eseguono semplicemente come se fosse codice C compilato. SpiderMonkey usa invece una JIT "traccia", che prima compila lo script in bytecode e lo interpreta, ma monitora l'esecuzione, cercando "punti caldi" come loop. Quando ne rileva uno, compila solo quel percorso caldo per il codice macchina e lo esegue in futuro.

Entrambi gli approcci hanno aspetti positivi e negativi. Il metodo JIT a tutto campo garantisce che tutto il codice JavaScript che viene eseguito verrà compilato ed eseguito come codice macchina e non interpretato, il che, in generale, dovrebbe essere più veloce. Tuttavia, a seconda dell'implementazione, potrebbe significare che il motore spende il codice di compilazione del tempo che non verrà mai eseguito, o che può essere eseguito una sola volta e non è critico per le prestazioni. Inoltre, questo codice compilato deve essere archiviato in memoria, quindi questo può portare ad un maggiore utilizzo della memoria.

Il JIT di tracciamento implementato in SpiderMonkey può produrre codice estremamente specializzato rispetto a un JIT di intero metodo, poiché ha già eseguito il codice e può speculare sui tipi di variabili (come il trattamento della variabile di indice in un ciclo for come un intero nativo), dove un JIT dell'intero metodo dovrebbe trattare la variabile come un oggetto perché JavaScript non è tipizzato e il tipo potrebbe cambiare (SpiderMonkey semplicemente "cadrà" se l'ipotesi fallisce e ritorna all'interpretazione del bytecode) . Tuttavia, JIT di traccia di SpiderMonkey attualmente non funziona in modo efficiente sul codice con molti rami, in quanto le tracce sono ottimizzate per singoli percorsi di esecuzione. Inoltre, c'è un sovraccarico nel monitoraggio dell'esecuzione prima di decidere di compilare una traccia e quindi di passare all'esecuzione su quella traccia. Inoltre, se il tracciante fa un'ipotesi che viene successivamente violata (come un tipo che cambia la variabile), il costo di eliminare la traccia e di tornare all'interpretazione è probabilmente più alto che con un JIT dell'intero metodo.