软件没有理由再慢了

前几天，我看到一条病毒推文，说人们在谈论法学硕士如何导致缓慢、臃肿的代码，一旦他们用超级优化的汇编语言重写所有内容，他们就会吃掉乌鸦。我们还没有完全达到要在汇编中编写所有内容的程度，但是诺兰·劳森（Nolan Lawson）关于测试所说的一些变体，你可以选择你现在想要多少个错误，我在这里不太雄辩地指出，对于性能来说正变得更加真实。我在上一篇文章中评论说，以前专门的性能工作的成本已经下降了许多数量级，而以前需要拥有一套罕见技能的个人或团队的性能工作可以由任何可以输入几句话的人来完成1，这意味着您可以进行各种优化，这些优化过去对于除了最大规模或最有利可图的项目之外的所有项目来说都过于昂贵，不值得，Marc Brooker 回应说完全同意您的结束点。适合特定工作负载而不是一类工作负载的动态定制软件似乎是一个很可能的结果。 （这本身就伴随着各种有趣的风险和机遇）。有点让我想起 FFTW 。还有大量奇怪的旧演示场景技术，这些技术都是为了在一个非常特殊的问题（通常是非常特殊的硬件）上实现超快和小型。例如，我记得一个演示将其代码重新用作纹理以获得良好的缓存局部性。迈克尔·马利斯 (Michael Malis) 指出，有一个流行语说人工智能无济于事，因为“代码从来都不是困难的部分”。我认为在某些领域确实如此，但在其他领域，编写代码绝对是困难的部分。 JIT 编译器就是一个很好的例子。对于许多软件来说，JIT 编译器对于加快代码速度有很大帮助。 JIT 编译器的稀有性使我相信，历史上实现 JIT 编译器太困难，不值得。法学硕士降低了进入门槛，使编写 JIT 编译器变得更加容易。这就是 prust 背后的论文。数据库历来是最难构建的软件，因此受到限制。现在，有了人工智能，我们可以对我们构建的软件类型更加雄心勃勃。针对一类工作负载进行优化 让我们使用 FRE 来尝试一下，FRE 是我们在上一篇文章中构建的正则表达式引擎。回想一下，它是通过使用代理循环一个月来创建的，用于通过访问 rebar 正则表达式基准套件来提高正则表达式引擎性能。这导致 FRE 严重过度适应 rebar，直到我们警告我们的代理我们有一个保留基准，这导致代理将优化概括得足够多，以至于在我们的保留上性能还可以。没有特别的理由使用“软件工厂”正则表达式引擎，因为它在保留基准测试中无法击败经过充分测试的正则表达式引擎，但 FRE 值得注意的一点是，本机 AOT 编译版本在较长的搜索中表现得相当好。我们注意到，按理说，当 ripgrep 运行其正常匹配器时，可以在另一个线程中运行本机代码编译器，然后在完成编译后切换到本机代码，通常会获得更好的性能。当然，这通常会导致短查询的性能变差，因为我们会丢失一个编译线程，但我更关心 ripgrep 在运行几秒或几分钟时所花费的时间，而不是运行几秒时的时间，所以我可以接受这种权衡。就像我们可以在几分钟的时间内构建一个正则表达式引擎一样，我们也可以在几分钟的时间内尝试这个实验。我输入了几句话，一个代理去做了工作，让这种情况发生（这对人类来说是相当大的代码手术），它对来自我的法典历史的实际 ripgrep 查询运行了基准测试。对于较长的查询，我们发现一些非常简单的查询的性能提高了 2 到 4 倍。但大多数查询都更加复杂，当我们在代表性保留查询上运行时，对于应启用 AOT 2 的查询，我们获得了大约 7% 的加速。这不是一个惊天动地的结果，但对于花几分钟在 Codex 上打字来说也不是一个糟糕的结果（而且它仍在做更多的优化，并且可能会进一步加快速度）。建立索引？这可以说是一件愚蠢的事情，因为如果我们在计算机上重复搜索文本，那么加快速度的明显方法不是编写用于正则表达式匹配的本机代码编译器，而是创建索引。但这里的重点是，这种过去需要大量时间和专业知识的技术工作现在可以轻松完成。如果我们想构建一个文本索引，恰好我在 BitFunnel 上工作，这是一个专门用于持续/快速文本摄取的 Bing 搜索索引，赢得了 SIGIR 的最佳论文奖，所以如果我们要为整个机器构建一个快速的本地索引，我可以想到一些实验来尝试（我见过的项目似乎