pypy - 为什么 PyPy 翻译这么慢？

Question

将 pypy 实现转换为 c 文件并在配备 2G 内存和 Intel Core2 2GHz CPU 的现代笔记本上构建 pypy-c 需要花费数小时。

我知道这是一个 CPU 密集型任务，但它必须这么慢吗？有没有机会减少计算，重新排列计算顺序，把时间缩短到几十分钟？

Answer 1

免责声明：我不是 PyPy 方面的专家 - 特别是，我不了解 RPython 翻译的细节，我只是引用文档以及在邮件列表和博客中无意中听到的内容。

“CPU密集型任务”？被提名为当月的轻描淡写。我自己不太了解翻译过程的细节，但即使我可以告诉你，它的几个分析和优化过程中的每一个都对大量代码进行了大量非常复杂的工作。

1. 它开始正常运行 Python 代码，例如导入模块、执行模块级变量定义、定义函数和类、对其应用装饰器等。在某些时候，当应该实现“足够的静态性”时，它会停止并继续实际翻译过程。
2. 它采用冻结的内存中正在进行的 Python 程序，并将其全部运行在一个特殊的对象空间中，该对象空间模拟流控制、变量的可能值等。它本质上是象征性地运行解释器！它这样做是为了执行类型推断（在 Python 这样的语言中，一切都很简单）和额外的分析。
3. 结果被转换为低级代码。
4. 可选地，许多优化（默认启用，我猜）和无堆栈支持的复杂转换（默认禁用，我猜）跟随。
5. 然后它将所有这些东西降低到适合指定后端的类型系统中，生成数百万行代码（从最近的邮件列表条目看来，至少有 19 个 .c 文件，其中至少一个包含至少 247,560线 - 只是为了让您了解我们正在谈论的数量级）。
6. 所有这些代码都是用gcc -O2或类似的方式编译的，这当然有很多解析和检查要做，而且它本身也有很多分析和优化通道要做。

所以，是的，这是一项非常艰巨的艰巨任务。难怪你那微不足道的 CPU 它丢了。作为参考，PyPy人员在 2010 年 11 月对翻译过程进行基准测试时使用了 Intel Xeon W3580 (3.33 GHz) 。他们仍然花了大约 76 分钟，即使他们也有 12 GB 的 RAM - 这导致了下一个问题：这个过程中需要大量的 RAM（当时 64 位 Ubuntu 上的 2.3 GB，不知道如何数字转化为您的情况）。我很确定你最终会超出你的物理 RAM - 输入过多的交换和相关的踢到性能的腹股沟。

再加上你可能有几个其他程序正在运行窃取 CPU 时间和 RAM 的事实，在我看来，这很好地解释了你的经历。翻译 PyPy 是为功能更强大的计算机保留的。如果有什么东西可以从根本上改善这些时代，像我们这样的外人不太可能找到它。我会把这些担心留给开发人员。