不要忘记Python为x86提供了JIT编译器，这进一步混淆了问题。(见psyco)。

对“解释型语言”的更严格的解释只有在讨论VM的性能问题时才有用，例如，与Python相比，Ruby被认为更慢，因为它是一种解释型语言，不像Python——换句话说，上下文就是一切。

A virtual machine is a virtual computing environment with a specific set of atomic well defined instructions that are supported independent of any specific language and it is generally thought of as a sandbox unto itself. The VM is analogous to an instruction set of a specific CPU and tends to work at a more fundamental level with very basic building blocks of such instructions (or byte codes) that are independent of the next. An instruction executes deterministically based only on the current state of the virtual machine and does not depend on information elsewhere in the instruction stream at that point in time.

另一方面，解释器更复杂，因为它是为解析特定语言和特定语法的某些语法流而定制的，这些语法必须在周围标记的上下文中进行解码。您不能单独地查看每个字节甚至每一行，然后确切地知道下一步该做什么。语言中的令牌不能像相对于VM的指令(字节码)那样孤立地获取。

Java编译器将Java语言转换为字节码流，与C编译器将C语言程序转换为汇编代码没有什么不同。另一方面，解释器并不真正将程序转换为任何定义良好的中间形式，它只是将程序操作作为解释源代码的过程。

VM和解释器区别的另一个测试是你是否认为它是独立于语言的。我们所知道的Java虚拟机并不是Java特有的。您可以使用其他语言制作编译器，生成可以在JVM上运行的字节代码。另一方面，我不认为我们真的会考虑将Python以外的其他语言“编译”为Python以供Python解释器解释。

Because of the sophistication of the interpretation process, this can be a relatively slow process....specifically parsing and identifying the language tokens, etc. and understanding the context of the source to be able to undertake the execution process within the interpreter. To help accelerate such interpreted languages, this is where we can define intermediate forms of pre-parsed, pre-tokenized source code that is more readily directly interpreted. This sort of binary form is still interpreted at execution time, it is just starting from a much less human readable form to improve performance. However, the logic executing that form is not a virtual machine, because those codes still can't be taken in isolation - the context of the surrounding tokens still matter, they are just now in a different more computer efficient form.

在本文中，“虚拟机”指的是进程虚拟机，不是指 系统虚拟机，如Qemu或Virtualbox。进程虚拟机为 一个简单的程序，它提供了一个通用的编程环境——程序 这是可以编程的。

Java has an interpreter as well as a virtual machine, and Python has a virtual machine as well as an interpreter. The reason "virtual machine" is a more common term in Java and "interpreter" is a more common term in Python has a lot to do with the major difference between the two languages: static typing (Java) vs dynamic typing (Python). In this context, "type" refers to primitive data types -- types which suggest the in-memory storage size of the data. The Java virtual machine has it easy. It requires the programmer to specify the primitive data type of each variable. This provides sufficient information for Java bytecode not only to be interpreted and executed by the Java virtual machine, but even to be compiled into machine instructions. The Python virtual machine is more complex in the sense that it takes on the additional task of pausing before the execution of each operation to determine the primitive data types for each variable or data structure involved in the operation. Python frees the programmer from thinking in terms of primitive data types, and allows operations to be expressed at a higher level. The price of this freedom is performance. "Interpreter" is the preferred term for Python because it has to pause to inspect data types, and also because the comparatively concise syntax of dynamically-typed languages is a good fit for interactive interfaces. There's no technical barrier to building an interactive Java interface, but trying to write any statically-typed code interactively would be tedious, so it just isn't done that way.

在Java世界中，虚拟机最引人注目，因为它运行程序 用一种可以编译成机器指令的语言编写， 结果就是速度和资源效率。可以执行Java字节码 通过Java虚拟机，性能接近编译 程序，相对来说。这是由于原始数据的存在 在字节码中键入信息。Java虚拟机将Java放在 自身类别:

可移植的解释静态类型语言

仅次于LLVM的是LLVM，但LLVM在不同的级别上运行:

可移植解释汇编语言

The term "bytecode" is used in both Java and Python, but not all bytecode is created equal. bytecode is just the generic term for intermediate languages used by compilers/interpreters. Even C compilers like gcc use an intermediate language (or several) to get the job done. Java bytecode contains information about primitive data types, whereas Python bytecode does not. In this respect, the Python (and Bash,Perl,Ruby, etc.) virtual machine truly is fundamentally slower than the Java virtual machine, or rather, it simply has more work to do. It is useful to consider what information is contained in different bytecode formats:

Llvm: CPU寄存器 原始数据类型 Python:用户定义类型

做一个现实世界的类比:LLVM使用原子，即Java虚拟机 Python虚拟机处理的是材料。 因为所有东西最终都必须分解成亚原子粒子(真实的 机器操作)，Python虚拟机有最复杂的任务。

Intepreters/compilers of statically-typed languages just don't have the same baggage that interpreters/compilers of dynamically-typed languages have. Programmers of statically-typed languages have to take up the slack, for which the payoff is performance. However, just as all nondeterministic functions are secretly deterministic, so are all dynamically-typed languages secretly statically-typed. Performance differences between the two language families should therefore level out around the time Python changes its name to HAL 9000.

