关于python:Python-312-目标还可以更快

42次阅读

共计 1658 个字符,预计需要花费 5 分钟才能阅读完成。

依照公布打算,Python 3.11.0 将于 2022 年 10 月 24 日公布。

据测试,3.11 相比于 3.10,将会有 10-60% 的性能晋升,这个成绩次要归功于“Faster CPython”我的项目,即“香农打算”。

对于“香农打算”的详情,可查看 Python 之父的主题分享,以及他的一则播客访谈。

3.11 版本为 Python 的提速开了一个激动人心的好头。接下来,3.12 还会有更多动作。

以下文章翻译自“香农打算”的《Python 3.12 Goals》,大家先一睹为快吧!

作者:Mark Shannon

译者:豌豆花下猫 @Python 猫

英文:https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goals

本文内容可能会改变,以理论版本为准!

本文是 Faster CPython 打算在 3.12 中实现的次要内容的概要。

跟踪优化器

Python 3.11 晋升速度的次要办法是用更快的与上下文相干的操作码(自适应的专门化操作码)替换个别的操作码,下一个大的改良办法是优化多个操作码的运行。

为此,现有的许多高级操作码将被替换成低级操作码,例如,用于查看版本号和援用计数的操作码。这些更简略的操作码更容易进行优化,例如,能够删除冗余的援用计数操作。

这些更底层的操作码还能让咱们失去一组适宜用于生成机器代码的指令(在 CPython 和第三方 JIT 我的项目中都实用)。

为了做到这点,解释器循环(interpreter loop)将基于申明性的形容而生成。

这可缩小一部分为了放弃解释器循环与某些相干函数同步而产生的 bug(mark_stacks、stack_effect 等函数),同时也让咱们能够对解释器循环作较大的更改试验。

多线程并行

Python 以后每个过程有一个全局解释器锁(GIL),妨碍了多线程的并行。

PEP-684:https://peps.python.org/pep-0684

PEP-554:https://peps.python.org/pep-0554

PEP-684 提出了一个计划,即保障所有的全局状态都是线程平安的,并挪动到每个子解释器的全局解释器锁中应用。

PEP-554 提出了让 Python 创立子解释器的计划(目前只是一个 C API 个性),从而实现真正的多线程并行。

Python 猫注:PEP-554 早在 2017 年就提出了,指标是落地在 Python 3.8-3.9 版本,然而大失所望。早在 2019 年的时候,我还翻译了一篇《Has the Python GIL been slain?》。屠刀已挥出,让它再飞一会~~

更多专门化

咱们剖析了哪些字节码将从专门化中获益最多,打算在 3.12 实现其余的高收益的改良。

https://github.com/faster-cpy…

较小的对象构造

有许多能够缩小 Python 对象构造大小的机会。因为它们被频繁应用,这不仅有利于总体的内存应用,还有利于缓存的一致性。咱们打算在 3.12 中实现最有心愿的一些想法。

这里有一些向后兼容性与性能之间的衡量问题,可能须要提出一个 PEP 来建设共识。

缩小内存治理的开销

咱们不仅会减小对象的大小,还会使它们的 layout 更加规定。

这不仅能优化内存的调配及开释,还能在 GC 和重新分配期间放慢遍历对象的速度。

API 稳定性

除了前述我的项目外,开发团队还将晋升 CPython 代码库的整体品质:

  • 通过缩小不同编译阶段的耦合,使编译器更易于保护与测试。
  • 踊跃地在 C 语言级别监控和改良 CPython 测试套的代码覆盖率。
  • 改良 Python 性能基准测试套,退出更具代表性的事实世界的负载测试。
  • 帮助解决 CPython 问题和 PR,特地是与性能无关的问题。
  • 减少用于规范基准测试的机器,减少 macOS 和 Windows 的测试后果。
  • 持续跟次要的深度应用 Python 内核的我的项目单干,帮忙它们适配 CPython 解释器的更改。

注:文中图片为译者所加。

首发于 Python 猫 ,如需转载,请分割作者

知乎:Python 猫

博客园:豌豆花下猫

掘金:豌豆花下猫

CSDN:Python 猫

正文完
 0