¿El lenguaje de “máquina virtual” de Java frente a “intérprete” de Python?

Parece raro que se lea todo el tiempo de una “máquina virtual” de Python, mientras que en Java se usa “máquina virtual”.

Ambos interpretan códigos de bytes; ¿Por qué llamar a una máquina virtual y al otro a un intérprete?

Una máquina virtual es un entorno de computación virtual con un conjunto específico de instrucciones atómicas bien definidas que se admiten de forma independiente de cualquier lenguaje específico y, en general, se considera una caja de arena en sí misma. La VM es análoga a un conjunto de instrucciones de una CPU específica y tiende a funcionar en un nivel más fundamental con bloques de construcción muy básicos de dichas instrucciones (o códigos de bytes) que son independientes de la siguiente. Una instrucción se ejecuta de manera determinista solo en función del estado actual de la máquina virtual y no depende de la información en otro lugar del flujo de instrucciones en ese momento.

Por otro lado, un intérprete es más sofisticado porque está diseñado para analizar una secuencia de una syntax que es de un lenguaje específico y de una gramática específica que debe decodificarse en el contexto de los tokens circundantes. No puede mirar cada byte o incluso cada línea de forma aislada y saber exactamente qué hacer a continuación. Los tokens en el idioma no se pueden tomar de forma aislada, como se puede en relación con las instrucciones (códigos de bytes) de una máquina virtual.

Un comstackdor de Java convierte el lenguaje Java en una secuencia de código de bytes, no diferente a un comstackdor de C que convierte los progtwigs de Lenguaje C en código ensamblador. Por otro lado, un intérprete no convierte realmente el progtwig en una forma intermedia bien definida, simplemente toma las acciones del progtwig como una cuestión del proceso de interpretación de la fuente.

Otra prueba de la diferencia entre una máquina virtual y un intérprete es si piensa que es independiente del lenguaje. Lo que conocemos como Java VM no es realmente específico de Java. Podría crear un comstackdor desde otros idiomas que dé lugar a códigos de bytes que puedan ejecutarse en la JVM. Por otro lado, no creo que realmente pensemos en “comstackr” otro lenguaje que no sea Python en Python para la interpretación del intérprete de Python.

Debido a la sofisticación del proceso de interpretación, este puede ser un proceso relativamente lento … específicamente analizando e identificando los tokens de lenguaje, etc. y comprendiendo el contexto de la fuente para poder llevar a cabo el proceso de ejecución dentro del intérprete. Para ayudar a acelerar tales lenguajes interpretados, aquí es donde podemos definir formas intermedias de código fuente pre-analizado, pre-tokenizado que se interpreta más fácilmente de manera directa. Este tipo de forma binaria aún se interpreta en el momento de la ejecución, solo está comenzando desde una forma mucho menos legible para mejorar el rendimiento. Sin embargo, la lógica que ejecuta esa forma no es una máquina virtual, ya que esos códigos aún no pueden tomarse de forma aislada; el contexto de los tokens circundantes sigue siendo importante, ahora están en una forma diferente, más eficiente desde el punto de vista informático.

En esta publicación, “máquina virtual” se refiere a máquinas virtuales de proceso, no a máquinas virtuales del sistema como Qemu o Virtualbox. Una máquina virtual de proceso es simplemente un progtwig que proporciona un entorno de progtwigción general, un progtwig que se puede progtwigr.

