潜在项目列表


             
潜在项目列表¶

参与进来¶
我们很乐意讨论围绕 PyPy 生态系统的想法。如果您有兴趣玩 RPython 或 PyPy，或者有这里没有提到的新想法，请加入我们到 irc 频道 #pypy (irc.libera.chat)。如果您不确定，但仍然认为您可以为 PyPy 做出宝贵的贡献，请不要犹豫，联系我们 #pypy 或我们的邮件列表。以下是一些让您思考的想法

优化 PyPy 内存使用：有时 PyPy 消耗的内存比 CPython 多。两个例子：1) PyPy 似乎在导入大型 Python 模块时分配并保持更多字符串的活动状态。2) PyPy 的基本解释器大小（从控制台启动的冷 VM）比 CPython 的更大。此项目的常规步骤是：运行相同 Python 版本的 CPython 和 PyPy，并比较内存使用情况（使用 Massif 或其他工具）。如果 PyPy 消耗的内存多得多，则找到并解决问题。
VMProf + 内存分析器：vmprof 是一个统计内存分析器。我们希望用新功能扩展它并解决一些当前的限制。
VMProf 可视化：vmprof 显示统计配置文件的火焰图以及有关特定调用站点的更多信息。尝试使用不同的信息（例如内存，甚至由我们的 jit 编译器生成的信息）将非常有趣。
RPython 中的显式类型：PyPy 希望有更好的方法来指定 RPython 中的签名和类属性类型。有关此主题的更多信息，请参见本页面的下方。
用于 vmprof 的虚拟现实 (VR) 可视化：这是一个非常开放的主题，有很大的自由度来探索配置文件的数据可视化。此项目不需要 VR 硬件。大学可以提供此类硬件，或者在任何其他情况下，我们可能会借用 VR 硬件设置。


面向新手的简单任务¶

优化随机：https://github.com/pypy/pypy/issues/1901
实现套接字的 AF_XXX 数据包类型：https://github.com/pypy/pypy/issues/1942
帮助编写文档。一项任务是记录目前仅在 此站点 上列出的 rpython 配置选项，也在 RPython 文档站点上。


中等至大型任务¶
以下是针对对 PyPy 项目有浓厚兴趣的潜在贡献者的一些有趣项目。它们大多共享一些共同的模式——它们规模中等偏大，通常被定义为独立项目，并且没有被积极开发。对于您可能想参与的小型项目，请查看上面的内容，或者查看 问题跟踪器、在 irc.libera.chat 上的 #pypy 频道上提问，或写信到 邮件列表。之所以这样是因为小型项目往往变化很快。
这个列表主要是为了提供对潜在项目的概述。这个列表本身并不详尽，我们很高兴人们能提出自己的改进想法。无论如何，如果您想参与其中的一些项目，或者 PyPy 中的任何其他内容，请在 IRC 上提问或写信到 邮件列表。


RPython 中的显式类型¶
RPython 主要基于类型推断，但在许多情况下，显式指定类型是有用的。我们希望能够选择性地指定任何函数参数的精确类型。我们已经在这个领域有了解决方案，@rpython.rlib.objectmodel.enforceargs 和 @rpython.rlib.signature.signature，但它们不方便且有限。例如，它们不能轻松地表达类型“以整数为键，以 Foo 实例列表为值的字典”。
此外，我们希望能够指定实例属性的类型。与函数情况不同，这可能需要对注释器进行一些重构。


使 bytearray 类型更快¶
PyPy 的 bytearray 类型非常低效。研究对此进行可能的优化将是一个有趣的任务。（XXX 当前状态未知；请在 #pypy 上询问有关此方面的更新。）


实现写时复制列表切片¶
想法是使用一个特殊的列表对象实现，当执行 myslice = mylist[a:b] 时使用：新列表不会立即构建，而是在（如果）myslice 或 mylist 被修改时才构建。


NumPy 重启¶
我们的 cpyext C-API 兼容性层现在可以运行未修改的上游 NumPy。我们需要重构 NumPy 添加文档字符串 的方式。
我们也正在寻求帮助，了解如何劫持 NumPy 类型转换和 ufunc 调用，以允许 JIT 使用我们的内部 _numpypy 模块使它们更快。


改进 jitviewer¶
分析应用程序的性能总是很棘手。我们有各种工具，例如 jitviewer，可以帮助我们分析性能。
旧工具被部分重写并与 vmprof 结合。该服务托管在 vmprof.com 上。
以下显示了 jitviewer 的旧图像。PyPy JIT 生成的代码以分层方式显示


在底层，它显示了已编译循环的 Python 源代码
对于每行源代码，它显示了相应的 Python 字节码
对于每个操作码，它显示了相应的 jit 操作，这些操作是实际发送到后端进行编译的操作（例如，示例中的 i15 = i10 < 2000）。


jitviewer 是一个基于 django 和 angularjs 的 web 应用程序：如果你有很棒的 web 开发技能并且想帮助 PyPy，这是一个理想的入门任务，因为它不需要任何对内部机制的深入了解。前往 vmprof-python、vmprof-server 和 vmprof-integration 查找开放问题和文档。


