blocks|key|1436759|text|它们之间没有真正的区别，人们只是遵循创建者选择的惯例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1436760|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There's no real difference between them, people just follow the conventions the creators have chosen.

blocks|key|1651314|text|可能出现不同术语的原因之一是，人们通常会考虑向python解释器提供原始的、人类可读的源代码，而不是担心字节码之类的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1651315|在Java中，您必须显式地编译成字节码，然后在VM上只运行字节码，而不运行源代码。|1651316|尽管Python在幕后使用虚拟机，但从用户的角度来看，大多数时候可以忽略这一细节。|1651317|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Probably one reason for the different terminology is that one normally thinks of feeding the python interpreter raw human-readable source code and not worrying about bytecode and all that. 

In Java, you have to explicitly compile to bytecode and then run just the bytecode, not source code on the VM. 

Even though Python uses a virtual machine under the covers, from a user's perspective, one can ignore this detail most of the time.

blocks|key|1436852|text|术语解释器是一个遗留下来的术语，可以追溯到早期的shell脚本语言。随着“脚本语言”演变成功能齐全的语言，以及它们对应的平台变得更加复杂和沙箱，虚拟机和解释器(在Python意义上)之间的区别变得非常小或根本不存在。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1436853|Python解释器仍然以与shell脚本相同的方式工作，在这个意义上，它可以在没有单独的编译步骤的情况下执行。除此之外，Python的解释器(或Perl或Ruby)与Java的虚拟机之间的差异主要是实现细节。(有人可能会争辩说，Java比Python更完整的沙箱，但两者最终都通过本机C接口提供对底层体系结构的访问。)|1436854|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The term interpreter is a legacy term dating back to earlier shell scripting languages. As "scripting languages" have evolved into full featured languages and their corresponding platforms have become more sophisticated and sandboxed, the distinction between a virtual machine and an interpreter (in the Python sense), is very small or non-existent.

The Python interpreter still functions in the same way as a shell script, in the sense that it can be executed without a separate compile step. Beyond that, the differences between Python's interpreter (or Perl or Ruby's) and Java's virtual machine are mostly implementation details. (One could argue that Java is more fully sandboxed than Python, but both ultimately provide access to the underlying architecture via a native C interface.)

blocks|key|1436909|text|不要忘记，Python提供了适用于x86的即时编译器，这进一步混淆了问题。(请参阅)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1436910|对“解释语言”的更严格的解释只有在讨论VM的性能问题时才会变得有用，例如，与Python相比，Ruby+was+(is?)被认为是较慢的，因为它是一种解释型语言，不像Python+-换句话说，上下文决定一切。|1436911|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Don't forget that Python has JIT compilers available for x86, further confusing the issue. (See psyco).

A more strict interpretation of an 'interpreted language' only becomes useful when discussing performance issues of the VM, for example, compared with Python, Ruby was (is?) considered to be slower because it is an interpreted language, unlike Python - in other words, context is everything.

blocks|key|1651519|text|虚拟机是一个虚拟计算环境，它具有一组特定的原子定义良好的指令，这些指令独立于任何特定的语言而被支持，并且通常被认为是其自身的沙箱。VM类似于特定CPU的指令集，并且倾向于在更基本的级别上工作，这些指令(或字节码)的非常基本的构建块独立于下一个。指令仅基于虚拟机的当前状态来确定性地执行，并且不依赖于在该时间点的指令流中的其他信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1651520|另一方面，解释器更复杂，因为它被定制为解析特定语言和特定语法的某些语法流，这些语法流必须在周围标记的上下文中解码。您不能孤立地查看每一个字节，甚至每一行，并且确切地知道下一步要做什么。语言中的标记不能像相对于VM的指令(字节码)那样孤立地使用。|1651521|Java编译器将Java语言转换为字节码流，就像C编译器将C语言程序转换为汇编代码一样。另一方面，解释器并不真正将程序转换为任何定义良好的中间形式，它只是将程序操作视为解释源代码的过程。|1651522|VM和解释器之间的区别的另一个测试是您是否认为它是独立于语言的。我们所知道的Java+VM实际上并不是Java特有的。您可以从其他语言生成可在JVM上运行的字节码的编译器。另一方面，我不认为我们真的会考虑将Python之外的其他语言“编译”成Python以供Python解释器解释。|1651523|由于解释过程的复杂性，这可能是相对较慢的process....specifically解析和识别语言标记等，并且理解源的上下文以便能够在解释器内进行执行过程。为了帮助加速这样的解释型语言，我们可以在这里定义更容易直接解释的预解析、预标记化源代码的中间形式。这种二进制形式在执行时仍然会被解释，它只是从一种人类可读的形式开始，以提高性能。然而，执行这种形式的逻辑不是虚拟机，因为这些代码仍然不能被孤立地处理-周围令牌的上下文仍然很重要，它们现在只是以一种不同的、更有效的计算机形式。|1651524|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

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.