Java tiene un intérprete y una máquina virtual, y Python tiene una máquina virtual y un intérprete. La razón por la que “máquina virtual” es un término más común en Java y “intérprete” es un término más común en Python tiene mucho que ver con la principal diferencia entre los dos lenguajes: escritura estática (Java) frente a escritura dinámica (Python). En este contexto, “tipo” se refiere a tipos de datos primitivos , tipos que sugieren el tamaño de almacenamiento en la memoria de los datos. La máquina virtual de Java lo tiene fácil. Requiere que el progtwigdor especifique el tipo de datos primitivo de cada variable. Esto proporciona información suficiente para que el código de byte de Java no solo sea interpretado y ejecutado por la máquina virtual de Java, sino que incluso se compile en las instrucciones de la máquina . La máquina virtual de Python es más compleja en el sentido de que asume la tarea adicional de hacer una pausa antes de la ejecución de cada operación para determinar los tipos de datos primitivos para cada variable o estructura de datos involucrada en la operación. Python libera al progtwigdor de pensar en términos de tipos de datos primitivos y permite que las operaciones se expresen a un nivel superior. El precio de esta libertad es el rendimiento. “Intérprete” es el término preferido para Python porque tiene que hacer una pausa para inspeccionar los tipos de datos, y también porque la syntax comparativamente concisa de los lenguajes de tipo dynamic es una buena opción para las interfaces interactivas. No hay una barrera técnica para construir una interfaz Java interactiva, pero intentar escribir cualquier código de forma estática de forma interactiva sería tedioso, por lo que simplemente no se hace de esa manera.

En el mundo Java, la máquina virtual se roba el progtwig porque ejecuta progtwigs escritos en un lenguaje que puede comstackrse en las instrucciones de la máquina, y el resultado es velocidad y eficiencia de recursos. Java bytecode puede ser ejecutado por la máquina virtual Java con un rendimiento que se aproxima al de los progtwigs comstackdos, en términos relativos. Esto se debe a la presencia de información de tipo de datos primitivos en el bytecode. La máquina virtual de Java coloca a Java en una categoría propia:

lenguaje interpretado de forma estática portátil

Lo siguiente más cercano es LLVM, pero LLVM opera a un nivel diferente:

lenguaje de ensamblaje interpretado portátil

El término “bytecode” se usa tanto en Java como en Python, pero no todos los bytecode se crean igual. bytecode es solo el término genérico para los lenguajes intermedios utilizados por los comstackdores / intérpretes. Incluso los comstackdores de C como gcc utilizan un lenguaje intermedio (o varios) para realizar el trabajo. El bytecode de Java contiene información sobre los tipos de datos primitivos, mientras que el bytecode de Python no lo hace. En este sentido, la máquina virtual Python (y Bash, Perl, Ruby, etc.) realmente es fundamentalmente más lenta que la máquina virtual Java, o más bien, simplemente tiene más trabajo que hacer. Es útil considerar qué información está contenida en diferentes formatos de código de bytes:

  • llvm: cpu registra
  • Java: tipos de datos primitivos
  • Python: tipos definidos por el usuario

Para dibujar una analogía del mundo real: LLVM trabaja con átomos, la máquina virtual Java trabaja con moléculas y la máquina virtual Python trabaja con materiales. Dado que todo debe eventualmente descomponerse en partículas subatómicas (operaciones de máquina real), la máquina virtual de Python tiene la tarea más compleja.

Los intérpretes / comstackdores de lenguajes de tipo estático simplemente no tienen el mismo equipaje que los intérpretes / comstackdores de lenguajes de tipo dynamic. Los progtwigdores de lenguajes de tipo estático tienen que ocuparse del margen, para lo cual la recompensa es el rendimiento. Sin embargo, al igual que todas las funciones no deterministas son secretamente deterministas, también lo son todas las lenguas de tipo dynamic, de forma estática y de forma estática. Por lo tanto, las diferencias de rendimiento entre las dos familias de idiomas deben nivelarse alrededor del momento en que Python cambia su nombre a HAL 9000.

Las máquinas virtuales de lenguajes dynamics como Python implementan alguna máquina lógica idealizada, y no necesariamente se corresponden muy de cerca con ningún hardware físico real. La máquina virtual de Java, por el contrario, tiene una funcionalidad más similar a la de un comstackdor de C clásico, excepto que, en lugar de emitir instrucciones de la máquina, ejecuta rutinas integradas. En Python, un entero es un objeto de Python con un montón de atributos y métodos adjuntos. En Java, un int es un número designado de bits, generalmente 32. No es realmente una comparación justa. Los enteros de Python realmente deberían compararse con la clase Integer de Java. El tipo de datos primitivos “int” de Java no se puede comparar con nada en el lenguaje Python, porque el lenguaje Python simplemente carece de esta capa de primitivos, y también lo hace el código de bytes de Python.

