Python的“虚拟机”似乎很少读到,而在Java中“虚拟机”一直被使用。
两者都解释字节码;为什么一个叫虚拟机,另一个叫解释器?
Python的“虚拟机”似乎很少读到,而在Java中“虚拟机”一直被使用。
两者都解释字节码;为什么一个叫虚拟机,另一个叫解释器?
当前回答
我认为两者之间的界限是模糊的,人们大多争论的是“解释器”这个词的含义,以及语言与“解释器……编译器”范围的每一方有多接近。然而,没有一个是100%的。我认为编写Java或Python实现是很容易的,这是频谱的任何价值。
目前Java和Python都有虚拟机和字节码,尽管一个操作具体的值大小(如32位整数),而另一个必须确定每次调用的大小,在我看来,这并没有定义术语之间的边界。
Python没有正式定义的字节码,它只存在于内存中,这一论点也不能说服我,只是因为我计划开发只识别Python字节码的设备,编译部分将在浏览器JS机器中完成。
性能只与具体的实现有关。我们不需要知道对象的大小就能处理它,最后,在大多数情况下,我们处理的是结构,而不是基本类型。可以通过重用现有对象来优化Python VM,从而消除每次在表达式计算期间创建新对象的需要。一旦完成,在计算两个整数的和之间没有全局性能差异,这是Java的闪光点。
两者之间没有致命的区别,只有一些与最终用户无关的实现上的细微差别和缺乏优化,可能在她开始注意到性能滞后的时候,但这又是实现而不是架构的问题。
其他回答
首先,你应该明白,编程或计算机科学一般不是数学,我们经常使用的大多数术语都没有严格的定义。
现在回答你的问题:
什么是解释器(计算机科学)
它按最小的可执行单元翻译源代码,然后执行该单元。
什么是虚拟机
对于JVM来说,虚拟机是一个包含解释器、类加载器、垃圾收集器、线程调度器、JIT编译器和许多其他东西的软件。
正如你所看到的,解释器是JVM的一部分,整个JVM不能被称为解释器,因为它包含许多其他组件。
为什么在谈论python时要用“解释器”这个词
在Java中,编译部分是显式的。 另一方面,Python的编译和解释过程不像Java那样明确,从最终用户的角度来看,解释是用于执行Python程序的唯一机制
不要忘记Python为x86提供了JIT编译器,这进一步混淆了问题。(见psyco)。
对“解释型语言”的更严格的解释只有在讨论VM的性能问题时才有用,例如,与Python相比,Ruby被认为更慢,因为它是一种解释型语言,不像Python——换句话说,上下文就是一切。
术语解释器是一个遗留术语,可以追溯到早期的shell脚本语言。由于“脚本语言”已经演变成功能齐全的语言,它们对应的平台也变得更加复杂和沙箱化,虚拟机和解释器(在Python意义上)之间的区别非常小,甚至不存在。
Python解释器仍然以与shell脚本相同的方式运行,从某种意义上说,它可以在不需要单独的编译步骤的情况下执行。除此之外,Python解释器(或Perl或Ruby的)和Java虚拟机之间的区别主要是实现细节。(有人可能会说Java比Python更加完全沙箱化,但两者最终都通过原生C接口提供对底层架构的访问。)
术语不同的一个原因可能是,人们通常认为向python解释器提供人类可读的原始源代码,而不用担心字节码之类的问题。
在Java中,必须显式地编译为字节码,然后在VM上只运行字节码,而不是源代码。
尽管Python在幕后使用虚拟机,但从用户的角度来看,大多数时候可以忽略这个细节。
解释器,翻译源代码为一些有效的中间表示(代码),并立即执行。
虚拟机,显式地执行存储的预编译代码,由编译器构建,它是解释器系统的一部分。
虚拟机的一个非常重要的特征是,在虚拟机内部运行的软件,受限于虚拟机提供的资源。确切地说,它无法跳出它的虚拟世界。想想远程代码的安全执行,Java applet。
在python的情况下,如果我们保留pyc文件,就像这篇文章的评论中提到的,那么这个机制将变得更像一个虚拟机,并且这个字节码执行得更快——它仍然会被解释,但从一个更计算机友好的形式。如果我们从整体上看,PVM是Python解释器的最后一步。
底线是,当我们提到Python解释器时,这意味着我们将其作为一个整体来引用,而当我们说PVM时,这意味着我们只是在谈论Python解释器的一部分,一个运行时环境。类似于Java,我们引用不同的部分,JRE, JVM, JDK等。
有关更多信息,请参阅维基百科条目:解释器和虚拟机。这里还有一个。在这里您可以找到应用程序虚拟机的比较。它有助于理解编译器,解释器和vm之间的区别。