An interpreter on the other hand is more sophisticated in that it is tailored to parse a stream of some syntax that is of a specific language and of a specific grammer that must be decoded in the context of the surrounding tokens. You can't look at each byte or even each line in isolation and know exactly what to do next. The tokens in the language can't be taken in isolation like they can relative to the instructions (byte codes) of a VM.

A Java compiler converts Java language into a byte-code stream no different than a C compiler converts C Language programs into assembly code. An interpreter on the other hand doesn't really convert the program into any well defined intermediate form, it just takes the program actions as a matter of the process of interpreting the source.

Another test of the difference between a VM and an interpreter is whether you think of it as being language independent. What we know as the Java VM is not really Java specific. You could make a compiler from other languages that result in byte codes that can be run on the JVM. On the other hand, I don't think we would really think of "compiling" some other language other than Python into Python for interpretation by the Python interpreter.

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.

blocks|key|1437033|text|不，它们都不能解释字节码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1437034|如果使用pypy运行，Python只解释字节码。否则，它将被编译成C语言，并在该级别进行解释。|1437035|Java编译成字节码。|1437036|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

No, they don't both interpret byte code.

Python only interprets bytecode if you are running with pypy. Otherwise it is compiled into C and interpreted at that level.

Java compiles to bytecode.

blocks|key|1651654|text|我认为两者之间的界限是模糊的，人们主要围绕“解释器”这个词的含义以及语言与"interpreter...compiler“光谱的两边有多近而争论不休。然而，没有一个是100%25的。我认为编写Java或Python实现是很容易的，它们具有不同的价值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1651655|目前，Java和Python都有虚拟机和字节码，虽然一个是根据具体的值大小(比如32位整数)操作的，而另一个则必须确定每次调用的大小，在我看来，这并没有定义术语之间的边界。|1651656|Python没有正式定义字节码，它只存在于内存中的论点也不能说服我，因为我正计划开发只识别Python字节码的设备，编译部分将在浏览器JS机器中完成。|1651657|性能只是关于具体的实现。我们不需要知道对象的大小就可以使用它，最后，在大多数情况下，我们使用的是结构，而不是基本类型。可以通过重用现有对象来优化Python+VM，从而消除在表达式计算过程中每次创建新对象的需要。一旦完成，在计算两个整数的和之间没有全局性能差异，这正是Java的闪光点。|1651658|这两者之间没有什么致命的区别，只是一些与最终用户无关的实现细微差别和缺乏优化，也许是在她开始注意到性能滞后的时候，但这又是实现而不是架构问题。|1651659|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I think the lines between both are blurred, people mostly argue around meaning of word "interpreter" and how close the language stands to each side of "interpreter...compiler" spectrum. None makes 100% however. I think it is easy to write Java or Python implementation which be of any value of the spectrum.

Currently both Java and Python have virtual machines and bytecode, though one operates by concrete value sizes (like 32-bit integer) while other has to determine the size for each call, which in my opinion doesn't define the border between the terms.

The argument that Python doesn't have officially defined bytecode and it exists only in memory also doesn't convince me, just because I am planning to develop devices which will recognize only Python bytecode and the compilation part will be done in browser JS machine.

