¿Cómo puede una implementación de un idioma en el mismo idioma ser más rápido que el idioma?

Question

Si hago un JVM en Java, por ejemplo, es posible hacer que la aplicación hice realidad más rápido que la implementación original Solía ​​ para construir esta aplicación, aunque mi aplicación se construye en la parte superior de la implementación original e incluso puede ser dependiente de esa implementación?

(confuso ...)

Mira PyPy. Es un compilador JIT para Python hecho en Python. Eso está bien, pero ¿cómo puede decirse que es más rápido que la implementación original de Python que está usando y de la que depende?

Answer 1

Se le confunde entre un idioma y el aparato de ejecución para ese idioma.

Una de las razones por las que PyPy puede ser más rápido que CPython es porque PyPy se compila en un ejecutable nativo completamente independiente, y no depende ni se ejecuta en CPython.

Sin embargo, sería posible que una implementación ineficaz de un idioma sea superada por un intérprete escrito en ese mismo idioma y alojado en el intérprete ineficaz, si el intérprete de nivel superior hizo uso de estrategias de ejecución más eficientes.

Answer 2

Absolutamente, es posible. Su implementación de JVM podría compilar bytecodes de Java para optimizar el código de la máquina. Si su optimizador fue más sofisticado que el de la implementación de JVM en la que ejecuta su compilador de Java, entonces el resultado final podría ser más rápido.

En ese caso, puede ejecutar su compilador Java en su propio código fuente, y beneficiarse de velocidades de compilación más rápidas a partir de ese momento.

Dijiste que PyPy es un compilador JIT para Python (no estoy familiarizado con él). Si ese es el caso, entonces convierte un programa de Python en código de máquina y luego ejecuta el código de máquina. Otro cartel decía que el compilador PyPy se ejecuta como un ejecutable independiente, separado de CPython. Pero incluso si se ejecutara en CPython, una vez que su programa esté JIT convertido en código de máquina, y el código de la máquina compilada se esté ejecutando, el rendimiento del compilador ya no importa. La velocidad del compilador solo tiene un efecto en el tiempo de inicio.

Answer 3

No creo que sea posible implementar un intérprete para un idioma en ese idioma (llame a esto A), luego ejecútelo sobre otro intérprete existente (llame a este B) para ese idioma y ejecute un programa (llame esta P), y tiene P ejecutándose (A ejecutándose en B) es más rápido que P ejecutándose en B.

Cada operación de A tendrá que implementarse con al menos una operación de B. Entonces, incluso si B es atrozmente malo y A, es óptimamente bueno, el hecho de que A se ejecute en B significa que la maldad de B se ralentizará A.

Podría ser posible implementar un compilador intérprete + JIT para un idioma en el idioma mismo , donde el JAT el compilador produce algún otro código más rápido en tiempo de ejecución y tiene P ejecutándose (A ejecutándose en B) más rápido que P ejecutándose en B. La parte del tiempo de ejecución de P que no está compilada JIT será más lenta (mucho más lenta, normalmente) pero si el compilador JIT identifica con éxito las partes "calientes" de P y las ejecuta más rápidamente que B, entonces todo el sistema podría funcionar más rápido en general.

Pero eso no es realmente interesante. También es posible implementar un compilador para un idioma en ese idioma (C), compilarlo con un compilador existente (D) y hacer que el nuevo lenguaje de compilación produzca un código que sea más rápido de lo que el compilador original habría producido. Espero que eso no te sobresalte; debe quedar claro que la velocidad del código emitido por D solo tendrá un efecto en el tiempo de ejecución de C, no en el tiempo de ejecución de otros programas compilados con C.

Se han escrito compiladores en los idiomas que compilan hecho por décadas (GCC está escrito en C, por ejemplo), y no es realmente relevante para la pregunta real que creo que estás haciendo; tampoco JIT-compiling es un lenguaje que se usa a sí mismo. En ambos casos, la ejecución subyacente es diferente del idioma que está considerando; generalmente código de máquina.

Sin embargo, la fuente de su pregunta es un error. El intérprete de Python de PyPy no está realmente implementado en Python. El proyecto PyPy tiene un intérprete para Python escrito en RPython. RPython es un subconjunto de Python, elegido para que pueda compilarse eficientemente en código de máquina; como lenguaje RPython se parece mucho más a Java con inferencia de tipo y bloques con sangría en lugar de llaves. El proyecto PyPy también tiene un compilador para RPython que está escrito en Python, y es capaz de (en su mayoría) agregar automáticamente un compilador JIT al cualquier intérprete que compila.

Cuando está utilizando realmente el intérprete PyPy en producción, está utilizando un intérprete de código de máquina compilado de las fuentes de RPython, del mismo modo que cuando usa el intérprete CPython utiliza un intérprete de código de máquina compilado de C código fuente. Si ejecuta el intérprete PyPy encima de otro intérprete de Python (que puede hacer porque el código de RPython válido también es código de Python válido, pero no al revés), entonces se ejecuta mucho más lento que el intérprete de CPython.

Answer 4

El proceso de traducción pypy se ejecuta en CPython, pero el resultado es una lista de archivos .c (19 archivos la última vez que revisé) que luego se compilan en un archivo binario: pypy-c. En tiempo de ejecución, pypy-c no tiene ninguna relación con CPython, por eso puede ser más rápido.

Answer 5

PyPy no es intérprete de Python implementado en Python, es Python intérprete y compilador implementado en RPython, que es un subconjunto restringido de tipos estáticos de Python:

RPython es un subconjunto restringido de Python que es susceptible de análisis estático . Aunque hay adiciones al lenguaje y algunas cosas podrían funcionar sorprendentemente, esta es una lista aproximada de restricciones que se deben considerar . Tenga en cuenta que hay toneladas de restricciones especiales que se encontrarán sobre la marcha.

La diferencia de velocidad real viene del hecho de que, a diferencia CPython que está interpretando todo el programa como código de bytes, PyPy utiliza just-in-time (JIT) compilation (en código máquina) de piezas RPython.