¿Por qué los idiomas interpretados son lentos?

Question

Estuve leyendo sobre los pros y contras de los lenguajes interpretados, y uno de los contras más comunes es la lentitud, pero ¿por qué los programas en lenguajes interpretados son lentos?

Answer 1

programas nativos se ejecuta mediante instrucciones escritas para el procesador que se ejecuten.

Los lenguajes interpretados son sólo eso, "interpretado". Alguna otra forma de instrucción es leído e interpretado, por un tiempo de ejecución, que a su vez ejecuta instrucciones nativas de la máquina.

Piense en ello de esta manera. Si se puede hablar en su lengua materna a alguien, eso generalmente trabajar más rápido que tener un intérprete tener que traducir a su idioma a otro idioma para que el oyente entienda.

Tenga en cuenta que lo que estoy describiendo anterior es para cuando una lengua se ejecuta en un intérprete. Hay intérpretes para muchos idiomas que también hay conectores nativos para que se acumulan las instrucciones de máquina nativo. La reducción de velocidad (sin embargo el tamaño de que podría ser) sólo se aplica al contexto interpretado.

Por lo tanto, es ligeramente incorrecto decir que el idioma es lento, sino que es el contexto en el que se está ejecutando es lento.

C # no es un lenguaje interpretado, a pesar de que emplea un lenguaje intermedio (IL), esto se compilados JIT a las instrucciones nativas antes de ser ejecutado, por lo que tiene algunos de la misma reducción de la velocidad, pero no todos de la misma, pero yo apostaría que si usted construyó un intérprete de pleno derecho para C # o C ++, sería correr más lento también.

Y sólo para que quede claro, cuando digo "lento", es decir, por supuesto, un término relativo.

Answer 2

Todas las respuestas parecen perder el importante punto real aquí. Es el detalle cómo "interpretado" código se implementa.

Los lenguajes de script interpretado son más lentas debido a su método, objeto y modelo global variable espacio es dinámico. En mi opinión esta es la verdadera definición de lenguaje de script no el hecho de que se interpreta. Esto requiere muchas consultas de tabla hash adicionales en cada acceso a una llamada variable o método. Y es la razón principal por la que son todos terrible en multihilo y utilizando un GIL (Global intérprete de bloqueo). Este búsquedas es donde la mayor parte del tiempo se dedica. Es una búsqueda aleatoria de memoria dolorosa, lo que realmente duele cuando se obtiene una caché-miss L1 / L2.

de JavaScript de Google Core8 es tan rápido y dirigidas a casi la velocidad de C para una simple optimización: toman el modelo de datos de objetos como fijo y crear un código interno para acceder a ella como la estructura de datos de un programa compilado nativo. Cuando se añade o elimina entonces una nueva variable o método todo el código compilado se descarta y se compila de nuevo.

La técnica está bien explicado en el documento Deutsch / Schiffman "Aplicación eficiente del sistema Smalltalk-80".

La pregunta de por qué PHP, Python y Ruby no están haciendo esto es bastante fácil de responder: la técnica es extremadamente complicado de implementar

.

Y sólo Google tiene el dinero para pagar JavaScript debido a una rápida basada en navegador intérprete de JavaScript es su necesidad fundamental de su modelo de negocio mil millones de dólares.

Answer 3

Piense en la interpeter como un emulador de una máquina que no sucede que tiene

La respuesta corta es que los lenguajes compilados son ejecutados por instrucciones de la máquina mientras que las interpretan los son ejecutados por un programa (escrito en un lenguaje compilado) que lee el origen o un código de bytes y luego esencialmente emula una máquina hipotética que haría se ejecute el programa directamente si existía la máquina.

Piense en el tiempo de ejecución interpretado como un emulador de una máquina que no sucede en realidad tienen todo en este momento.

Esto es, obviamente complica por el JIT (Just In Time) compiladores que Java, C #, y otros tienen. En teoría, son tan buenos como los compiladores "AOT" ( "a la vez"), pero en la práctica dichas lenguas corren más lento y se ven perjudicadas por la necesidad de tener el compilador torno al uso de la memoria y el tiempo durante la ejecución del programa. Pero si usted dice nada de eso aquí en fin de estar preparados para atraer a los defensores de los JIT rabiosos que insisten en que no hay ninguna diferencia teórica entre JIT y AOT. Si se les pregunta si Java y C # son tan rápidos como C y C ++, entonces empiezan a poner excusas y tipo de calmen un poco. : -)

