制作邪恶的快速编译器的关键设计选择是什么？

Question

我想知道如何设计一个非常快速编译的编译器.

首先,让我对我的问题有一些明显的误解:

1. 我不是在谈论编译器生成的代码的速度.已有许多资源可用于学习如何优化生成的代码.我遇到的问题是有关快速编译编译器的信息.

2. 我也不讨论为什么C++编译器通常比Java编译器慢(例如).我感兴趣的是可以使用哪些技术来加速任何给定语言的编译器.

3. 我也不想听到像Microsoft的Incredibuild或Unix的distcc这样的分布式编译系统.这些系统不会为您提供更快的编译器,它们只会为您提供更多的编译器.这当然有用,但这不是我要问的问题.我想知道如何为单个CPU设计快速编译器.

4. ccache也不是我正在寻找的答案.这是一个允许您完全避免使用编译器的系统,但它不会使编译器更快.再说一次,这很有用; 再说一遍,那不是我要问的问题.

我希望我的问题现在非常明确.但也许一些历史会使它更加清晰.

C编译器过去非常慢.然后,在1986年,THINK Technologies推出了Lightspeed C for Macintosh,它几乎可以即时编译程序.光速C为这样超过了其他所有的C编译器,有几乎没有任何比较快的多.(也许Lightspeed C不是新一代闪电般快速编译器中的第一个,但它是我体验中的第一个.Turbo Pascal早于[1983],但我没有经验,所以我不知道如何它在速度方面进行了比较.)

从那时起,许多快速编译器已经可用.似乎有某种在1980年的编译器技术的飞跃,而这尤其是什么,我试图理解.突破是什么？

答案可能很简单:使用Lightspeed和Turbo等IDE,集成编辑器已经在RAM中有源代码.如果编译器对该数据进行操作,则会消除磁盘I/O,这是任何编译器中最慢的部分.如果源代码大小相对于内存大小较小,那么这可能是提高速度的一个非常重要的因素.(在那些日子里,RAM大小要小得多,但是典型的程序大小也是如此.)

是吗？还是涉及其他重要的创新？从那以后,编译器速度有了重大改进吗？

Answer 1

C++ 编译器比 Java 编译器慢，主要是因为它们（通常）生成优化的本机代码，而 Java 编译器生成不是那么优化的字节码，并将最终的优化和本机代码生成留给 JIT 编译器（在运行时执行） ）。由于严格的优化需要了解本机代码，因此字节码编译器可以做的事情是有限的。

现在，我无法评论 Lightspeed（因为我对此一无所知），但在 Lattice & Microsoft C（慢）与 Borland TurboC（快）的情况下，Borland 将所有文件保存在内存中并在那里编译它们（如果如果你的程序崩溃了，它可能会导致 IDE 崩溃，从而丢失未保存的源代码！）。Microsoft 的 IDE 总是将文件保存到磁盘，然后启动一个单独的程序来读取磁盘并编译它。

使用预编译器头文件还有助于加快 c/C++ 编译速度。

有助于加快编译速度的另一件事是设计允许单遍编译的语言。例如，Pascal 要求每个函数在使用之前必须先定义（而不仅仅是声明，如 C++）（这就是为什么 main 函数必须位于源文件的最后）