¿Podemos hacer declaraciones generales sobre el rendimiento del código interpretado frente al código compilado?

Para código como A = A + B , que puede compilar hasta una o dos instrucciones de máquina, cada una de ellas con un cierto número de ciclos. Ningún intérprete puede hacer lo mismo en ese número de ciclos por una simple razón.

El intérprete también ejecuta un conjunto de instrucciones propio (llámelos códigos de bytes, códigos p, lenguaje intermedio, lo que sea). Cada vez que ve un código de bytes como AGREGAR, debe buscarlo de alguna manera y derivarse al código que hace la adición.

La siguiente vez que la ve, tiene que repetir esa búsqueda, a menos que tenga una forma de recordar la búsqueda anterior. Si tiene una manera de recordar la búsqueda anterior, ya no es lo que llamamos un "intérprete", sino un compilador justo a tiempo, o JITter.

Por otro lado ...

Para códigos como callSomeFunction( ... some args ...) , ¿cuántos ciclos se gastan entre ingresar ese código y dejarlo? Todo depende de lo que ocurra dentro de callSomeFunction . Podrían ser unos pocos, y podrían ser billones, incluso si callSomeFunction está compilado. Si es mucho, no tiene sentido debatir el costo de interpretación de esa línea de código, el dinero está en otra parte.

Recuerde que los idiomas interpretados tienen un valor propio, como, por ejemplo, no es necesario compilarlos. (La "compilación" de la sintaxis de la superficie a los códigos de bytes toma un tiempo trivial. Tome R o MATLAB, por ejemplo).

También, se necesita flexibilidad para niveles inteligentes de programación. En Society of Mind de Minsky, Capítulo 6.4 B -Frenos, hay programas A que tratan con el mundo, y programas B que tratan con los programas A, y puede haber niveles adicionales. Los programas que escriben y administran otros programas se pueden hacer más fácilmente en sistemas interpretativos.

