代码之家 › 专栏 › 技术社区 › Jon Smock

为什么现在整个程序优化不更流行?

optimization language-agnostic

Jon Smock · 技术社区 · 14 年前

我读了超级编译器有限责任公司的书后就开始思考这个问题 White paper ,其中讨论了他们的“超级编译”或 metacompiling

Partial Evaluation 是一种可能更为狭义的全程序优化类型,其中程序的源代码根据某个固定的输入集进行缩减/计算,而将未知的输入留在运行时进行计算。例如,一个一般函数x^y,如果给定y=5,可以简化为x^5,或者类似于(x*x)*(x*x)*x。

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

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

这不值得吗 (即,对于web应用程序来说,瓶颈是 I/O和这种优化似乎在节省CPU时间?
是这个吗软件就是这么难写什么?
或者,是我对

3 回复 | 直到 6 年前

Jerry Coffin 14 年前

大多数人没有注意到的主要原因是,最终,这些很少产生足够的差异,以至于人们真正关注的是这些问题。这类工具的普遍可用性也发生在这样一个时期,即它们对于大多数目的来说都无关紧要。CPU现在速度如此之快,以至于没有人会再三考虑让代码运行在java虚拟机上,而java虚拟机本身运行在类似VMWare虚拟机的内部(甚至不会是这样) 尤其难得有一个虚拟机层)。

矮人 相当地 大到根本不重要(全局优化的改进很少有资格)。

Mike Dunlavey 10 年前

请原谅我的火焰。。。

这就是为什么它做得不多。

每当你写一个程序a,它写一个程序B(这是一个基本的技能,每个程序员(在我看来)应该知道如何使用,和使用)您正在进行部分评估。由于一些输入数据是很早就知道的,并且不会经常更改,因此程序不需要一直测试它是什么。你可以把几乎从不改变的信息作为输入传递给A,然后让A打印出程序B,它只“知道”静态输入,所以它所要做的就是处理不可预知的动态输入。

但一旦有人想写一个工具

一般来说,优化也是如此。当程序员将自己的判断交给一个工具时,结果很少,因为没有工具(至少是这样)能够像程序员那样理解代码。

尝试使工具能够像程序员一样理解代码,但是假设它有已经完成了。

Quonux 10 年前

我猜这是个鸡蛋问题,让我解释一下。

使用超级编译(SC),程序员可以编写更多的抽象代码,而无需支付运行时成本(对于发布版本,对每个调试版本都这样做可能是不切实际的)。

因此,如果(今天)没有SC,程序员就编写“低级”代码,因此没有人编写更好的代码,需要SC来完成繁重的工作。

在现实世界中,唯一可能阻止SC的是对整个程序超级编译的(非常)高水平的智能需求。OpenCog或任何其他AGI-ish-AI可能对解决最后一个问题有很大帮助。如果只对小部分进行扫描(如单一方法),则情况并非如此。

另一个原因是,SC现在并不常见,因为它相对较新(与更老的编译技术相比),SC是在70年代开发的,编译成本是非线性的,所以它不是大型编译器供应商的目标。

更抽象的代码

程序员可以在任何时候调用任何类型的解释器,在大多数情况下,SC应该能够完全优化它,这样最终的结果看起来就像是程序员心目中的手工版本的代码。无需手动“展开”和更高的生产率(因为程序员不需要修改“低级”代码,他可以在更高的级别上工作)