performance - programacion - que es un interprete
¿Por qué los lenguajes interpretados son lentos? (15)
Estaba leyendo sobre los pros y los contras de los idiomas interpretados, y uno de los contras más comunes es la lentitud, pero ¿por qué son lentos los programas en idiomas interpretados?
Piense en el intérprete como un emulador de una máquina que no tiene
La respuesta corta es que los lenguajes compilados son ejecutados por instrucciones de la máquina mientras que los interpretados son ejecutados por un programa (escrito en un lenguaje compilado) que lee la fuente o un código de bytes y luego emula esencialmente una máquina hipotética que habría ejecutado el programa. directamente si la máquina existía.
Piense en el tiempo de ejecución interpretado como un emulador para una máquina que en realidad no tiene alrededor en este momento.
Esto es obviamente complicado por los compiladores JIT (Just In Time) que Java, C # y otros tienen. En teoría, son tan buenos como los compiladores "AOT" ("A la vez"), pero en la práctica esos lenguajes se ejecutan más lentamente y tienen una desventaja al necesitar que el compilador utilice la memoria y el tiempo en el tiempo de ejecución del programa. Pero si dice algo de eso aquí, así que prepárese para atraer a defensores rabiosos de JIT que insisten en que no hay una diferencia teórica entre JIT y AOT. Si les pregunta si Java y C # son tan rápidos como C y C ++, entonces comienzan a inventar excusas y se calman un poco. :-)
Por lo tanto, C ++ gobierna totalmente en los juegos donde siempre se puede utilizar la cantidad máxima de computación disponible.
En el escritorio y en la web, las tareas orientadas a la información a menudo las realizan los lenguajes con más abstracción o al menos menos compilación, porque las computadoras son muy rápidas y los problemas no son computacionales, por lo que podemos dedicar algo de tiempo a objetivos como el tiempo de - mercado, productividad del programador, entornos confiables seguros para la memoria, modularidad dinámica y otras herramientas poderosas.
Además de las otras respuestas, hay optimización: cuando compilas un programa, generalmente no te importa cuánto tiempo se tarda en compilar: el compilador tiene mucho tiempo para optimizar tu código. Cuando interpreta el código, debe hacerse muy rápidamente para que algunas de las optimizaciones más inteligentes no se puedan realizar.
Desde about.com :
Un lenguaje interpretado se procesa en tiempo de ejecución. Cada línea es leída, analizada y ejecutada. Tener que reprocesar una línea cada vez en un bucle es lo que hace que los idiomas interpretados sean tan lentos. Esta sobrecarga significa que el código interpretado se ejecuta entre 5 y 10 veces más lento que el código compilado. Los lenguajes interpretados como Basic o JavaScript son los más lentos. Su ventaja es que no es necesario volver a compilarlos después de los cambios y eso es útil cuando estás aprendiendo a programar.
Sin embargo, la velocidad 5-10 veces más lenta no es necesariamente cierta para lenguajes como Java y C #. Se interpretan, pero los compiladores justo a tiempo pueden generar instrucciones en lenguaje de máquina para algunas operaciones, acelerando dramáticamente las cosas (cerca de la velocidad de un lenguaje compilado a veces).
Esta es una buena pregunta, pero debería formularse de manera un poco diferente en mi opinión, por ejemplo: "¿Por qué los idiomas interpretados son más lentos que los compilados?"
Creo que es un error común que los lenguajes interpretados sean lentos per se. Los idiomas interpretados no son lentos , pero, dependiendo del caso de uso, pueden ser más lentos que la versión compilada. En la mayoría de los casos, los idiomas interpretados son lo suficientemente rápidos .
"Lo suficientemente rápido", más el aumento en la productividad de usar un lenguaje como Python sobre, por ejemplo, C debería ser una justificación suficiente para considerar un lenguaje interpretado. Además, siempre puede reemplazar ciertas partes de su programa interpretado con una implementación rápida de C, si realmente necesita velocidad. Pero nuevamente, mida primero y determine si la velocidad es realmente el problema, luego optimice.
Lea esto Pros y contras de idiomas interpretados
Esta es la idea relevante en ese post para tu problema.
Una ejecución por parte de un intérprete suele ser mucho menos eficiente que la ejecución regular del programa. Ocurre porque cada instrucción debe pasar una interpretación en tiempo de ejecución o como en implementaciones más nuevas, el código debe compilarse en una representación intermedia antes de cada ejecución.
Los idiomas interpretados deben leer e interpretar su código fuente en el momento de la ejecución. Con el código compilado, gran parte de esa interpretación se realiza antes de tiempo (en el momento de la compilación).
Los programas nativos se ejecutan utilizando instrucciones escritas para el procesador en el que se ejecutan.
Los lenguajes interpretados son solo eso, "interpretados". Alguna otra forma de instrucción es leída e interpretada por un tiempo de ejecución, que a su vez ejecuta las instrucciones de la máquina nativa.
Piénsalo de esta manera. Si puede hablar con alguien en su idioma nativo, eso generalmente funcionaría más rápido que tener un intérprete que tenga que traducir su idioma a otro idioma para que el oyente lo entienda.
Tenga en cuenta que lo que describo anteriormente es para cuando un idioma se está ejecutando en un intérprete. Hay intérpretes para muchos idiomas en los que también hay enlazadores nativos para las instrucciones de la máquina nativa. La reducción de velocidad (sin embargo, el tamaño de la misma) solo se aplica al contexto interpretado.
Entonces, es un poco incorrecto decir que el lenguaje es lento, más bien es el contexto en el que se está ejecutando lo que es lento.
C # no es un lenguaje interpretado, a pesar de que emplea un lenguaje intermedio (IL), se trata de instrucciones nativas antes de ser ejecutado, por lo que tiene la misma reducción de velocidad, pero no toda, pero apostaría a que si construyes un intérprete completo para C # o C ++, también se ejecutaría más lento.
Y para ser claro, cuando digo "lento", ese es, por supuesto, un término relativo.
Muy pocos lenguajes contemporáneos de escritura son "interpretados" en estos días; Por lo general, se compilan sobre la marcha, ya sea en código de máquina o en algún lenguaje de código de byte intermedio, que se ejecuta (de manera más eficiente) en una máquina virtual.
Dicho esto, son más lentos porque su CPU está ejecutando muchas más instrucciones por "línea de código", ¡ya que muchas de las instrucciones se emplean para entender el código en lugar de hacer lo que sugiere la semántica de la línea!
No existe tal cosa como un lenguaje interpretado. Cualquier lenguaje puede ser implementado por un intérprete o un compilador. Estos días la mayoría de los lenguajes tienen implementaciones usando un compilador.
Dicho esto, los intérpretes suelen ser más lentos, ya que necesitan procesar el idioma o algo parecido a él en tiempo de ejecución y traducirlo a las instrucciones de la máquina. Un compilador hace esta traducción a las instrucciones de la máquina solo una vez, después de eso se ejecutan directamente.
Por la misma razón que es más lento hablar a través del traductor que en el idioma nativo. O bien, leyendo con el diccionario. Se necesita tiempo para traducir.
Actualización: no, no vi que mi respuesta es la misma que la aceptada, hasta cierto punto ;-)
Repetir 100 veces, el contenido del bucle se interpreta 100 veces en código de bajo nivel.
No almacenado en caché, no reutilizado, no optimizado.
En términos simples, un compilador interpreta una vez en código de bajo nivel
Editar, después de los comentarios:
- JIT es un código compilado , no interpretado. Simplemente se compila más tarde no por adelantado
- Me refiero a la definición clásica, no a las implementaciones prácticas modernas.
Sí, los idiomas interpretados son lentos ...
Sin embargo, considere lo siguiente. Tuve un problema que resolver. Me tomó 4 minutos resolver el problema en Python, y el programa tardó 0,15 segundos en ejecutarse. Luego intenté escribirlo en C, obtuve un tiempo de ejecución de 0,12 segundos y tardé 1 hora en escribirlo. Todo esto porque la forma práctica de resolver el problema en cuestión era usar tablas hash, y la tabla hash dominaba el tiempo de ejecución de todos modos.
Todas las respuestas parecen pasar por alto el punto realmente importante aquí. Es el detalle de cómo se implementa el código "interpretado".
Los idiomas interpretados son más lentos porque su modelo de objeto, objeto y espacio variable global es dinámico. Esto requiere muchas búsquedas adicionales de tablas hash en cada acceso a una variable o método de llamada. Aquí es donde se pasa la mayor parte del tiempo. Es una búsqueda de memoria aleatoria dolorosa, que realmente duele cuando se obtiene una falta de caché L1 / L2.
El Javascript Core8 de Google es tan rápido y apunta a una velocidad casi C para una optimización simple: toman el modelo de datos del objeto como fijo y crean un código interno para acceder a él como la estructura de datos de un programa compilado nativo. Cuando se agrega o se elimina una nueva variable o método, todo el código compilado se descarta y se vuelve a compilar.
La técnica está bien explicada en el documento de Deutsch / Schiffman "Implementación eficiente del sistema Smalltalk-80".
La pregunta de por qué php, python y ruby no están haciendo esto es bastante simple de responder: la técnica es extremadamente complicada de implementar.
Y solo Google tiene el dinero para pagar por JavaScript porque un rápido intérprete de JavaScript basado en navegador es su necesidad fundamental de su modelo de negocio de mil millones de dólares.
Una pregunta simple, sin ninguna respuesta realmente simple. La conclusión es que todas las computadoras realmente "entienden" son instrucciones binarias, que es en lo que se compilan los lenguajes "rápidos" como C.
Luego están las máquinas virtuales, que comprenden diferentes instrucciones binarias (como Java y .NET), pero esas deben ser traducidas sobre la marcha a instrucciones de la máquina por un Just-In-Compiler (JIT). Eso es casi tan rápido (incluso más rápido en algunos casos específicos porque el JIT tiene más información que un compilador estático sobre cómo se usa el código).
Luego están los lenguajes interpretados, que generalmente también tienen sus propias instrucciones binarias intermedias, pero el intérprete funciona de manera muy parecida a un bucle con una instrucción de interruptor grande con un caso para cada instrucción y cómo ejecutarla. Este nivel de abstracción sobre el código de máquina subyacente es lento. Hay más instrucciones involucradas, largas cadenas de llamadas a funciones en el intérprete para hacer incluso cosas simples, y se puede argumentar que la memoria y el caché no se usan tan efectivamente como resultado.
Pero los idiomas interpretados suelen ser lo suficientemente rápidos para los fines para los que se utilizan. Las aplicaciones web están vinculadas invariablemente por IO (generalmente acceso a la base de datos) que es un orden de magnitud más lento que cualquier intérprete.
La interpretación del código es más lenta que la ejecución del código compilado porque el intérprete debe analizar cada instrucción en el programa cada vez que se ejecuta y luego realizar la acción deseada, mientras que el código compilado simplemente realiza la acción dentro de un contexto fijo determinado por la compilación . Este análisis en tiempo de ejecución se conoce como "sobrecarga interpretativa". El acceso a las variables también es más lento en un intérprete porque la asignación de identificadores a las ubicaciones de almacenamiento se debe hacer repetidamente en tiempo de ejecución en lugar de en tiempo de compilación.
Consulte este documento de IBM ,
El programa interpretado debe traducirse cada vez que se ejecuta, hay una sobrecarga mayor. Por lo tanto, un lenguaje interpretado es generalmente más adecuado para solicitudes ad hoc que solicitudes predefinidas.
En Java, aunque se considera como un lenguaje interpretado, utiliza la compilación JIT (Just-in-Time) que mitiga el problema anterior mediante el uso de una técnica de almacenamiento en caché para almacenar en memoria caché el código de bytes compilado.
El compilador JIT lee los códigos de byte en muchas secciones (o en su totalidad, rara vez) y los compila dinámicamente en código de máquina para que el programa pueda ejecutarse más rápido. Esto se puede hacer por archivo, por función o incluso en cualquier fragmento de código arbitrario; el código se puede compilar cuando está a punto de ejecutarse (de ahí el nombre "just-in-time"), y luego se almacena en caché y se vuelve a utilizar más tarde sin necesidad de volver a compilarlo.