为什么整个计划优化现在不再普遍？

Question

主要问题：为什么一般甚至专业的整体计划优化者都不是我们日常生活的一部分？

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

Partial Evaluation可能是一种更窄的整个程序优化类型，其中程序的源是基于一些固定的输入集减少/评估的，同时保持未知输入在运行时被评估。例如，如果给定y = 5，则一般函数x ^ y可以简化为x ^ 5或者可能是（x * x）*（x * x）* x。

（我为这两种技术的粗略描述道歉）

历史上整个程序优化（例如上面两个）的内存密集程度太大而无法执行，但是由于我们的机器有内存（或使用类似云），为什么我们没有看到很多开源部分评估器和像春天一样？我见过一些，但我认为这将成为我们工具链的常规部分。

• 是否担心（程序员担心他们的代码转换会引入错误）？
• 这是不值得的 （即对于网络应用而言，瓶颈是 I / O，以及这种优化 似乎节省了CPU时间）？
• 这是 那种困难的软件 写？
• 或者，是我的看法 这错了吗？

Answer 1

我认为这主要是因为你的看法是错误的。大多数编译器支持“整个程序”（过程间）优化和配置文件引导优化，以根据实际使用情况指导优化器。

大多数人没有注意到的主要原因是，最终，这些很少有足够的差异才能真正注意到很多。这些工具的普遍可用性也发生在他们对大多数目的而言并不重要的时候。现在CPU速度如此之快，以至于没有人会想到在java虚拟机上运行代码，这个虚拟机本身就像在VMWare虚拟机中运行一样（尤其是特别 第三个​​虚拟机层）。

这增加了 dwarfs 通常可以从全局优化中获得的改进的开销。对于大多数人来说，速度差异必须相当大到完全重要（全局优化的改进很少有资格）。

Answer 2

我的猜测是鸡蛋问题，让我解释一下。

使用超级编译（SC），程序员可以编写更抽象的代码而无需支付运行时成本（对于发布版本，为每个调试版本执行它可能是不切实际的）。

因此，如果（今天）没有SC可用，程序员会编写“低级”代码，因此没有人编写更好的代码，需要SC来完成繁重的工作。

在现实世界中唯一可能阻止SC的是整个程序超级编译需要（非常）高水平的智能。 OpenCog或任何其他AGI-ish AI可能对解决最后一个问题有很大帮助。如果只有小部件应该是SC（如单一方法），则不是这种情况。

SC今天不常见的另一个原因是它相对较新（与较旧的编译技术相比），SC是在70年代开发的，编译成本是非线性的，所以它不是大的目标编译器供应商。

使用更抽象的代码我的意思是

• 能够编写与数据类型无关的代码，因此它最终会使模板/泛型过时（大部分时间）
• 程序员可以在任何时候调用任何类型的解释器，SC应该在大多数情况下能够完全优化它，因此最终结果看起来像是程序员想到的代码的手工版本。无需手动“展开”和更高的生产力（因为程序员不需要修改“低级别”代码，他可以在更高的层次上工作

Answer 3

感谢您提出我认为深刻的问题，并且 请原谅我的火焰......

部分评估是一个美丽的概念，其美貌已经完全失去了看似无穷无尽的渴望，即建立聪明但无脑的工具，将事情从程序员手中夺走。 这就是为什么它没有做太多的事情。

每当你编写一个编写程序B的程序A（这是一个基本技能，每个程序员（在我看来）应该知道如何使用，当使用时）你正在做部分评价。 由于一些输入数据是早期知道的并且不经常改变，因此程序不需要一直测试它是什么。 您可以获取几乎没有变化的信息并将其作为输入传递给A，并打印出程序B，只需简单地知道＆＃34;静态输入，所以它所要做的就是处理不可预测的动态输入。

但是，只要有人试图编写工具来进行部分评估，他们就会把程序员的大脑从循环中解放出来，这就是杀死它的原因。

一般来说优化也是如此。 当程序员将他/她的判断交给一个工具时，结果很少，因为没有工具（至少）能够像程序员那样理解代码。

尝试制作能够理解代码和程序员的工具当然是值得的，但假设已经已经完成，这是愚蠢的。< / p>