Debido a que las variables de Java están tipificadas explícitamente, uno puede razonablemente esperar que algo como el rendimiento de Jython esté en el mismo campo de juego que cPython . Por otro lado, una máquina virtual Java implementada en Python está casi garantizada para ser más lenta que el lodo. Y no esperes que a Ruby, Perl, etc., les vaya mejor. Ellos no fueron diseñados para hacer eso. Fueron diseñados para “scripting”, que es como se llama la progtwigción en un lenguaje dynamic.

Cada operación que tiene lugar en una máquina virtual eventualmente tiene que golpear hardware real. Las máquinas virtuales contienen rutinas precomstackdas que son lo suficientemente generales para ejecutar cualquier combinación de operaciones lógicas. Una máquina virtual puede no estar emitiendo nuevas instrucciones de máquina, pero ciertamente está ejecutando sus propias rutinas una y otra vez en secuencias complejas complejas. La máquina virtual de Java, la máquina virtual de Python y todas las otras máquinas virtuales de propósito general que existen por igual son equivalentes en el sentido de que se pueden convencer para que ejecuten cualquier lógica que se pueda imaginar, pero son diferentes en cuanto a las tareas que realizan. Asumir, y qué tareas le dejan al progtwigdor.

Psyco para Python no es una máquina virtual completa de Python, sino un comstackdor justo a tiempo que secuestra la máquina virtual de Python en los puntos que cree que puede comstackr algunas líneas de código, principalmente bucles donde cree que el tipo primitivo de algunos La variable permanecerá constante incluso si el valor cambia con cada iteración. En ese caso, puede renunciar a parte de la incesante determinación de tipo de la máquina virtual normal. Sin embargo, debes tener un poco de cuidado para que no saques el tipo de debajo de los pies de Psyco. Sin embargo, Pysco, por lo general, sabe que solo debe recurrir a la máquina virtual normal si no está completamente seguro de que el tipo no cambiará.

La moraleja de la historia es que la información del tipo de datos primitivos es realmente útil para un comstackdor / máquina virtual.

Finalmente, para ponerlo todo en perspectiva, considere esto: un progtwig Python ejecutado por un intérprete / máquina virtual Python implementado en Java que se ejecuta en un intérprete Java / máquina virtual implementado en LLVM que se ejecuta en una máquina virtual qemu que se ejecuta en un iPhone.

enlace permanente

Probablemente una de las razones de la diferente terminología es que normalmente se piensa en alimentar el código fuente legible para el usuario del intérprete de Python y no preocuparse por el código de bytes y todo eso.

En Java, tiene que comstackr explícitamente a bytecode y luego ejecutar solo el bytecode, no el código fuente en la VM.

A pesar de que Python utiliza una máquina virtual bajo la cubierta, desde la perspectiva de un usuario, uno puede ignorar este detalle la mayor parte del tiempo.

Intérprete , traduce el código fuente en una representación intermedia (código) eficiente y lo ejecuta de inmediato.

La máquina virtual ejecuta de forma explícita el código previamente comstackdo almacenado por un comstackdor que forma parte del sistema de intérprete.

Una característica muy importante de una máquina virtual es que el software que se ejecuta en su interior está limitado a los recursos proporcionados por la máquina virtual. Precisamente, no puede salir de su mundo virtual. Piense en la ejecución segura de código remoto, Java Applets.

En el caso de python, si mantenemos archivos pyc , como se menciona en el comentario de esta publicación, entonces el mecanismo se volvería más como una máquina virtual, y este código de bytes se ejecuta más rápido, aún se interpretaría pero desde una forma mucho más amigable con la computadora . Si observamos esto como un todo, PVM es un último paso del intérprete de Python.

