前几天，我看到一条病毒式传播的推文，称谈论大型语言模型（LLMs）导致代码缓慢、臃肿的人，一旦重写所有内容为超优化的汇编语言，将会自食其果。我们还没有到需要用汇编语言编写所有代码的地步，但诺兰·劳森关于测试的说法有一些变体，你现在可以选择想要多少个错误，而我在这里表达得不够优雅的观点，对于性能来说变得越来越真实。对此，我在上一篇文章中的评论提到，曾经专门的性能工作成本下降了多个数量级，过去需要一组罕见技能的人或团队才能完成的性能工作，现在可以由任何人完成，只需输入几句话，这意味着你可以进行各种优化，这些优化在过去除非是最大规模或最有利可图的项目，否则是太昂贵而不值得的。马尔克·布鲁克尔对此回应说：完全同意你的总结观点。动态定制软件，针对特定工作负载而非一类工作负载进行调整，似乎是一种非常可能的结果。（这带来了各种有趣的风险和机会）。这让我想起了 FFTW 和大量奇怪的旧演示场景技术，这些技术都是围绕在非常特定的问题（并且通常是非常特定的硬件）上，力求速度快和占用空间小。例如，我记得有一个演示代码将其代码重用为纹理，以获得良好的缓存局部性。迈克尔·马利斯提到，有一个谣言流传着说 AI 没有帮助，因为“代码从来不是困难的部分”。我认为在某些领域这是正确的，但在其他领域，编写代码绝对是困难的部分。即时编译器就是一个很好的例子。对于许多软件来说，即时编译器会大大加快代码执行速度。即时编译器稀缺让我相信，实现即时编译器在历史上是过于困难的，以至于不值得。大型语言模型降低了准入门槛，使编写即时编译器变得容易得多。这便是 pgrust 背后的论点。数据库历史上是构建最困难的软件部分，并因此受到限制。现在，借助 AI，我们可以对构建的软件类型有更大的雄心。在处理工作负载类别时让我们试试这个，使用我们在上一篇文章中构建的正则表达式引擎 FRE。回想一下，它是通过让一个代理循环改善正则表达式引擎性能，并访问 rebar 正则表达式基准套件，经过一个月的努力而创建的。结果是 FRE 与 rebar 过度拟合，直到我们警告我们的代理，我们有一个保留基准，这导致代理对优化进行了一定程度的推广，以至于在我们的保留基准上性能良好。没有特别的理由使用不在保留基准上击败经过充分测试的正则表达式引擎的“软件工厂”正则表达式引擎，但 FRE 的一个显著特点是原生 AOT 编译版本在较长搜索中表现良好。我们注意到，可以合理地推测，当 ripgrep 正在运行其常规匹配器时，可以在另一个线程中运行原生代码编译器，然后在编译完成后切换到原生代码，通常能获得更好的性能。当然，对于短查询，这通常会导致性能下降，因为我们失去一个用于编译的线程，但我更关心的是 ripgrep 在运行几秒或几分钟时的耗时，而不是几秒，所以我对此权衡表示认可。同样，我们可以在几分钟的人类时间内构建一个正则引擎，也可以在几分钟的人类时间内尝试这个实验。我输入了一些句子，代理进行了工作，使得这个实验得以实现（对人类而言，这将是相当大的一块代码修改），并在我的代码历史中来自实际 ripgrep 查询的基准上进行了测试。对于较长的查询，我们在几个非常简单的查询中看到了 2 倍到 4 倍的性能提升。但大多数查询更复杂，当我们在具有代表性的保留查询上运行时，对于应该启用 AOT 的查询，我们获得了大约 7% 的加速。这不是一个颠覆性的结果，但对花费几分钟时间输入到 codex 来说，也不是一个糟糕的结果（而且它仍在进行更多优化，预计将进一步加速）。构建索引？这也许是件愚蠢的事情，因为如果我们在计算机上反复搜索文本，加速这一过程的显而易见方法不是为正则匹配编写原生代码编译器，而是创建一个索引。但这里的重点是，这种技术工作，过去需要相当多的时间和专业知识，现在可以轻松完成。如果我们想要构建文本索引，正好我曾参与过 BitFunnel，这是一个专门用于快速文本摄取的必应搜索索引，并在 SIGIR 上获得最佳论文奖，所以如果我们要在整个机器上构建一个快速的本地索引，我可以考虑一些实验。