是否有任何自我改进的编译器？答案

【问题标题】：Is there any self-improving compiler around?是否有任何自我改进的编译器？
【发布时间】：2011-03-15 03:19:38
【问题描述】：

我不知道有任何自我改进的编译器，但我又不是一个编译器专家。

是否有任何自我改进的编译器？

请注意，我说的是自我改进的编译器，而不是改进它所编译的代码的编译器。

任何指针表示赞赏！

旁注：如果您想知道我为什么要问，请查看this post。即使我同意大多数论点，我也不太确定以下几点：

我们有可以改进的计划他们的代码现在没有人工输入—— 它们被称为编译器。

...所以我的问题。

【问题讨论】：

自我提升在哪方面？编译器将如何自我改进？它是否自己添加了一种新语言，所以 gcc 决定要编译 Ruby，然后学习如何编译？是否通过添加新的优化级别来改进它编译 C 的方式？
自己编译的编译器怎么样？
@JamesBlack 在任何方面自我提升 :) - 我只是想了解是否有这样的事情
直到你能明确地说出你的意思是“不是一个真正的问题”。我的意思是，你认为编译器可以理解它自己的性能并决定如何处理它吗？
我的意思是任何自我提升的方面，包括你提到的那个，这对我来说听起来像是一个问题。这与我的想法无关，我只是想了解当前是否有任何级别的关于该主题的研究。

标签： language-agnostic compiler-construction artificial-intelligence self-modifying

【解决方案1】：

虽然编译器确实可以在没有人为干预的情况下改进代码，但是，“编译器是自我改进的”的说法是相当可疑的。编译器所做的这些“改进”仅仅是基于一组人类编写的规则（有人说是电子人吗？）。所以你的问题的答案是：没有。

顺便说一句，如果有类似自我改进编译器的东西，我们会知道……首先它会改进语言，然后是它自己的代码，最后，它会修改它的代码成为病毒，然后让所有开发人员都使用它...最后我们将拥有一种经典的计算机对抗人类的最后希望人类的东西...所以...不。

【讨论】：

啊——讽刺的是……你的帖子甚至被标记为“singularity”
“那么它就会变成一种病毒，让所有开发者都使用它”……那么 Java 呢？
啊！感谢 jrockway 的笑声。
我不了解你，但我的编译器会参加夜校学习水下编篮！
天网改进了它的编译器

【解决方案2】：

MilepostGCC 是一个机器学习编译器，它随着时间的推移而自我改进，因为它能够改变自己以随着时间变得“更好”。更简单的iterative compilation 方法几乎可以改进任何编译器。

【讨论】：

【解决方案3】：

25 年的编程经验，我从来没有听说过这样的事情（除非你说的是自动下载软件更新的编译器！）。

【讨论】：

【解决方案4】：

据我所知，尚未实际实施，但是是的，理论已经存在：

Goedel machines：自我参照的通用问题解决者进行可证明的最佳自我改进。

【讨论】：

所以答案是：不——那里没有这样的东西。理论上时间旅行是可能的，但我看不到未来的任何人:) - 除了所有的笑话，谢谢你的链接。您能想到的任何其他示例或 Goedel 机器是此类事物的唯一理论化示例吗？
据我所知，它们是最先进的，之前的工作是由 Schmidhuber 的学生 Marcus Hutter (hutter1.net) 完成的。但我需要明确一点：Goedel 机器并不是“理论化的”，因为有模糊的陈述表明它们是可能的；不，在 Schmidhuber 的工作中，有一个明确的计划来构建（程序）一个。剩下的是工程，这并不容易：特别是它需要一个运行它的硬件性能的公理模型。使用当前蹩脚的 CPU 是不切实际的确定性性能模型，我正在考虑让程序...
.. 监控自身（通过硬件性能计数器），逐步学习和完善公理概率性能模型。但这纯属猜测。
从链接页面 - “搜索者系统和有效地测试可计算证明技术（输出为证明的程序），直到找到可证明有用的、可计算的自重写。我们证明了这样的自重写是全局最优的——没有局部最大值！——因为代码首先必须证明继续寻找替代自重写的证明搜索是没有用的。”这通常需要运行多长时间？这听起来很像是一场与宇宙热寂的竞赛。特别是因为现有的编译器理论已经相当先进了。
否：时间在完成实际任务和寻找更好的解决方案之间平均分配。想象一个执行计划的机器人——如果有严格的时间限制，最坏的情况是它会完成执行效率较低的计划的任务。因此，如果有时间限制，则无论如何都会完成实际任务（当然，如果计划在该时间限制内都是可计算且可行的）。此外，如果一个人有一个好的起点，那么没有什么可以阻止从那里开始 - 可能重写会发现一个更好的版本，而不是（还）可以通过传统方式计算。

