language-agnostic - 为什么整个程序优化现在不流行了？

Question

主要问题:为什么通用的甚至专门的整个程序优化器不是我们日常生活的一部分？

我在阅读 SuperCompilers, LLC 的 White paper 后开始思考这个问题。 ，讨论了他们的“ super 编译”方法或 metacompiling程序的源代码(通常)实现与原始程序具有相同功能的更快版本。本质上，它们逐步执行程序并重新编译为相同的目标语言。通过这样做，自然优化发生;例如，如果输入程序经常使用 100 个项目的数组，则一般的二分搜索函数可能专门用于对 100 个项目的数组进行二分搜索。

Partial Evaluation可能是一种更窄的整个程序优化类型，其中程序的源根据一些固定的输入集减少/评估，同时在运行时打开未知输入进行评估。例如，通用函数 x ^ y，如果给定 y = 5，可以简化为 x ^ 5 或类似 (x * x) * (x * x) * x 的函数。

(对于我对这两种技术的粗略描述，我深表歉意)

从历史上看，像上面两个这样的整个程序优化会占用大量内存而无法执行，但是由于我们的机器有大量内存(或使用云之类的东西)，为什么我们没有看到很多开源部分评估器之类的 spring向上？我见过一些，但我认为这将是我们工具链的常规部分。

是恐惧(程序员担心他们的代码转换会引入错误)吗？

难道只是不值得
(即对于网络应用程序，瓶颈是
I/O，以及这种优化
似乎在节省 CPU 时间)？

这是
那种软件就那么难
来写？

或者，是我对
这只是错了吗？

Answer 1

我认为主要是你的看法是错误的。大多数编译器都支持“整个程序”(过程间)优化，以及基于实际使用的配置文件引导优化来指导优化器。

大多数人没有注意到的主要原因是，最终，这些很少有足够的差异来真正注意到人们非常关心。此类工具的普遍可用性也发生在它们对大多数目的并不重要的时候。 CPU 现在如此之快，以至于没有人会三思而后行在 Java 虚拟机上运行代码，Java 虚拟机本身运行在类似 VMWare 虚拟机的内部(并且拥有第三个虚拟机层甚至不会特别罕见)。

这增加了开销，使您通常可以从全局优化中获得的改进相形见绌。对于大多数人来说，速度差异必须非常大才能不再重要(并且全局优化的改进很少符合条件)。