Por lo tanto, C ++ totalmente reglas en juegos en los que la cantidad máxima de computación disponible siempre puede ser objeto de un uso.

En el escritorio y la web, las tareas orientadas a la información se hace a menudo por los idiomas con más abstracción o al menos menos compilación, porque los ordenadores son muy rápidos y los problemas no son computacionalmente intensivas, por lo que puede pasar algún tiempo en objetivos como tiempo de salida al mercado, la productividad del programador, entornos de memoria de fallos fiables, modularidad dinámico, y otras herramientas de gran alcance.

Answer 4

Esta es una buena pregunta, pero en mi opinión debería formularse un poco diferente, por ejemplo:"¿Por qué los lenguajes interpretados son más lentos que los lenguajes compilados?"

Creo que es un error común pensar que los lenguajes interpretados son lentos per se.Los lenguajes interpretados son No despacio, pero, dependiendo del caso de uso, podría ser Más lento que la versión compilada.En la mayoría de los casos, los lenguajes interpretados son en realidad suficientemente rapido!

"Lo suficientemente rápido", más el aumento en la productividad al usar un lenguaje como Python en lugar de, por ejemplo, C debería ser una justificación suficiente para considerar un lenguaje interpretado.Además, siempre puedes reemplazar ciertas partes de tu programa interpretado con una implementación rápida en C, si realmente necesitas velocidad.Pero, de nuevo, mida primero y determine si la velocidad es realmente el problema, luego optimice.

Answer 5

Loop 100 veces, el contenido del bucle se interpretan 100 veces en código de nivel bajo.

No es almacenado en caché, no se reutiliza, no optimizado.

En términos simples, un compilador interpreta vez para siempre en código de bajo nivel

Editar, después de los comentarios:

• JIT es compilado código , no interpretado. Es sólo compila más tarde no por adelantado
• Me refiero a la definición clásica, no es moderno implementaciones prácticas

Answer 6

Además de las otras respuestas no hay optimización: cuando se está compilando un programa, que normalmente no importa cuánto tiempo se necesita para compilar - el compilador tiene un montón de tiempo para optimizar su código. Cuando se está interpretando código, tiene que hacerse muy rápidamente por lo que algunas de las optimizaciones más inteligentes podría no ser capaz de realizar.

Answer 7

Una pregunta sencilla, sin ninguna respuesta simple real. La conclusión es que todos los equipos realmente "entienden" es instrucciones binarias, que es lo lenguas "rápidos" como C se compilan en.

A continuación, hay máquinas virtuales, que comprendan diferentes instrucciones binarias (como Java y .NET), pero los que tienen que ser traducidas sobre la marcha para instrucciones de la máquina por un Just-In-compilador (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 en cómo se está utilizando el código.)

A continuación, hay lenguas, que por lo general también tienen sus propias instrucciones binarias intermedios interpretarse, pero las funciones de interpretación tanto como un bucle con una gran sentencia switch en ella con un caso por cada instrucción, y la forma de ejecutarlo. Este nivel de abstracción sobre el código de máquina subyacente es lenta. Hay más instrucciones involucrados, largas cadenas de llamadas a funciones en el intérprete de hacer incluso las cosas simples, y se puede argumentar que la memoria caché y no se utilizan con tanta eficacia como consecuencia de ello.

Pero lenguajes interpretados son a menudo lo suficientemente rápido para los fines para los que se van a usar. Las aplicaciones web son invariablemente ligados por IO (por lo general el acceso de base de datos), que es un orden de magnitud más lento que cualquier intérprete.

Answer 8

No hay tal cosa como un lenguaje interpretado. Cualquier lenguaje puede ser implementado por un intérprete o un compilador. En estos días la mayoría de las lenguas tienen implementaciones utilizando un compilador.

Dicho esto, los intérpretes son por lo general más lento, ya que necesitan procesar el lenguaje o algo más cerca de ella en tiempo de ejecución y traducirlo a instrucciones de la máquina. Un compilador hace esto traducción de instrucciones de la máquina sólo una vez, después de que se ejecuten directamente.

Answer 9

about.com :

  