The virtual machines of dynamic languages like Python implement some idealized logical machine, and don't necessarily correspond very closely to any real physical hardware. The Java virtual machine, in contrast, is more similar in functionality to a classical C compiler, except that instead of emitting machine instructions, it executes built-in routines. In Python, an integer is a Python object with a bunch of attributes and methods attached to it. In Java, an int is a designated number of bits, usually 32. It's not really a fair comparison. Python integers should really be compared to the Java Integer class. Java's "int" primitive data type can't be compared to anything in the Python language, because the Python language simply lacks this layer of primitives, and so does Python bytecode.

因为Java变量是显式类型的，所以可以合理地期望 比如Jython的性能在同一范围内 cPython的。另一方面，一个用Python实现的Java虚拟机 肯定比泥的速度要慢。不要指望Ruby, Perl等等， 为了更好的生活。它们的设计初衷不是这样的。它们是为 “脚本”，这是动态语言编程的称呼。

Every operation that takes place in a virtual machine eventually has to hit real hardware. Virtual machines contain pre-compiled routines which are general enough to to execute any combination of logical operations. A virtual machine may not be emitting new machine instructions, but it certainly is executing its own routines over and over in arbirtrarily complex sequences. The Java virtual machine, the Python virtual machine, and all the other general-purpose virtual machines out there are equal in the sense that they can be coaxed into performing any logic you can dream up, but they are different in terms of what tasks they take on, and what tasks they leave to the programmer.

Psyco for Python is not a full Python virtual machine, but a just-in-time compiler that hijacks the regular Python virtual machine at points it thinks it can compile a few lines of code -- mainly loops where it thinks the primitive type of some variable will remain constant even if the value is changing with each iteration. In that case, it can forego some of the incessent type determination of the regular virtual machine. You have to be a little careful, though, lest you pull the type out from under Psyco's feet. Pysco, however, usually knows to just fall back to the regular virtual machine if it isn't completely confident the type won't change.

这个故事的寓意是原始数据类型信息实际上是 有助于编译器/虚拟机。

最后，考虑以下情况:执行一个Python程序 由Python解释器/运行在Java上的Java虚拟机实现 解释器/虚拟机在LLVM中实现，运行在qemu虚拟中 在iPhone上运行的机器

永久链接

Python可以解释代码，而无需将其编译为字节码。Java不能。

Python是一种解释型语言，而不是编译型语言，尽管由于字节码编译器的存在，两者的区别可能很模糊。这意味着源文件可以直接运行，而无需显式地创建一个可执行文件，然后再运行。

(来自文档)。

在java中，每个文件都必须编译为.class文件，然后在JVM上运行。相反，python会通过主脚本导入这些文件，以帮助加快后续使用这些文件的速度。

然而，在典型的情况下，大多数python(至少是CPython)代码运行在模拟的堆栈机器中，它与JVM的指令几乎相同，因此没有太大的区别。

然而，这种区别的真正原因是，从一开始，java就把自己打上了“可移植的、可执行的字节码”的标签，而python则把自己打上了带有REPL的动态解释语言的标签。名字贴!

不要忘记Python为x86提供了JIT编译器，这进一步混淆了问题。(见psyco)。

对“解释型语言”的更严格的解释只有在讨论VM的性能问题时才有用，例如，与Python相比，Ruby被认为更慢，因为它是一种解释型语言，不像Python——换句话说，上下文就是一切。

HotSpot运行时被称为虚拟机，而CPython仅仅被称为解释器，这可能是有原因的

首先，CPython只是普通的、基于栈的字节码解释器。你向它输入Python操作码，CPython内部的软件堆栈机器就会计算你的代码，就像普通的解释器一样。

The Java HotSpot runtime is different. First and foremost, Java has 3 Just-in Time Compilers, C1, C2, and an experimental one that isn't in use yet. But that's not the main reason. The Interpreter inside the JVM is a very special kind of Interpreter called a Template Interpreter. Instead of just executing bytecode directly in a massive opcode switch case statement like CPython (And really almost every other interpreter does) does, the Template Interpreter inside the JVM contains an enormous arraylist. What does it contain? Key-value pairs of bytecodes and native CPU instructions! The arraylist is empty on startup and is filled with mappings of bytecodes pointing to native machine language to be directly run on the hardware just before your application starts up, what this means is that the "Interpreter" inside the JVM isn't actually an Interpreter at all- It's actually a discount Compiler! When Java bytecode is run, the "Interpreter" simply maps the input bytecode directly to native machine language and executes the native mapping directly, rather than implementing it in software. I'm not exactly sure why the JVM was made this way, but I suspect it was to easily execute "Interpreted" Code together with JIT Compiled Code seamlessly, and for speed/performance. If you pitted the JVM without JIT against CPython or most other interpreters it would still probably come out ahead of them, in virtue of its ingenious design which to my knowledge no other language has used before.