La conclusión es que, cuando se refiere al intérprete de Python, significa que lo estamos refiriendo en su totalidad, y cuando decimos PVM, eso significa que solo estamos hablando de una parte del intérprete de Python, un entorno de tiempo de ejecución. Similar a la de Java, referimos diferentes partes differentyl, JRE, JVM, JDK, etc.

Para más información, Wikipedia Entry: Intérprete , y Máquina Virtual . Otro más aquí . Aquí puede encontrar la comparación de máquinas virtuales de aplicación . Ayuda a comprender la diferencia entre comstackdores, intérpretes y máquinas virtuales.

El término intérprete es un término heredado que se remonta a lenguajes anteriores de shell scripting. A medida que los “lenguajes de scripting” se han convertido en lenguajes con todas las funciones y sus plataformas correspondientes se han vuelto más sofisticadas y aisladas, la distinción entre una máquina virtual y un intérprete (en el sentido de Python) es muy pequeña o inexistente.

El intérprete de Python todavía funciona de la misma manera que un script de shell, en el sentido de que puede ejecutarse sin un paso de comstackción separado. Más allá de eso, las diferencias entre el intérprete de Python (o Perl o Ruby’s) y la máquina virtual de Java son en su mayoría detalles de implementación. (Se podría argumentar que Java es más completamente aislado que Python, pero ambos proporcionan acceso a la architecture subyacente a través de una interfaz C nativa).

No hay una diferencia real entre ellos, la gente simplemente sigue las convenciones que los creadores han elegido.

No olvide que Python tiene comstackdores JIT disponibles para x86, lo que confunde aún más el problema. (Ver psico).

Una interpretación más estricta de un ‘lenguaje interpretado’ solo se vuelve útil cuando se analizan los problemas de rendimiento de la máquina virtual, por ejemplo, en comparación con Python, Ruby fue (¿es?) Considerado más lento porque es un lenguaje interpretado, a diferencia de Python, en otras Palabras, el contexto lo es todo.

Para proporcionar una respuesta profunda a la pregunta ” ¿Por qué la máquina virtual Java, pero el intérprete de Python? “, Intentemos volver al campo de la teoría de la comstackción en cuanto al punto de inicio de la discusión.

El proceso típico de comstackción del progtwig incluye los siguientes pasos:

  1. Análisis léxico . Divide el texto del progtwig en “palabras” significativas llamadas tokens (como parte del proceso, se eliminan todos los comentarios, espacios, nuevas líneas, etc. porque no afectan el comportamiento del progtwig). El resultado es un flujo ordenado de fichas.
  2. Análisis de la syntax . Construye el llamado árbol de syntax abstracta (AST) a partir de la secuencia de tokens. AST establece relaciones entre tokens y, como consecuencia, define un orden de evaluación del progtwig.
  3. Análisis semántico . Verifica la corrección semántica del AST utilizando información sobre los tipos y un conjunto de reglas semánticas del lenguaje de progtwigción. (Por ejemplo, a = b + c es una afirmación correcta desde el punto de vista de la syntax, pero completamente incorrecta desde el punto de vista semántico si a se declaró como un objeto constante)
  4. Generación de código intermedio . Serializa AST en el flujo ordenado linealmente de operaciones “primitivas” independientes de la máquina. De hecho, el generador de código atraviesa AST y registra el orden de los pasos de evaluación. Como resultado, a partir de la representación en forma de árbol del progtwig, logramos una representación en forma de lista mucho más simple en la que se conserva el orden de evaluación del progtwig.
  5. Generación de código de máquina . El progtwig en forma de código de bytes “primitivo” independiente de la máquina se traduce en código de máquina de una architecture de procesador particular.

De acuerdo. Vamos a definir ahora los términos.

