Language agnostic 为什么不'；整个程序优化现在是否更普遍？

主要问题：为什么通用的甚至专门的整个程序优化器没有成为我们日常生活的一部分

在阅读SuperCompilers，LLC的文章后，我开始思考这个问题，该文章讨论了他们的“超级编译”方法或程序源代码，以（通常）实现与原始程序具有相同功能的更快版本。从本质上讲，它们逐步完成程序的执行并重新编译到相同的目标语言。通过这样做，自然优化发生；例如，如果输入程序经常使用100项数组，则通用二进制搜索函数可能专用于对100项数组进行二进制搜索

是一种可能更为狭隘的全程序优化类型，其中程序的源代码根据某个固定的输入集进行缩减/评估，同时保留未知输入，以便在运行时进行评估。例如，一般函数x^y，如果给定y=5，可以简化为x^5，或者类似于（x*x）*（x*x）*x的东西

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

从历史上看，像上面两个这样的整个程序优化都是内存密集型的，无法执行，但是由于我们的机器有Gig内存（或者使用类似于云的东西），为什么我们没有看到大量开源部分求值器之类的涌现呢？我见过一些，但我认为这将是我们工具链的一个常规部分

• 是害怕吗（程序员害怕他们的代码转换引入bug）
• 这不值得吗 （即，对于web应用而言，瓶颈是 I/O和这种优化 似乎节省了CPU时间）
• 这是吗 那种软件就是那么难 写作
• 或者，是我对 这是错的吗

---

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

---

大多数人没有注意到的主要原因是，最终，这些很少产生足够的差异，以至于没有真正注意到他们所关心的。这类工具的普遍可用性也发生在它们对大多数目的都无关紧要的时候。CPU现在速度如此之快，以至于没有人会再三考虑让代码在java虚拟机上运行，而java虚拟机本身运行在类似VMWare虚拟机的内部（而且拥有第三个虚拟机层也不是特别罕见）

---

这增加了开销，使您通常期望从全局优化中获得的改进相形见绌。对大多数人来说，速度差异必须相当大才能再起作用（而全局优化的改进很少有资格）。
我猜这是一个鸡蛋问题，让我解释一下
使用超级编译（SC），程序员可以编写更多的抽象代码，而无需支付运行时成本（对于发布版本，在每个调试版本中都这样做可能是不切实际的）
因此，如果（今天）没有SC，程序员会编写“低级”代码，因此没有人编写更好的代码，需要SC来完成繁重的工作
在现实世界中，唯一可能阻止SC的是整个程序超级编译需要（非常）高水平的智能。OpenCog或任何其他AGI-ish AI可能对解决最后一个问题有很大帮助。如果只对小零件进行分类（如单一方法），则情况并非如此
另一个原因是，SC在今天并不常见，因为它相对较新（与更老的编译技术相比），SC是在70年代开发的，编译成本是非线性的，因此它不是大型编译器供应商的目标
我的意思是用更抽象的代码
• 能够编写与数据类型无关的代码，因此最终会使模板/泛型过时（大部分情况下）
• 程序员可以在任何时候调用任何类型的解释器，在大多数情况下，SC应该能够完全优化它，因此最终结果看起来像是程序员心目中的手工版本的代码。无需手动“展开”和更高的生产率（因为程序员不需要修改“低级”代码，他可以在更高的级别上工作）

---

谢谢你问我一个很深的问题， 请原谅我的火焰
部分评估是一个美丽的概念，它的美丽已经完全消失在似乎无穷无尽的渴望中，即构建智能但无脑的工具，以从程序员的手中/头脑中解放出来。 这就是为什么它做的不多
每当你编写一个程序a，而它又编写了一个程序B（在我看来，这是每个程序员都应该知道如何使用和何时使用的一项基本技能），你都在进行部分评估。 由于一些输入数据是早期已知的，并且不会经常更改，因此程序不需要一直测试它是什么。 您可以获取几乎从不改变的信息并将其作为输入传递给A，然后让A打印出程序B，该程序B只“知道”静态输入，因此它所要做的就是处理不可预测的动态输入
但一旦有人试图编写一个工具来进行部分评估，他们就把程序员的大脑从循环中带出来了，这就是它的致命之处
一般来说，优化也是如此。 当程序员将自己的判断交给一个工具时，结果很小，因为没有工具（至少是现在）能够像程序员那样理解代码
尝试使工具能够像程序员一样理解代码当然是值得的，但假设已经做到了这一点是愚蠢的。
强大的优化器无处不在。不仅主线编译器上的静态优化器可以进行大量AST重写，JIT编译器上的优化器也可以进行大量AST重写