2011-07-08 18 views
5

Sé que ASM es básicamente el más rápido que se puede obtener, pero ¿qué hace que los HLL sean más lentos que ASM la abstracción? Lo que quiero decir con abstracción es que, por ejemplo, en C++ usted tiene una clase, los datos deben almacenarse sobre lo que está almacenado en la clase, de qué se deriva, los accesadores privados/públicos y otras cosas. Cuando se compila este código, ¿existe un código de ensamblaje real que funcione para descubrir la información sobre la clase? Al igual que CPython se basa en C por lo que hay aún más abstracción e instrucciones para ejecutar en tiempo de ejecución que C. ¿Es cierto lo que digo? Creo que he respondido mi propia pregunta, pero me gustaría obtener una respuesta de un individuo más experimentado que yo.¿Por qué algunos lenguajes de programación son más rápidos que otros?

EDIT: Entiendo que Python se interpreta pero ¿no sería aún más lento que C si se compilara?

Respuesta

5

Esa es una pregunta amplia.

Fundamentalmente, los lenguajes compilados se traducen a las instrucciones de la máquina (códigos op) al igual que ASM (ASM también es una capa de abstracción). Es probable que un buen compilador supere el resultado de un codificador ASM promedio, ya que puede examinar un gran parche de código y aplicar reglas de optimización que la mayoría de los programadores no podían hacer a mano (ordenando instrucciones para una ejecución óptima, etc.).

En ese sentido, todos los idiomas compilados se crean "iguales". Sin embargo, algunos son más iguales que otros. El rendimiento del código compilado depende fundamentalmente de cuán bueno sea el compilador y mucho menos del idioma específico. Ciertas características como los métodos virtuales incurren en una penalización de rendimiento (la última vez que revisé los métodos virtuales se implementaron usando una tabla de indicadores de función, aunque mi conocimiento puede estar fechado aquí).

Los lenguajes interpretados examinan fundamentalmente el lenguaje legible por humanos a medida que se ejecuta el programa, lo que exige esencialmente el equivalente de las etapas de compilación y ejecución durante el tiempo de ejecución del programa. Por lo tanto, casi siempre serán algo más lentos que una contraparte compilada.Las implementaciones inteligentes interpretarán incrementalmente partes del código tal como se ejecutan (para evitar la interpretación de las ramas que nunca se golpean), y almacenarán en caché el resultado de modo que una porción dada de código se interprete solo una vez.

También hay un término medio, en el que el lenguaje legible por el ser humano se traduce a un pseudocódigo (a veces llamado código P o código de bytes). El propósito de esto es tener una representación compacta del código que sea rápida de interpretar, aunque portátil en muchos sistemas operativos (aún necesita un programa para interpretar el código P en cada plataforma). Java cae en esta categoría.

+0

Gracias. Sí, como dije en mi comentario a paulsm4, el lenguaje puede ser el más complicado de todos, pero aún más rápido si tiene un gran compilador. Esto tiene mucho más sentido para mí, ¡así que gracias de nuevo! – edaniels

2

En realidad, su premisa no es necesariamente cierta.

Muchos dirían que un buen compilador de optimización puede superar el ensamblaje codificado a mano.

Otros podrían decir que los compiladores just-in-time como los de Java y .Net pueden aprovechar la heurística de tiempo de ejecución y por lo tanto superar el rendimiento de cualquier código compilado estáticamente.

Entre los compiladores e intérpretes, les aseguro que no hay necesariamente una correlación entre la forma alto nivel es el lenguaje y la eficiencia en tiempo de ejecución. Muy idiomas de alto nivel pueden producir extremadamente código eficiente.

mi humilde opinión ...

+0

Así que realmente se trata de cómo el compilador o intérprete elige crear/optimizar el código de máquina real. Lo que haría que mi punto sobre Python sea más lento si fuera un lenguaje compilado porque el compilador (hecho en C) probablemente tomaría pasos similares para crear el código de máquina como lo haría en el compilador de C. – edaniels

+0

Es fácil para muchos decir tales cosas. Encontrar apoyo objetivo para sus reclamos sería mucho más difícil. –

+0

¿Eres demasiado perezoso con Google, Jerry Coffin? ¿O simplemente demasiado detestable para contribuir con algo positivo a la discusión? – paulsm4

1

Como regla general, cuanto más abstracto (y por lo general el más conveniente para los programadores) el lenguaje es, más lento será. Un compilador de C generará un código de ensamblado, por lo que es tan dependiente del sistema. Los lenguajes como Java se ejecutan en una máquina virtual, que a su vez es un programa compilado. Pero esa abstracción ralentizará las cosas en general.

Pero eso no quiere decir que no haya excepciones. Como dijo paulsm4, los lenguajes de alto nivel pueden llegar a ser más eficientes que los de bajo nivel porque pueden aprovechar varios patrones (no conozco los detalles).

+0

¿Cómo es que la gente dice que en estos días JAVA ya no es mucho más lento que C++? –

1

Cuando habla de la velocidad de un idioma, lo primero que debe hacer es compilarlo o interpretarlo. Un lenguaje interpretado generalmente se ejecutará de uno a dos órdenes de magnitud más lento que un lenguaje compilado.

Pero eso puede no importar. Un lenguaje interpretado puede tener otras ventajas, y lo que desea hacer con él puede no requerir velocidad de cegamiento; si tuviera la velocidad, no lo notaría.

Por ejemplo, todos los lenguajes de la línea de comandos se interpretan (que yo sepa), y eso está bien, porque simplemente ejecutan un comando del sistema operativo que consume tiempo seguido del siguiente. Los ciclos afeitados al interponerse entre comandos nunca se notarían.

Incluso en lenguajes compilados rápidamente, los programas que solo vinculan una llamada de biblioteca seguida de otra y otra, con solo un poco de manipulación de datos sin procesar, obtienen poco beneficio de la velocidad del lenguaje, porque todo el tiempo es siendo gastado en el sótano.

Donde la velocidad del lenguaje importa es en ese material del sótano. Si solo está escribiendo código de nivel superior, la velocidad del código compilado importa poco. Lo que importa muchoes decir, si el código llama rutinas subordinadas más de lo que realmente necesita. El compilador no puede ayudarlo con eso. Here's an example of how to fix that kind of problem.

Cuestiones relacionadas