Intérprete , en el significado clásico de esa palabra, asume la ejecución basada en la evaluación del progtwig basada en AST producida directamente del texto del progtwig. En ese caso, un progtwig se distribuye en forma de código fuente y el intérprete es alimentado por el texto del progtwig, con frecuencia de forma dinámica (statement por statement o línea por línea). Para cada statement de entrada, el intérprete construye su AST e inmediatamente lo evalúa cambiando el “estado” del progtwig. Este es un comportamiento típico demostrado por los lenguajes de scripting. Considere, por ejemplo, Bash, Windows CMD, etc. Conceptualmente, Python también toma este camino.

Si reemplazamos el paso de ejecución basado en AST en la generación del paso intermedio de código de byte binario independiente de la máquina en el intérprete, dividiremos el proceso completo de ejecución del progtwig en dos fases separadas: comstackción y ejecución. En ese caso, lo que anteriormente era un intérprete se convertirá en un comstackdor de bytecode, que transformará el progtwig de la forma del texto en alguna forma binaria . Luego, el progtwig se distribuye en esa forma binaria, pero no en forma de código fuente. En la máquina del usuario, ese bytecode se alimenta a una nueva entidad: la máquina virtual , que de hecho interpreta ese bytecode. Debido a esto, las máquinas virtuales también se denominan intérprete de código de bytes . ¡Pero pon tu atención aquí! Un intérprete clásico es un intérprete de texto , pero una máquina virtual es un intérprete binario . Este es un enfoque adoptado por Java y C #.

Finalmente, si agregamos la generación de código de máquina al comstackdor de bytecode conseguimos como resultado lo que llamamos un comstackdor clásico. Un comstackdor clásico convierte el código fuente del progtwig en el código de máquina de un procesador particular. Ese código de máquina puede ejecutarse directamente en el procesador de destino sin ninguna mediación adicional (sin ningún tipo de intérprete, ni intérprete de texto ni intérprete binario).

Ahora volvamos a la pregunta original y consideremos Java vs Python.

Java fue diseñado inicialmente para tener la menor cantidad posible de dependencias de implementación. Su diseño se basa en el principio “escribir una vez, ejecutar en cualquier lugar” (WORA). Para implementarlo, Java se diseñó inicialmente como un lenguaje de progtwigción que se comstack en un bytecode binario independiente de la máquina, que luego se puede ejecutar en todas las plataformas que soportan Java sin la necesidad de su recomstackción. Puedes pensar en Java como en C ++ basado en WORA. En realidad, Java está más cerca de C ++ que de los lenguajes de script como Python . Pero a diferencia de C ++ , Java fue diseñado para comstackrse en un bytecode binario que luego se ejecuta en el entorno de la máquina virtual , mientras que C ++ fue diseñado para ser comstackdo en código de máquina y luego ejecutado directamente por el procesador de destino.

Python se diseñó inicialmente como un tipo de lenguaje de progtwigción de scripts que interpreta scripts (progtwigs en forma de texto escrito de acuerdo con las reglas del lenguaje de progtwigción). Debido a esto, Python ha admitido inicialmente una interpretación dinámica de comandos o declaraciones de una línea, como hacen Bash o Windows CMD. Por la misma razón, las implementaciones iniciales de Python no tenían ningún tipo de comstackdores de bytecode y máquinas virtuales para la ejecución de dicho bytecode, pero desde el principio Python había requerido un intérprete capaz de entender y evaluar el texto del progtwig de Python.

Debido a esto, históricamente, los desarrolladores de Java solían hablar sobre la Máquina Virtual de Java (porque inicialmente, Java ha venido como paquete del comstackdor de bytecode de Java y el intérprete de bytecodeJVM ), y los desarrolladores de Python tienden a hablar sobre el intérprete de Python (porque inicialmente Python tiene no era una máquina virtual y era un tipo de intérprete de texto clásico que ejecuta el texto del progtwig directamente sin ningún tipo de comstackción o transformación en cualquier forma de código binario).

