编译语言与解释语言

21 浏览
0 Comments

编译语言与解释语言

我试图更好地理解它们之间的区别。我在网上找到了很多解释,但它们往往偏向抽象的差异而不是实际影响。\n我大部分的编程经验都来自于CPython(动态、解释型)和Java(静态、编译型)。然而,我了解到还有其他类型的解释型和编译型语言。除了编译型语言可以从程序中分发可执行文件这一事实之外,每种类型都有哪些优缺点呢?很多时候,我听到人们争论解释型语言可以交互使用,但我相信编译型语言也可以有交互式实现,对吗?

0
0 Comments

过去,计算机领域存在着解释器和编译器的争议。解释器开发快,但执行速度慢,因为每次执行都要将语句解释为机器代码(对于执行数千次的循环来说,这意味着什么);而编译器开发慢,但执行速度快,因为整个程序已经是本机机器代码。解释器和编译器之间的运行时性能存在一到两个数量级的差异。其他区别点,比如运行时代码的可变性,也有一定的兴趣,但主要区别还是围绕运行时性能问题。

然而,如今的计算机领域已经发展到了一个程度,编译/解释的区别几乎无关紧要。许多编译语言调用的运行时服务并不完全基于机器代码。而大多数解释语言在执行之前都会被“编译”成字节码。字节码解释器可以非常高效,并在执行速度上与一些编译器生成的代码媲美。

经典的区别是编译器生成本机机器代码,而解释器读取源代码,并使用某种运行时系统即时生成机器代码。如今,几乎没有经典的解释器留下来,它们几乎都会编译成字节码(或其他半编译状态),然后在虚拟“机器”上运行。

0
0 Comments

编译语言和解释语言之间的区别是一个常见的问题。一个语言本身并不是编译的或者解释的,只有语言的具体实现才是。例如,Java就是一个很好的例子。它有基于字节码的平台(JVM),一个本地编译器(gcj)以及一个解释器(bsh)来支持Java的超集。那么Java到底是什么呢?是字节码编译的,本地编译的还是解释的呢?

其他一些同时支持编译和解释的语言有Scala、Haskell和Ocaml。每种语言都有一个交互式解释器,以及一个编译器可以将代码编译成字节码或者本地机器码。

因此,通常将语言归类为“编译”和“解释”并没有太多意义。

我同意这个观点。或者说:有一些本地编译器(直接生成供CPU执行的机器码),还有一些不太本地的编译器(生成标记化的中间代码,即中间码,然后由即时编译器在运行时编译成机器码),还有一些“真正”的非编译器,它们从不产生机器码,也不让CPU执行代码。后者被称为解释器。如今,直接在编译时生成机器(CPU)代码的本地编译器越来越少见。Delphi/Codegear是其中一个最好的幸存者。

所以,编译语言和解释语言之间的区别并不是非常明显,因为有很多语言既可以编译也可以解释。具体要选择哪种方式,取决于语言的实现和使用场景。

0
0 Comments

编译语言是指一旦编译完成,程序就以目标机器的指令表示。相反,解释语言不直接由目标机器执行指令,而是由其他程序读取和执行(通常以本机语言编写)。编译语言和解释语言都是图灵完备的,可以实现相同的功能,但在实现和使用上都有优缺点。

编译语言的优点包括:

- 通过直接使用目标机器的本机代码来提高性能

- 在编译阶段应用强大的优化

解释语言的优点包括:

- 更容易实现(编写好的编译器非常困难!)

- 无需运行编译阶段:可以直接“即时”执行代码

- 对于动态语言来说更方便

现代技术(如字节码编译)增加了一些额外的复杂性-编译器将目标指向一个“虚拟机”,这与底层硬件不同。这些虚拟机指令可以在后续阶段再次编译为本机代码(例如,Java JVM的JIT编译器)。

并非所有的编译语言都需要一个缓慢的编译阶段。严肃的Common Lisp实现是编译器,它们通常不使用解释器,而是更喜欢即时编译。

解释器在动态语言中更容易实现是因为解释器执行以下操作:

1. 接收非本机代码。

2. 调用相应的函数,该函数会调用适当的本机函数。

而JIT编译执行以下操作:

1. 接收非本机代码。

2. 将其编译为中间语言,该中间语言可能会以某种方式转换为本机机器代码并执行。

JIT编译相对解释器的优势在于,JIT编译器只需要执行1)和2)一次,之后就完全是本机代码。解释器需要每次调用代码时都执行1)和2)(可能是多次)。因此,随着时间的推移,JIT编译器的性能更好。

字节码在整个程序执行过程中的某个时刻被翻译成机器代码(而不是在程序执行之前,就像传统的编译器那样)。但是,在整个程序执行过程中,给定的代码可能会执行1000万次以上。它(可能)只会从字节码编译一次到机器代码。因此,JIT的运行时开销很小,可以忽略不计。在JIT编译器完成工作后,您将完全运行纯机器代码。

这实际上是一个错误的二分法。没有任何一个语言的本质使其成为编译语言或解释语言。这只是一个被广泛持有的误解。许多语言都有两种实现方式,所有语言都可以具有任何一种。

这不是错误的二分法。编程语言包括设计和实现。尽管在理论上,给定的语言定义可以同时被编译和解释,但在现实世界的实践中,实现上存在着相当大的差异。例如,至今尚无人解决如何有效编译某些语言结构的问题,这是一个开放的研究问题。

确实是如此。编译有其优势,解释也有其优势。只因为编译器技术正在发展以改进某些语言特性,并不意味着我们可以对使用编译还是解释进行任何有关该特性的选择的优点进行任何说明。将语言和实现混为一谈会导致对选择编译或解释实现产生错误的理解。例如,你的评论“[解释器] 对于动态语言来说更方便”。

将基本语法检查添加到编译器的列表中。

所以,解释语言中机器和您编写的代码之间有一层间接层,而编译语言则没有。

“应用相当强大的优化”是什么意思?这是否意味着相同的源文件可以根据编译方式产生不同的目标文件?即,特定源文件中的语句和生成的编译的机器指令之间不一定是一对一的关系,而是一对多的关系?

解释器本身是编译的。对吗?因为最终需要机器代码。对吗?

0