为什么 PyPy 翻译这么慢?

发布于 2024-11-10 06:18:58 字数 158 浏览 0 评论 0原文

将 pypy 实现转换为 c 文件并在具有 2G mem 和 Intel Core2 2GHz CPU 的现代笔记本电脑上构建 pypy-c 需要几个小时。

我知道这是一个 CPU 密集型任务,但是有必要这么慢吗?有没有机会或者空间来减少计算量,重新安排计算顺序,把时间缩短到几十分钟?

It takes hours to translate pypy implementation to c files and build the pypy-c on a modern notebook, with 2G mem and an Intel Core2 2GHz CPU.

I know it's a cpu-intensive task, but does it have to be so slow? Is there any chance or room to reduce the computation, rearrange the computing order and cut the time to tens of minutes?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

多情出卖 2024-11-17 06:18:58

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

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

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

所以,是的,这是一项非常艰巨的任务。难怪你那微不足道的CPU会丢掉。作为参考,PyPy 人员在 2010 年 11 月对翻译流程进行基准测试。尽管他们也有 12 GB RAM,但仍然花费了大约 76 分钟 - 这导致了下一个问题:该过程需要大量 RAM(当时 64 位 Ubuntu 上需要 2.3 GB) ,不知道这些数字如何转化为您的情况)。我很确定你最终会超出你的物理内存 - 输入过多的交换和相关的性能影响。

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

Disclaimer: I'm not an expert on PyPy - in particular, I don't understand the details of the RPython translation, I'm only citing docs and what overheared at the mailing list and in the blog.

"A CPU-intensive task"? Nominated for the understatement of the month. I don't quite understand the details of the translation process myself, but even I can tell you that each of its several analysis and optimization passes does a whole lot of very complex work to a whole lot of code.

  1. It starts to run the Python code normally, e.g. importing modules, executing module-level variable definitions, defining functions and classes, applying decorators to them, etc. At some point, when "sufficent staticness" should be achieved, it stops and continues the actual translation process.
  2. It takes the frozen in-memory in-progress Python program and runs all of it in a special object space that simulates flow control, possible values of variables, etc. It's essentially running the interpreter symbolically! It does this to perform type inference (everything but easy in a language like Python) and additional analysis.
  3. The results are converted into low-level code.
  4. Optionally, lots of optimizations (enabled by default, I'd guess) and a complex transformation for stackless support (disabled by default, I'd guess) follow.
  5. Then it's lowering all that stuff into a type system that fits the designated backend, generates millions of lines of code (from a recent mailing list entry it seems that there are at least 19 .c files and at least one of it contains at least 247,560 lines - just so you have an idea of the order of magnitude we're talking about).
  6. All that code is compiled with gcc -O2 or similar, which of course has a lot of parsing and checking to do and will itself have many many analysis and optimization passes to do.

So yeah, it's a pretty freaking HUGE task. No wonder your puny CPU it lost. For reference, the PyPy guys used a Intel Xeon W3580 (3.33 GHz) when benchmarking the translation process in November 2010. It still took them about 76 minutes, even though they also had 12 GB of RAM - which leads to the next issue: A lot of RAM is needed in the process (2.3 GB on 64 bit Ubuntu back then, don't know how the numbers translate to your situation). I'm pretty sure you end up exceeding your physical RAM - enter excessive swapping and associated kick to performance's groin.

That, combined with the fact that you propably had several other programs running stealing CPU time and RAM, explains your experience pretty well in my opinion. Translating PyPy is reserved for more powerful computers. If there's something that can fundamentally improve these times, outsiders like us are unlikely to find it. I'd leave these worrys to the developers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文