Actualmente, Python también tiene la máquina virtual bajo el capó y puede comstackr e interpretar el código de bytes de Python. Y ese hecho hace una inversión adicional en la confusión ” ¿Por qué la Máquina Virtual Java, pero el intérprete de Python? “, Porque parece que las implementaciones de ambos lenguajes contienen máquinas virtuales. ¡Pero! Incluso en el momento actual, la interpretación del texto del progtwig es una forma principal de ejecución de los progtwigs Python. Las implementaciones de Python explotan máquinas virtuales bajo el capó exclusivamente como una técnica de optimización. La interpretación del código de bytes binario en la máquina virtual es mucho más eficiente que una interpretación directa del texto del progtwig original. Al mismo tiempo, la presencia de la máquina virtual en Python es absolutamente transparente tanto para los diseñadores de lenguaje Python como para los desarrolladores de progtwigs Python. El mismo lenguaje se puede implementar en intérpretes con y sin la máquina virtual. De la misma manera, los mismos progtwigs pueden ejecutarse en intérpretes con y sin la máquina virtual, y esos progtwigs demostrarán exactamente el mismo comportamiento y producirán igualmente la misma salida de la misma entrada. La única diferencia observable será la velocidad de ejecución del progtwig y la cantidad de memoria consumida por el intérprete. Por lo tanto, la máquina virtual en Python no es una parte inevitable del diseño del lenguaje, sino una extensión opcional del principal intérprete de Python.

Java puede ser considerado de una manera similar. Java bajo el capó tiene un comstackdor JIT y puede comstackr selectivamente los métodos de la clase Java en el código de máquina de la plataforma de destino y luego ejecutarlo directamente. ¡Pero! Java todavía utiliza la interpretación de bytecode como una forma principal de ejecución del progtwig Java. Al igual que las implementaciones de Python que explotan las máquinas virtuales bajo el capó exclusivamente como una técnica de optimización, las máquinas virtuales de Java usan comstackdores Just-In-Time exclusivamente para fines de optimización. Del mismo modo, solo por el hecho de que la ejecución directa del código de la máquina es al menos diez veces más rápida que la interpretación del código de bytes de Java. Y como en el caso de Python, la presencia de comstackdor JIT bajo el capó de JVM es absolutamente transparente tanto para los diseñadores de lenguaje Java como para los desarrolladores de progtwigs Java. JVM puede implementar el mismo lenguaje de progtwigción Java con y sin el comstackdor JIT. Y de la misma manera, los mismos progtwigs se pueden ejecutar en JVM con y sin JIT en el interior, y los mismos progtwigs demostrarán exactamente el mismo comportamiento y producirán igualmente la misma salida de la entrada igual en ambas JVM (con y sin JIT). Y como en el caso de Python, la única diferencia observable entre ellos, será en la velocidad de ejecución y en la cantidad de memoria consumida por JVM. Y finalmente, como en el caso de Python, JIT en Java tampoco es una parte inevitable del diseño del lenguaje, sino solo una extensión opcional de las principales implementaciones de JVM.

Desde el punto de vista del diseño e implementación de máquinas virtuales de Java y Python, difieren significativamente, mientras que (¡atención!) Ambas siguen siendo máquinas virtuales. JVM es un ejemplo de una máquina virtual de bajo nivel con operaciones básicas simples y un alto costo de envío de instrucciones. Python, a su vez, es una máquina virtual de alto nivel, para la cual las instrucciones demuestran un comportamiento complejo, y el costo de envío de instrucciones no es tan importante. Java opera con muy bajo nivel de abstracción. JVM opera en el pequeño conjunto bien definido de tipos primitivos y tiene una correspondencia muy estrecha (generalmente de uno a uno) entre las instrucciones del código de bytes y las instrucciones del código de máquina nativo. Por el contrario, la máquina virtual de Python opera a un alto nivel de abstracción, opera con tipos de datos complejos (objetos) y admite polymorphism ad hoc, mientras que las instrucciones de bytecode exponen un comportamiento complejo, que puede ser representado por una serie de múltiples instrucciones de código de máquina nativas. Por ejemplo, Python es compatible con las matemáticas de rango ilimitado. Por lo tanto, Python VM se ve obligada a explotar la aritmética larga para los enteros potencialmente grandes, cuyo resultado de la operación puede desbordar la palabra de la máquina. Por lo tanto, una instrucción de código de bytes para aritmética en Python puede exponerse en la llamada de función dentro de Python VM, mientras que en la operación aritmética JVM se expondrá en una operación simple expresada por una o unas pocas instrucciones de máquina nativas.

