javascript - attribute - title html
Ventajas de los motores de Javascript (4)
Existen varios enfoques para la ejecución de JavaScript, incluso cuando se ejecuta JIT. V8 y Nitro (anteriormente conocido como SquirrelFish Extreme) eligen hacer un JIT de método completo, lo que significa que compilan todos los códigos de JavaScript siguiendo instrucciones nativas cuando encuentran secuencias de comandos, y luego simplemente lo ejecutan como si se tratara de código C compilado. SpiderMonkey utiliza en su lugar un JIT de "rastreo", que primero compila el script para que lo transmita e interprete, pero supervisa la ejecución, buscando "puntos calientes" como bucles. Cuando detecta uno, compila solo esa ruta caliente al código de máquina y lo ejecuta en el futuro.
Ambos enfoques tienen ventajas y desventajas. El JIT de método completo garantiza que todo el código JavaScript que se ejecuta se compilará y ejecutará como código de máquina y no se interpretará, lo que en general debería ser más rápido. Sin embargo, dependiendo de la implementación, puede significar que el motor dedique tiempo a compilar código que nunca se ejecutará, o solo se puede ejecutar una vez, y no es crítico para el rendimiento. Además, este código compilado debe almacenarse en la memoria, por lo que esto puede conducir a un mayor uso de la memoria.
El JIT de rastreo implementado en SpiderMonkey puede producir código extremadamente especializado en comparación con un JIT de método completo, ya que ya ha ejecutado el código y puede especular sobre los tipos de variables (como tratar la variable de índice en un bucle for como un entero nativo) ), donde un JIT de método completo tendría que tratar la variable como un objeto porque JavaScript está sin tipo y el tipo podría cambiar (SpiderMonkey simplemente se "caerá" de rastreo si la suposición falla, y volverá a interpretar bytecode). Sin embargo, el JIT de rastreo de SpiderMonkey actualmente no funciona de manera eficiente en código con muchas ramas, ya que las trazas están optimizadas para rutas de ejecución únicas. Además, hay una sobrecarga implicada en la supervisión de la ejecución antes de decidir compilar una traza y luego cambiar la ejecución a esa traza. Además, si el rastreador hace una suposición que luego se viola (como un tipo de cambio de variable), es probable que el costo de la caída del rastreo y el cambio a la interpretación sea mayor que con un JIT de método completo.
Estoy confundido acerca de los motores de JavaScript en este momento. Sé que V8 era un gran problema porque compilaba JavaScript con código nativo.
Luego comencé a leer sobre Mozilla SpiderMonkey , que por lo que entiendo está escrito en C y puede compilar JavaScript. Entonces, ¿cómo es esto diferente de V8 y si esto es cierto, por qué Firefox no hace esto?
Finalmente, ¿compila Rhino literalmente el código de bytes de JavaScript a Java para que pueda obtener todas las ventajas de velocidad de Java? Si no es así, ¿por qué las personas no ejecutan V8 cuando escriben scripts en sus escritorios?
Para responder la pregunta, ¿por qué el código nativo Vs Byte ...
El código nativo es más rápido y para Google una opción estratégica porque tienen planes para JS, uno de ellos al menos es ChromeOS.
Un buen video sobre esta pregunta se publica en Channel9 con una entrevista con Lars Bak. El hombre detrás de V8 se puede encontrar here
Si desea ver cómo se acumulan los distintos motores Javascript en el navegador, instale Safari 4 (sí, también se ejecuta en Windows ahora), Chrome V8, Firefox 3.5 e IE 8 (si está en Windows) y ejecute el benchmark :
http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
Creo que, como dijo Pointy anteriormente, el nuevo Firefox 3.5 usa TraceMonkey que también compila código de intermediario sobre la marcha utilizando algún tipo de JIT. Por lo tanto, debería compararse con V8 de manera un tanto favorable. Al menos no será 10 veces más lento que V8 como lo fue Firefox 3 SpiderMonkey (sin JIT).
Para mí ... safari 4.0.3 era 2.5 veces más rápido que Tracemonky en Firefox 3.5.3 en Win XP. IE8 fue mucho más lento. No tengo Chrome instalado en este momento.
No sé sobre la compilación de Rhino a bytecode java. Si todavía está interpretando las características dinámicas de Javascript, como poder agregar atributos a instancias de objeto en tiempo de ejecución (ejemplo obj.someNewAttribute = "someValue", que está permitido en Javascript) ... no estoy tan seguro de que esté completamente "compilado" "a bytecode, y es posible que no obtenga un mejor rendimiento que el que no tiene que compilar a partir del texto del código fuente de Javascript cada vez que se ejecuta su Javascript. Recuerde que Javascript permite una sintaxis muy dinámica como eval ("x = 10; y = 20; z = x * y"); lo que significa que puede construir cadenas de código que se compilan en el tiempo de ejecución. Es por eso que creo que Rhino sería interpretado / compilado en modo mixto, incluso si compiló código byte de JVM.
La JVM sigue siendo un intérprete, aunque muy bueno con el soporte de JIT. Así que me gusta pensar en Rhino-on-JVM como 2 capas de intérprete (intérprete-en-intérprete) o intérprete ^ 2. Mientras que la mayoría de sus otros motores Javascript están escritos en C, y como tales deberían interpretarse más como intérprete ^ 1. Cada capa de intérprete puede agregar una degradación de rendimiento de 5-10x en comparación con C o C ++ (ref. Perl o Python o Ruby, por ejemplo), pero con JIT, el rendimiento puede ser mucho menor del orden de 2-4x. Y la JVM tiene uno de los motores JIT más robustos y maduros de la historia.
Por lo tanto, su kilometraje definitivamente variará y probablemente se beneficie de hacer algunos benchmarks serios si quiere una respuesta real para su aplicación prevista en su propio hardware y sistema operativo.
Rhino no puede ser demasiado lento, ya que sé que mucha gente lo está usando. Creo que su principal atractivo no es su velocidad, sino el hecho de que es fácil de codificar / ligero / incrustable / intérprete que tiene ganchos en las bibliotecas de Java, lo que lo hace perfecto para la creación de scripts / configuración / extensibilidad de su proyecto de software. Algunos editores de texto como UltraEdit incluso están incorporando Javascript como un motor de macro scripting alternativo. Todos los programadores parecen ser capaces de tropezar a través de JavaScript con bastante facilidad, por lo que es fácil de recuperar también.
Una de las ventajas de Rhino es que se ejecuta prácticamente en cualquier lugar donde se ejecute la JVM. En mi experiencia, intentar conseguir que TraceMonkey o SpiderMonkey autónomos se construyan y ejecuten desde la línea de comandos puede ser un poco doloroso en sistemas como Windows. Y la incrustación en su propia aplicación puede consumir aún más tiempo. Pero la recompensa por tener un lenguaje incrustado valdría la pena para un gran proyecto, en comparación con tener que "rodar tu propio" mini scripting solution si eso es lo que estás buscando hacer.
La creación de secuencias de comandos con Rhino es realmente fácil si tiene Java y el jarro de rinoceronte, simplemente escriba su javascript y ejecútelo desde la línea de comandos. Lo uso todo el tiempo para tareas simples.
V8 es el más rápido, porque compila todos los códigos JS a máquina.
SpiderMonkey (lo que FF usa) también es rápido, pero se compila en un código de byte intermedio, no en un código de máquina. Esa es la gran diferencia con V8. EDITAR- Los lanzamientos más nuevos de Firefox vienen con una variante más nueva de SpideMonkey; TraceMonkey. TraceMonkey hace compilación JIT de partes críticas, y tal vez otras optimizaciones inteligentes.
Rhino compila Javascript en clases de Java, lo que le permite básicamente escribir aplicaciones "Java" en Javascript. Rhino también se usa como una forma de interpretar JS en el backend y manipularlo, y tener una comprensión completa del código, como la reflexión. Esto es usado, por ejemplo, por el compresor YUI.
La razón por la que se utiliza Rhino en lugar de V8 en todas partes es probablemente porque V8 es relativamente nuevo, por lo que muchos proyectos ya han utilizado Rhino / Spidermonkey como su motor JS, por ejemplo, widgets de Yahoo. (Supongo que eso es a lo que se refiere con "scripts en sus escritorios")
edit- Este enlace también puede dar una idea de por qué SpiderMonkey es tan ampliamente adoptado. ¿Qué motor Javascript insertarías en tu aplicación?