En Lisp, puedes escribir (+ A B) para agregar A y B, pero una vez que está escrito solo tienes la opción de ejecutarlo o no. También puede escribir (eval (list '+ 'A 'B)) que construye el programa y luego lo ejecuta. Podría construir algo diferente.

El tema del programa es otro programa . Esto es más fácil de escribir en un lenguaje interpretado (aunque, como señala Jörg, las versiones más recientes de Lisp, mientras que tienen eval , compila sobre la marcha, por lo que no tienen la penalización de velocidad de la interpretación). / p>     

Es un tipo de, depende de, pero como regla general, el entorno compilado, ya sea a través de JIT o estáticamente compilado, será más rápido para muchas tareas de uso intensivo de cómputo, suponiendo que sea un lenguaje sencillo.

Parte de la razón es que los lenguajes interpretados necesitan tener un bucle de bucle de intérprete que lea una instrucción, seleccione la acción apropiada para realizarla y la ejecute. En el mejor de los casos, como interpretar Python o Java bytecode (como old JVM), tiene una sobrecarga de pocas instrucciones y causó estragos en el predictor de la rama, sin la última puede esperar grandes penalizaciones debido a predicciones erróneas. Incluso un JIT muy tonto debería acelerar esto significativamente.

Dicho esto, el lenguaje interpretado puede hacer trampa. Por ejemplo, Matlab ha optimizado las rutinas para la multiplicación de matrices y con pocos cambios puede ejecutar el código en la GPU (exención de responsabilidad: trabajo para nVidia: cualquier opinión expresada aquí es mía y no representa la opinión de mi empleador). De esa manera, puede escribir código de nivel alto breve y potente sin preocuparse por los detalles: alguien se ocupó de ello y dedicó tiempo y recursos a la optimización en lenguaje de bajo nivel. No hay nada heredado al respecto y no impide, por ejemplo, aplicar Matlab al JIT del código, pero a menudo no hay razón, ya que la sobrecarga de llamadas a la rutina de alto nivel es mínima en comparación con el tiempo empleado en los de bajo nivel.

TL; DR: los programas compilados tienen enormes beneficios de rendimiento sobre los interpretados (para la comparación manzanas con manzanas, vea PyPy Speed ). Sin embargo, la velocidad del ejecutable es solo una parte del problema y puede que no contribuya mucho a la velocidad general (si la mayor parte del tiempo se dedica a las bibliotecas). También importa la implementación.

Su suposición está bien fundada, aunque es una suposición.

No voy a repasar las razones por las que el código compilado debería ser más rápido que el código interpretado: si sabes cómo funcionan las computadoras, eso será obvio. La diferencia puede ser de órdenes de magnitud para ciertos tipos de problemas. Si su crítico disputa seriamente ese caso general, no saben de qué están hablando.

Aunque pueden tener un punto es si la diferencia es significativa en el tipo de aplicación que está desarrollando. Si se trata principalmente de E / S o, en su mayoría, de bibliotecas compiladas y no tiene muchos cálculos, la sobrecarga del proceso de interpretación puede ser insignificante.

Pero el punto de mi publicación es este: como un I.T. experto, a menudo se lo llamará para tomar decisiones rápidas basadas en un conocimiento general de cómo deberían funcionar las cosas. Hacer una prueba específica podría ofrecerte una respuesta más precisa, pero te costará mucho más y no te llevará allí primero.

Pero de vez en cuando te atrapan. Me ha pasado Usted hace una buena suposición y luego descubre que no tuvo en cuenta la estupidez del mundo.

Pero no puedo explicar tan bien como mi dibujo animado favorito de Dilbert de todos los tiempos. Nada muestra mejor que esto los peligros de ser un asno inteligente.

TL; DR: debes tener razón, pero revisa el mundo real por si acaso.

A menos que use algo un tanto exótico, su problema no será sobre el rendimiento de un lenguaje interpretado A y un lenguaje compilado B.

Porque si usted / su equipo sabe A y no B y, por lo tanto, escribe mejor el código en A que en B, puede tener un desempeño mucho mejor en A que en B. Si tiene personas con experiencia en un idioma y el idioma / bibliotecas Puede hacer el trabajo que necesita, seguirlo.

Aquí hay un enlace sobre expresiones regulares en varios idiomas; verá que las expresiones regulares se implementan mejor en algún lenguaje, incluso si están compiladas o no: enlace

Creo que no es una buena idea hablar sobre el rendimiento de dos tecnologías solo por el hecho de que una se compila y la otra se interpreta. Como se indica en otras respuestas, puede depender del área de la aplicación (algunos idiomas pueden optimizarse para realizar algunas operaciones muy rápidamente y hacer otras cosas más lentamente), así como en la experiencia de las personas que están a punto de usar esa tecnología. p>

No creo que sea razonable esperar que obtengas un aumento en el rendimiento si tomas unos excelentes codificadores de lenguaje interpretados y les das una tecnología con la que no están familiarizados, tal vez en teoría esto último puede dar como resultado un mejor rendimiento, pero en realidad, sin las habilidades y experiencia necesarias, no utilizará todas las oportunidades de optimización.

Por parte de uno de los conocidos empleados de la compañía de Silicon Valley, también escuché que prefieren el lenguaje que es más fácil de usar, ya que es más costoso y problemático pagar a algunos desarrolladores expertos para mantener un código complicado pero altamente optimizado. que solo comprar una plataforma para lidiar con una implementación menos eficiente, por lo que también debe considerarse al elegir la tecnología.

Una vez tuve que hacer una declaración similar para justificar una gran decisión.

Primero, es posible que no quieran creerle a un ingeniero humilde, así que encontré algunas pruebas comparativas comparables y las cité. Hay muchos acerca de ellos, de personas como Microsoft o universidades reconocidas. Y dirán cosas como: El método A es entre 3 y 10 veces más rápido que el método B, dependiendo de las variables X e Y.

En segundo lugar, es posible que desee ejecutar un punto de referencia propio, tal vez utilizando una parte representativa del código en cuestión, o algo similar que ya tenga. Ejecutarlo 1000 veces durante la noche, así que realmente hay una diferencia mensurable.

En este punto, la diferencia (o la falta de ella) entre A y B debería ser tan clara que solo tiene que presentarla. Entonces formatee los resultados claramente, con diagramas si es posible, estableciendo todos los supuestos y definiendo todos los datos utilizados.

Yo diría que cualquier lenguaje dinámico tiene una ventaja sobre los compilados estáticamente: "Optimizaciones de tiempo de ejecución"

Esa es una de las razones por las que Java puede ser más rápido que C ++

Sí, cargar un idioma escrito dinámicamente siempre tendrá el costo de traducción y estará en desventaja. Pero una vez que se está ejecutando, el intérprete puede perfilar y mejorar las rutas de código frecuentes con información de tiempo de ejecución que los lenguajes estáticos nunca tendrán

NOTA: Bueno, Java es un lenguaje interpretado, no dinámico. Pero es un gran ejemplo de lo que puede acelerar con información de tiempo de ejecución

  

... También declaro que dado que un programa puede escribirse de muchas maneras, es   Todavía es posible que un programa escrito en tecnología A pueda superar a uno   escrito en tecnología B.

     

Cuando envié este informe para su revisión, el revisor declaró que   No ofreció ninguna razón clara por la que, en general, la sobrecarga de la   proceso de interpretación sería lo suficientemente grande como para que pudiéramos concluir   El rendimiento de esa tecnología B sería mejor. ...

Este sería mi enfoque:

En general, los intérpretes se compilan, por lo que cada tecnología interpretada no es más que una tecnología compilada si se la observa en un nivel bajo. Por lo tanto, las tecnologías compiladas son más y con más posibilidades, nunca podrá empeorar si es inteligente (lo que en general es). Depende de cuánta información haya disponible en tiempo de compilación y cuánta información esté disponible solo en tiempo de ejecución y de cuán buenos sean los compiladores e intérpretes, pero en teoría siempre debería ser posible igualar al menos el rendimiento de cualquier intérprete con un compilador adecuado. solo porque los intérpretes son fabricados por compiladores. Que sea posible, no significa que sea el caso de tus técnicos A y B, sin embargo.

En la práctica, simplemente informe al revisor acerca de todos los puntos de referencia disponibles donde se comparan los sistemas compilados e interpretados. Luego, pídale que le sugiera un intérprete que supere su algoritmo específico de código ensamblado optimizado.

Tal vez debería agregarse que cualquier declaración general no ayuda en absoluto cuando se comparan dos técnicos específicos A y B. En este caso, la elección de A y B importa mucho, mucho más, que si se interpretan o compilan.