Como resultado, podemos sacar las siguientes conclusiones. La máquina virtual de Java pero el intérprete de Python es porque:

  1. El término máquina virtual asume la interpretación del código de bytes binario, mientras que el intérprete del término asume la interpretación del texto del progtwig.
  2. Históricamente, Java se diseñó e implementó para la interpretación de códigos de bytes binarios y Python se diseñó e implementó inicialmente para la interpretación de texto de progtwig. Por lo tanto, el término “Máquina virtual de Java” es histórico y está bien establecido en la comunidad de Java. Y de manera similar, el término “intérprete de Python” es histórico y está bien establecido en la comunidad de Python. Los pueblos tienden a prolongar la tradición y usan los mismos términos que se usaron mucho antes.
  3. Finalmente, actualmente, para Java, la interpretación del código de bytes binario es una forma principal de ejecución de progtwigs, mientras que la comstackción JIT es solo una optimización opcional y transparente. Y para Python, actualmente, la interpretación de texto de progtwig es una forma principal de ejecución de progtwigs de Python, mientras que la comstackción en el código de bytes de Python VM es solo una optimización opcional y transparente.

Por lo tanto, tanto Java como Python tienen máquinas virtuales que son intérpretes de código de bytes binarios, lo que puede generar confusión, como ” ¿Por qué la Máquina Virtual de Java, pero el intérprete de Python? ” El punto clave aquí es que para Python, una máquina virtual no es un medio primario o necesario para la ejecución del progtwig; Es solo una extensión opcional del intérprete de texto clásico. Por otro lado, una máquina virtual es una parte fundamental e inevitable del ecosistema de ejecución de progtwigs Java. La elección de escritura estática o dinámica para el diseño del lenguaje de progtwigción afecta principalmente el nivel de abstracción de la máquina virtual, pero no determina si se necesita o no una máquina virtual. Los idiomas que utilizan ambos sistemas de escritura pueden diseñarse para comstackrse, interpretarse o ejecutarse en el entorno de la máquina virtual, según el modelo de ejecución deseado.

En primer lugar, debe comprender que la progtwigción o la informática en general no son matemáticas y no tenemos definiciones rigurosas para la mayoría de los términos que usamos con frecuencia.

Ahora a tu pregunta:

¿Qué es un intérprete (en informática)?

Traduce el código fuente a la unidad ejecutable más pequeña y luego ejecuta esa unidad.

¿Qué es una máquina virtual?

En el caso de JVM, la máquina virtual es un software que contiene un intérprete, cargadores de clases, recolector de basura, progtwigdor de hilos, comstackdor JIT y muchas otras cosas.

Como puede ver, el intérprete es una parte o JVM y no se puede llamar intérprete a la JVM completa porque contiene muchos otros componentes.

¿Por qué usar la palabra “Intérprete” cuando se habla de python?

Con java la parte de comstackción es explícita. Python, por otro lado, no es explícito como java sobre su proceso de comstackción e interpretación, desde la perspectiva del usuario final, el único mecanismo utilizado para ejecutar progtwigs de python.

No, ambos no interpretan el código byte.

Python solo interpreta el bytecode si está ejecutando pypy. De lo contrario, se comstack en C y se interpreta a ese nivel.

Java comstack a bytecode.