【解决方案5】：

根据定义，自我改进的编译器必须具有自我修改的代码。如果你环顾四周，你会发现人们这样做的例子（自我修改代码）。但是，这种情况很少见——尤其是在像编译器这样大而复杂的项目上。这并不常见，因为它非常难以（即几乎不可能）保证正确的功能。许多自认为很聪明的编码员（尤其是汇编编码员）有时会玩弄这个。真正聪明的人大多会走出这个阶段。 ;)

【讨论】：

【解决方案6】：

在某些情况下，C 编译器会在没有任何人工输入的情况下运行多次，每次都会得到一个“更好”的编译器。幸运的是（或者不幸的是，从另一个角度来看）这个过程在几个步骤之后就会停滞不前——进一步的迭代会生成与上一个完全相同的编译器可执行文件。

我们拥有所有的 GCC 源代码，但是这台机器上唯一可用的 C 编译器不是 GCC。唉，GCC 的一部分使用只能用 GCC 构建的“扩展”。幸运的是，这台机器确实有一个功能性的“make”可执行文件，以及一些随机的专有 C 编译器。人类进入包含 GCC 源代码的目录，并手动键入“make”。
make 实用程序找到 MAKEFILE，它指示它运行（专有）C 编译器来编译 GCC，并使用“-D”选项，以便 GCC 的所有使用“扩展”的部分都是ifdef'ed了。（这些代码可能是编译一些程序所必需的，但不是 GCC 的下一阶段。）。这会生成一个非常有限的精简二进制可执行文件，它几乎没有足够的功能来编译 GCC（编写 GCC 代码的人会小心避免使用这个精简二进制不支持的功能）。
make 实用程序使用适当的选项运行缩减的二进制可执行文件，以便编译 GCC 的所有部分，从而生成一个功能齐全（但相对较慢）的二进制可执行文件。
make 实用程序在 GCC 源代码上运行全功能二进制可执行文件，并打开所有优化选项，从而生成人们从现在开始使用的实际 GCC 可执行文件，并将其安装在适当的位置.
make 实用程序测试以确保一切正常：它从 GCC 源代码的标准位置运行 GCC 可执行文件，并打开所有优化选项。然后它将生成的二进制可执行文件与标准位置中的 GCC 可执行文件进行比较，并确认它们是相同的（可能除了不相关的时间戳）。

在人类键入“make”之后，整个过程会自动运行，每个阶段都会生成一个改进的编译器（直到它稳定并生成一个相同的编译器）。 http://gcc.gnu.org/wiki/Top-Level_Bootstrap 和 http://gcc.gnu.org/install/build.html 和 Compile GCC with Code Sourcery 有更多细节。

我见过其他编译器在此过程中有更多阶段——但它们都需要在每个或两个阶段之后进行一些人工输入。示例：Edmund Grimley Evans 2001 年的“从无到有引导一个简单的编译器” http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html 还有所有从事 GCC 的程序员所做的历史性工作，他们使用以前版本的 GCC 来编译和测试他们对可能改进的 GCC 版本的推测性想法。虽然我不会说这没有任何人工输入，但趋势似乎是编译器在每次人工击键时会做越来越多的“工作”。

【讨论】：

【解决方案7】：

我不确定它是否符合条件，但 Java HotSpot 编译器在运行时使用统计信息改进了代码。

但是在编译时呢？该编译器如何知道有什么不足，什么没有？善良的衡量标准是什么？

有plenty of examples 的人使用遗传技术将算法相互竞争以提出“更好”的解决方案。但这些通常是具有度量的易于理解的问题。

那么我们可以在编译时应用哪些指标？编译代码的最小大小、循环复杂度或其他什么？其中哪些在运行时有意义？

【讨论】：

首先：这不是自我改进吗？其次：如果有人认为那是人工智能的应用，那不是。它所做的只是检查性能瓶颈并尝试通过在其他方面做出妥协来改进这些瓶颈。
谢谢，我明白你的意思，但我说的是一个可以自我改进的编译器——而不是它编译的代码。

【解决方案8】：

嗯，有JIT（及时）技术。有人可能会争辩说，具有一些 JIT 优化的编译器可能会重新调整自身以使其编译的程序更高效???

【讨论】：

我说的是编译器本身对编译器源代码的改进