将 RPython 转换为 Python3¶
世界在不断发展，我们也应该如此。这方面的工作已经开始在 rpython3 分支上进行，主要是为了能够使用 Python3 构建文档。一些已知需要仔细重构的内容

python3 中的单个字符是 int，而不是字节
我们在 make_win32_traits 中使用 str/unicode 来区分 Windows 不同操作模式。

可能还有更多。该分支目前无法通过 rpython 测试，因此需要进行一些工作来回滚一些更改并以正确的方式重新执行它们。


提高性能¶

使未内联的 Python 级调用更快
切换到 节点海洋 IR，或类似 Lua-Jit 的 IR，它在节点海洋方法上进行迭代
使用真正的寄存器分配
改进指令选择/调度
创建混合跟踪/方法 JIT


改进预热¶

解释器加速
在跟踪时优化
在运行之间缓存信息


翻译工具链¶
(XXX 这不太可能实现。)

增量或分布式翻译。
允许单独编译扩展模块。


各种 GC¶
PyPy 具有可插拔的垃圾收集策略。这意味着可以为特定目的编写各种垃圾收集器，甚至可以针对通用目的进行各种实验。例子

一个垃圾收集器，它可以更好地压缩移动设备的内存
一个并发垃圾收集器（很多工作）
一个收集器，它将对象标志保存在单独的内存页面中，以避免在多个 fork()ed 进程之间取消共享所有页面


STM（软件事务内存）¶
这是一个我们停止开发的实验。除了主要开发路径（其目标是制作一个包含 STM 的（相对较快）的 pypy 版本）之外，还有一些独立的主题可以在现有的、无 JIT 的 pypy-stm 版本上进行实验

我们在实际用例中遇到了什么类型的冲突？而且，有时，哪些数据结构更合适？例如，以哈希表实现的字典将在任何线程写入任何内容时在所有线程中遭受“stm 冲突”；但可能还有其他实现。也许可以在 Python 解释器级别实现替代策略（参见列表/字典策略，pypy/objspace/std/{list,dict}object.py）。
更一般地说，有一种想法是我们需要某种“调试器”之类的工具来“调试”不是错误，而是 stm 冲突的东西。这个工具对最终的 Python 程序员来说会是什么样子？像一个分析器？还是像一个在中止的事务上设置断点的调试器？它可能都是应用程序级别的，有一些钩子，例如用于事务冲突。
找到好的方法让库使用内部线程和原子操作，但不对用户公开线程。现在在 lib_pypy/transaction.py 中有一个粗略的草稿，但还有更好的方法。例如，我们可能可以有一个类似迭代器的概念，允许每个循环迭代并行运行。


引入新的基准测试¶
我们的基准测试 runner 已经过时了。我们应该与 CPython 网站 合并
此外，我们通常很乐意引入新的基准测试。请事先咨询我们，但总的来说，任何真实世界的 Python 代码并且尚未被表示的东西都是受欢迎的。我们至少需要一个可以不带参数运行的独立脚本。示例想法（基准测试需要从它们中获取！）

hg


与 C 交互¶
虽然我们可以让 cpyext 更快，但我们也希望探索其他想法。虽然 cffi 适用于中小型扩展，但 HPy 似乎是 Python C 扩展的未来方向。以下是一些想法：* 帮助 HPy 并将项目移植到它 * 扩展 Cython 以拥有一个 JIT 可以理解的后端 * 与 C 扩展作者合作以确保完全的 PyPy 支持（见下文）* 将 PyPy 兼容的包放到 PyPI 和 conda 中

使更多 Python 模块对 PyPy 友好¶
在过去几年中，PyPy 对 CPython 的 C-API 的实现 cpyext 投入了大量工作，使其达到了实用的兼容性水平，因此 CPython 的 C 扩展可以在 PyPy 上运行，无需进行重大重写。但是，仍然存在许多边缘情况和特殊情况，它会表现异常。
对于任何尚未宣传完全 PyPy 兼容性的流行扩展，仔细查看它以使其与 PyPy 完全兼容将非常有用。一般过程如下

在 PyPy 上运行扩展的测试并查看测试失败。
一些失败可以通过识别扩展依赖于 CPython 未记录或内部细节的情况来解决，并重写相关代码以遵循记录的最佳实践。根据扩展的开发过程，适当地打开问题并发送拉取请求。
其他失败可能突出显示 cpyext 和 CPython 之间的兼容性问题。请向我们报告并尝试解决它们。
运行基准测试，无论是扩展开发人员提供的还是您创建的。任何 PyPy 比 CPython 慢得多的情况都应视为错误并按上述方法解决。

或者，我们过去推荐的一种方法是使用更适合 PyPy 的技术（例如 cffi）重写 C 扩展。以下是一些需要完成的良好工作的部分列表
wxPython-cffi bitbucket 仓库的存档副本

状态：PyPy 开发人员的一个项目，旨在将 Phoenix sip 构建系统改编为 cffi
该项目是 2013 年 GSOC 的延续 https://waedt.blogspot.com/
待办事项：恢复存档，合并包装的最新版本并完成 sip 转换

pygame https://github.com/CTPUG/pygame_cffi

状态：上次发布是在 2017 年