Recuerdo que un profesor dijo una vez que el código interpretado era aproximadamente 10 veces más lento que el compilado. ¿Cuál es la diferencia de velocidad entre interpretado y bytecode? (suponiendo que el bytecode no está compilado JIT)Bytecode vs. Interpretado
Lo pregunto porque algunas personas han estado dando vueltas a la idea de compilar vim script en bytecode y me pregunto qué tipo de impulso de rendimiento obtendrá.
Cuando compila las cosas en bytecode, tiene la oportunidad de realizar primero un montón de costosas optimizaciones de alto nivel. El diseño del código de bytes es muy que se compila fácilmente en el código de máquina y ejecuta todas las optimizaciones y análisis de flujo con anticipación.
El aumento de velocidad es, por tanto, potencialmente bastante importante: no solo omite las etapas de lectura/análisis en tiempo de ejecución, sino que también tiene más oportunidades de aplicar optimizaciones y generar mejores códigos de máquina.
Basado en lo que hace Java (la plataforma basada en códigos bytes más extendida), está completamente equivocado. Se realiza muy poca optimización durante la compilación del código fuente; la gran mayoría de la optimización es realizada por el compilador JIT, y la JVM es una arquitectura basada en pila que no se adapta muy bien a los conjuntos de instrucciones del mundo real. –
No pregunta por Java, pregunta sobre bytecode en general. Pasar de un intérprete a un bytecode/JIT brinda la oportunidad de realizar optimizaciones anticipadas y seleccionar un bytecode que se corresponda bien con el lenguaje de la máquina. Los diseñadores de Java tenían razones para elegir el bytecode que tenían, pero esa no es la única forma de hacerlo. – Eclipse
Podría ver un impulso bastante bueno. Sin embargo, hay muchos factores. No puede simplemente decir que el código compilado es siempre aproximadamente 10 veces más rápido que el código interpretado, o que el bytecode es n veces más rápido que el código interpretado.
Los factores incluyen la complejidad y la verbosidad del idioma, por ejemplo. Si una palabra clave en el idioma es varios caracteres, y el bytecode es uno, debería ser bastante más rápido cargar el bytecode, y saltar a la rutina que maneja ese bytecode, que leer la palabra clave string, luego descifrar dónde ir. Pero, si está interpretando uno de los idiomas exóticos que tiene una palabra clave de un byte, la diferencia podría ser menos notoria.
He visto este aumento de rendimiento en la práctica, por lo que podría valer la pena para usted. Además, es divertido escribir tal cosa, te da una idea de cómo funcionan los intérpretes de lenguaje y los compiladores, y eso te convertirá en un mejor codificador.
¿Dónde comenzaría uno? Escribí un compilador en la universidad pero era para un lenguaje realmente simple y no puedo ni imaginarme escribiendo un intérprete de código de bytes. – Whaledawg
La mayor parte del trabajo difícil va a ser compilar en primer lugar el código de bytes; después de eso, su intérprete será poco más que una máquina de estado glorificada. Simplemente use bytecode directamente para indexar en un conjunto de rutinas. Solo será difícil si quieres JIT. – Eclipse
Realmente no puedo darle consejos actuales sobre esto: escribí un compilador que compilaba a bytecode en los años 80 en algún momento, y que estaba en ensamblador 6502 en un Ohio Scientific C1P. Entonces, las cosas pueden haber cambiado sinusoidal;) –
Está de acuerdo con su máquina virtual. Algunas de sus máquinas virtuales más rápidas (JVM) se están acercando a la velocidad del código C. Entonces, ¿qué tan rápido se ejecuta el código interpretado en comparación con C?
No crea que si convierte su código interpretado en ByteCode funcionará tan rápido como Java (cerca de las velocidades C), ha habido años de aumento del rendimiento, pero debería ver un impulso de velocidad significativo.
Emacs ha sido portado en bytecode con un mayor rendimiento. Puede valer la pena mirarlo.
Nunca he notado un script de Vim que fue lo suficientemente lento como para notarlo. Suponiendo que una secuencia de comandos llame principalmente a las operaciones incorporadas, de código nativo (expresiones regulares, operaciones de bloque, etc.) que se implementan en el núcleo del editor, incluso una aceleración de 10 veces de la 'lógica de pegamento' en la creación de scripts sería insignificante.
Aún así, la creación de perfiles es la única manera de estar realmente seguro.
¿Hay realmente algún "intérprete" convencional que actualmente no compile su código? (O a bytecode o algo similar.)
Por ejemplo, cuando utiliza un programa Perl directamente desde su código fuente, lo primero que hace es compilar el origen en un árbol de sintaxis, que luego optimiza y utiliza para ejecutar el programa. En situaciones normales, el tiempo dedicado a la compilación es muy pequeño en comparación con el tiempo que realmente se ejecuta el programa.
Siguiendo con este ejemplo, obviamente Perl no puede ser más rápido que el código C bien optimizado, ya que está escrito en C. En la práctica, para la mayoría de las cosas que normalmente haría con Perl (como procesamiento de texto), será como tan rápido como podría razonablemente codificarlo en C, y órdenes de magnitud más fáciles de escribir. Por otro lado, ciertamente no trataría de escribir una rutina matemática de alto rendimiento directamente en Perl.
Ruby 1.8 (MRI) utiliza un andador AST, no un bytecode. Sin embargo, todavía hace un análisis completo. –
Además, muchos intérpretes "clásicos" también incluyen la fase lex/parse junto con la ejecución.
Por ejemplo, considere ejecutar una secuencia de comandos de Python. Cuando lo hace, tiene todos los costos asociados con la conversión del texto del programa a las estructuras internas de datos del intérprete, que luego se ejecutan.
Ahora contraste esto con la ejecución de una secuencia de comandos compilada de Python, un archivo .pyc. Aquí, la fase de lex y parse está lista, y usted tiene solo el tiempo de ejecución del intérprete interno.
Pero si considera, por ejemplo, un intérprete BASIC clásico, estos nunca almacenan el texto en bruto, sino que almacenan un formulario tokenizado y vuelven a crear el texto del programa cuando hace "LISTAR". Aquí el código de bytes es mucho más crudo (aquí no tienes una máquina virtual), pero tu ejecución puede omitir parte del procesamiento de texto. Todo eso se hace cuando ingresas a la línea y presionas ENTER.
bytecode is interpreted. el código fuente vs bytecode sería mejor. –
código fuente, para mí, implica que debe compilarse. – Whaledawg
@Whaledawg byecode se puede compilar también. –