Un lenguaje interpretado es procesada   en tiempo de ejecución. Cada línea se lee,   analizado y ejecutado. Tener que   reprocesar una línea cada vez en un bucle   es lo que hace que los lenguajes interpretados por lo   lento. Esta sobrecarga significa que   código interpretado corre entre de 5 - 10   veces más lento que el código compilado. los   lenguajes interpretados como Basic o   JavaScript son los más lentos. Su   ventaja no se necesitan ser   recompiladas después de esos cambios y que es   útil cuando se está aprendiendo a programar.

Los 5-10 veces más lento no es necesariamente cierto para lenguajes como Java y C #, sin embargo. Se interpretan, pero el justo a tiempo pueden generar lenguaje de máquina instrucciones para algunas operaciones, acelerando las cosas de manera espectacular (cerca de la velocidad de un lenguaje compilado a veces).

Answer 10

Los lenguajes interpretados tienen que leer e interpretar el código fuente en tiempo de ejecución. Con el código compilado un montón de que la interpretación que se hace antes de tiempo (en tiempo de compilación).

Answer 11

Muy pocos lenguajes de script contemporáneos son "interpretados" en estos días; Son típicamente compiladas sobre la marcha, ya sea en código máquina o en algún lenguaje de código de bytes intermedia, que es (más eficiente) ejecutado en una máquina virtual.

Una vez dicho esto, son más lentas debido a su CPU está ejecutando muchas más instrucciones por "línea de código", ya que muchas de las instrucciones que se gastan entender el código en lugar de hacer lo que la semántica de la línea sugieren!

Answer 12

Lenguajes interpretados

Esta es la idea relevante en ese puesto a su problema.

  

Una ejecución por un intérprete es   por lo general mucho menos eficiente que   la ejecución del programa regular. Sucede   ya sea porque cada instrucción   debe pasar a una interpretación   tiempo de ejecución o como en la más reciente   implementaciones, el código tiene que ser   compilado para un intermedio   la representación antes de cada ejecución.

Answer 13

Por la misma razón por la que es más lento para hablar a través de traductor que en lengua nativa. O bien, la lectura con el diccionario. Se necesita tiempo para traducir.

Actualización: no, no vi que mi respuesta es la misma que la aceptada, en un grado; -)

Answer 14

Sí, lenguajes interpretados son lentos ...

Sin embargo, tenga en cuenta lo siguiente. Tenía un problema a resolver. Me tomó 4 minutos para resolver el problema en Python, y el programa tomó 0,15 segundos para funcionar. Entonces traté de escribir en C, y me dieron un tiempo de ejecución de 0,12 segundos, y me tomó 1 hora para escribirlo. Todo esto debido a que la forma práctica de resolver el problema en cuestión era utilizar tablas hash, y la tabla hash dominado el tiempo de ejecución de todos modos.

Answer 15

Wikipedia dice ,

  código

Interpretando es más lenta que ejecuta el código compilado porque el intérprete debe analizar cada declaración en el programa cada vez que se ejecuta y luego realizar la acción deseada, mientras que el código compilado solo realiza la acción dentro de un marco fijo que se determine por la compilación . Este análisis de tiempo de ejecución se conoce como "sobrecarga interpretativa". El acceso a las variables es también más lento en un intérprete porque la asignación de identificadores a los lugares de almacenamiento debe realizarse varias veces en tiempo de ejecución en lugar de en tiempo de compilación.

IBM doc ,

  

programa interpretado debe traducirse cada vez que se ejecuta, hay una sobrecarga superior. Por lo tanto, un lenguaje interpretado es generalmente más adecuado a las solicitudes específicas que solicitudes predefinidos.

En Java aunque se considera como un lenguaje interpretado, utiliza JIT (Just-in-Time) compilación que mitigan el problema anterior mediante el uso de una técnica de almacenamiento en caché para almacenar en caché el código de bytes compilado.

  

El compilador JIT lee los códigos de bytes en muchas secciones (o en su totalidad, en raras ocasiones) y los compila dinámicamente a código de máquina por lo que el programa puede correr más rápido. Esto se puede hacer por archivo, per-función o incluso en cualquier fragmento de código arbitrario; el código puede ser compilado cuando se está a punto de ser ejecutado (de ahí el nombre de "just-in-time"), y luego se almacena en caché y volver a utilizar más adelante sin necesidad de volver a compilar.