Performance is only about the concrete implementation. We don't need to know the size of the object to be able to work with it, and finally, in most cases, we work with structures, not basic types. It is possible to optimize Python VM in the way that it will eliminate the need of creating new object each time during expression calculation, by reusing existing one. Once it is done, there is no global performance difference between calculating sum of two integers, which is where Java shines.

There is no killer difference between the two, only some implementation nuances and lack of optimization which are irrelevant to the end user, maybe up at the point where she starts to notice performance lags, but again it is implementation and not architecture issue.

blocks|key|1651781|text|对于提到python不需要生成字节码的帖子，我不确定这是真的。似乎Python中的所有可调用对象都必须有一个包含字节码的.__code__.co_code属性。我看不出有什么有意义的理由叫Python“未编译”，仅仅是因为编译的工件可能不会被保存；而且通常不是通过Python语言的设计来保存的，例如，所有的理解都会为它的输入编译新的字节码，这就是为什么在compile(mode='exec,+...)和编译compile(mode='single',+...)之间理解变量的作用域是不一致的|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1651782|entityMap^0|1O|H|4Y|O|5P|R|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

for posts that mention that python does not need to generate byte code, I'm not sure that's true. it seems that all callables in Python must have a <code>.__code__.co_code</code> attribute which contains the byte code. I don't see a meaningful reason to call python "not compiled" just because the compiled artifacts may not be saved; and often aren't saved by design in Python, for example all comprehension compile new bytecode for it's input, this is the reason comprehension variable scope is not consistent between <code>compile(mode='exec, ...)</code> and compile <code>compile(mode='single', ...)</code> such as between running a python script and using pdb

blocks|key|1651893|text|实际上，HotSpot运行时被称为虚拟机，而CPython仅被称为解释器，这可能是有原因的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1651894|首先，CPython只是一个普通的基于堆栈的字节码解释器。您向其中输入Python操作码，CPython内部的软件堆栈机器将评估您的代码，就像普通解释器一样。|1651895|Java+HotSpot运行时有所不同。首先也是最重要的是，Java有3个即时编译器:+C1、C2和一个尚未使用的试验性编译器。但这并不是主要原因。JVM内部的解释器是一种非常特殊的解释器，称为模板解释器。CPython中的模板解释器包含了一个巨大的数组列表，而不是像JVM+(实际上几乎所有其他解释器都是这样)那样，在一个庞大的操作码切换case语句中直接执行字节码。它包含了什么？字节码和本机CPU指令的键值对！arraylist在启动时是空的，并且充满了字节码的映射，这些字节码指向直接在应用程序启动前在硬件上运行的本机语言，这意味着JVM中的“解释器”实际上根本不是解释器-它实际上是一个折扣编译器！当Java字节码运行时，“解释器”简单地将输入字节码直接映射到本机语言，并直接执行本机映射，而不是在软件中实现它。我不太确定为什么JVM是这样制作的，但我怀疑这是为了方便地与JIT编译代码无缝地一起执行“解释的”代码，以及速度/性能。如果你让JVM在没有JIT的情况下与CPython或其他大多数解释器竞争，它可能仍然会脱颖而出，因为它的巧妙设计，据我所知，以前没有其他语言使用过。|1651896|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There actually might be a reason why the HotSpot runtime is called a Virtual Machine while CPython is merely referred to as an interpreter
Firstly, CPython is just your average run of the mill, stack based, bytecode interpreter. You input Python opcode into it, and the software stack machine inside CPython evaluates your code, just like a normal Interpreter would.
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 &quot;Interpreter&quot; inside the JVM isn't actually an Interpreter at all- It's actually a discount Compiler! When Java bytecode is run, the &quot;Interpreter&quot; 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 &quot;Interpreted&quot; 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.

It seems rare to read of a Python "virtual machine" while in Java "virtual machine" is used all the time.

Both interpret byte codes; why call one a virtual machine and the other an interpreter?

Java "Virtual Machine" vs. Python "Interpreter" parlance?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

读到Python中的“虚拟机”似乎并不多见，而在Java中，“虚拟机”却总是被使用。两者都能解释字节码；为什么一个叫虚拟机，另一个叫解释器？

问Java“虚拟机”与Python“解释器”的说法？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java“虚拟机”与Python“解释器”的说法？EN