CPython 3.13 已经在两周前发布了,该版本是一段时间以来最注重性能的版本。我在快速阅读发行说明后,了解以下几点对性能的影响显而易见:
CPython 现在可以在自由线程模式下运行,并禁用全局解释器锁 (GIL)
添加了全新的即时(JIT) 编译器
CPython 现在捆绑了mimalloc开箱即用的分配器
在本文中,我们将重点关注自由线程模式,了解如何利用这一变化以及它如何通过使用 CodSpeed 测量性能来影响 Python 应用程序的性能。
自由线程的 CPython
自由线程是 Python 3.13 中的一项实验性功能,允许 CPython 在没有全局解释器锁 (GIL) 的情况下运行。
GIL 是一个互斥锁,可防止多个线程同时执行 Python 字节码。这种设计选择简化了 CPython 的内存管理,并使 C API 更易于使用。然而,它也是有效利用现代多核处理器的最大障碍之一。
multiprocessing 解决方法
传统的解决方案是使用multiprocessing模块,它会生成单独的 Python 进程而不是线程,虽然这种方法有效,但它有很大的局限性:
内存开销:每个进程都需要自己的 Python 解释器实例和内存空间。对于数据密集型应用程序,这很快就会成为瓶颈。
通信成本:进程之间不能直接共享内存。数据在进程间传递时必须进行序列化和反序列化,这增加了开销和复杂性。
启动时间:创建新进程的速度明显慢于创建线程,因此对于需要频繁生成工作进程的任务来说,它并不实用。
现实世界的影响:PageRank 示例
为了说明这些限制,让我们来实践一个功能叫 PageRank,这是 Google 早期搜索引擎所采用的算法。
PageRank 是一个非常理想的安全,因为它有如下的特性:
计算密集型(矩阵运算)
适用于大型数据集(网络图)
可以从并行化中获益匪浅
Python 3.12 或更早版本中的简单多线程实现在矩阵操作期间会因 GIL 而成为瓶颈,而多处理版本则会遇到以下问题:
将图复制到每个进程的内存开销
在流程之间转移部分结果的成本
管理共享状态的复杂性
在我们继续之前,需要澄清的是,我们的重点不是 PageRank 算法本身的细节,而是并行化,因此我们不会在这里讨论算法本身的细节。
让我们看看如何使用这些不同的并发模型来实现这一点。
教科书案例实现(单线程)
def pagerank_single(matrix: np.ndarray, num_iterations: int) -> np.ndarray:
"""Single-threaded PageRank implementation"""
size = matrix.shape[0]
# Initialize scores
scores = np.ones(size) / size
for _ in range(num_iterations):
new_scores = np.zeros(size)
for i in range(size):
# Get nodes that point to current node
incoming = np.where(matrix[:, i])[0]
for j in incoming:
# Add score contribution from incoming node
new_scores[i] += scores[j] / np.sum(matrix[j])
# Apply damping factor
scores = (1 - DAMPING) / size + DAMPING * new_scores
return scores
代码中突出显示的行,显示了算法中计算最密集的两个部分。第一部分计算来自传入节点的分数贡献,而第二部分应用阻尼因子,将新分数纳入最终结果。
对第一部分进行并行化将是最有益且最容易实现的,因为我们可以划分范围,从而有效地使用多个线程来计算数组new_scores。
多线程实现
对于多线程实现,我们首先将矩阵分成多个块:
chunk_size = size // num_threads
chunks = [(i, min(i + chunk_size, size)) for i in range(0, size, chunk_size)]
然后,每个线程将处理矩阵的不同块,更新new_scores数组:
def _thread_worker(
matrix: np.ndarray,
scores: np.ndarray,
new_scores: np.ndarray,
start_idx: int,
end_idx: int,
lock: threading.Lock,
:
size = matrix.shape[0]
local_scores = np.zeros(size)
for i in range(start_idx, end_idx):
incoming = np.where(matrix[:, i])[0]
for j in incoming:
+= scores[j] / np.sum(matrix[j])
with lock:
new_scores += local_scores
需要注意的是,数组的更新new_scores是在锁定后进行的,以防止出现竞争条件。如果锁定时间过长,这可能会成为瓶颈,但实际上,并行化算法的第一部分应该已经可以显著提高速度。
最后,我们将把这些代码块提供给每个线程:
new_scores = np.zeros(size)
lock = threading.Lock()
with concurrent.futures.ThreadPoolExecutor(max_workers=num_threads) as executor:
# Process chunks in parallel
futures = executor.map(
lambda args: _thread_worker(*args), # starmap isn't available on ThreadPoolExecutor
[
(matrix, scores, new_scores, start_idx, end_idx, lock)
for start_idx, end_idx in chunks
],
)
new_scores = (1 - DAMPING) / size + DAMPING * new_scores
scores = new_scores
多处理实现
本质上,multiprocessing实现方式与这个 threading进程处理极其相似,让我们关注一下不同之处:
由于进程无法直接共享内存,因此每个工作进程现在将返回local_scores数组,而不是更新共享new_scores数组。
然后,本地分数将在主进程中汇总:
# Combine results
new_scores = sum(chunk_results)
虽然这应该比线程版本更快,但它仍然会产生进程间通信的开销,这对于大型数据集来说可能非常显著。
它不使用ThreadPoolExecutor,而是使用multiprocessing.Pool。两个API 非常相似,但multiprocessing.Pool会生成进程池而不是线程池:
with multiprocessing.Pool(processes=num_processes) as pool:
# Process chunks in parallel
chunk_results = pool.starmap(_process_chunk, chunks)
# Combine results
new_scores = sum(chunk_results)
new_scores = (1 - DAMPING) / size + DAMPING * new_scores
scores = new_scores
衡量绩效
为了测量实际的性能变化,让我们构建一个性能测试。首先需要生成一些测试数据:
def create_test_graph(size: int) -> np.ndarray:
# Fixed seed
np.random.seed(0)
# Create random adjacency matrix with ~5 outgoing edges per node
matrix = np.random.choice([0, 1], size=(size, size), p=[1 - 5/size, 5/size])
# Find nodes with no outgoing edges
zero_outdegree = ~matrix.any(axis=1)
zero_indices = np.where(zero_outdegree)[0]
# For each node with no outgoing edges, add a random edge
if len(zero_indices) > 0:
random_targets = np.random.randint(0, size, size=len(zero_indices))
matrix[zero_indices, random_targets] = 1
return matrix
正如所强调的,我们使用固定种子来确保从一次运行到下一次运行的可重复性。
这个在比较不同实现的性能时很重要。在这里,我们在页面之间建立一些假连接来构建真实的图形,但只要大小相同,数学运算与空矩阵完全相同。
接下来,我们将使用 pytest-codspeed插件pytest 来测量具有各种参数和多个 CPython 构建/版本的不同实现的性能。
首先,让我们定义基准案例:
@pytest.mark.parametrize(
"pagerank",
[
pagerank_single,
partial(pagerank_multiprocess, num_processes=8),
partial(pagerank_multithread, num_threads=8),
],
ids=["single", "8-processes", "8-threads"],
)
@pytest.mark.parametrize(
"graph",
[
create_test_graph(100),
create_test_graph(1000),
create_test_graph(2000),
],
ids=["XS", "L", "XL"],
)
def test_pagerank(
benchmark: BenchmarkFixture,
pagerank: PagerankFunc,
graph: np.ndarray,
):
benchmark(pagerank, graph, num_iterations=10)
这里我们测试了 3 种具有 3 种不同图形大小的实现。该 benchmark装置由提供,pytest-codspeed并将测量具有pagerank给定参数的函数的执行时间。
然后,让我们编写一个 GitHub Actions 工作流程来测量 CodSpeed 基础架构上各种 CPython 版本的性能:
on:
push:
jobs:
codspeed:
runs-on: codspeed-macro # requests a CodSpeed Macro runner for the jobs
strategy:
matrix:
python-version: ["3.12", "3.13"]
include:
- { python-version: "3.13t", gil: "1" }
- { python-version: "3.13t", gil: "0" }
env:
UV_PYTHON: ${{ matrix.python-version }}
steps:
- uses: actions/checkout@v4
- name: Install uv
uses: astral-sh/setup-uv@v3
- name: Install CPython & dependencies
run: uv sync --all-extras
- name: Run benchmarks
uses: CodSpeedHQ/action@v3
env:
PYTHON_GIL: ${{ matrix.gil }}
with:
run: uv run pytest --codspeed --codspeed-max-time 10 -vs src/tests.py
这里我们使用 Python 3.12、3.13 和支持自由线程 ( 3.13t) 的 3.13 版本运行基准测试,有 GIL 和无 GIL 版本均有。运行支持和不支持自由线程的 3.13 版本将使我们能够看到其对性能的影响,即使启用了 GIL 也是如此。
uv使用的 Python 版本直接从 python-build-standalone中提取, 使用GCC 6.3.0 20170516。
这些作业将在 CodSpeed Macro运行器上运行,它们是专用于每个作业的 ARM64 裸机实例,具有 16 个内核和 32GB 内存。
结果请见下图:
L 图大小的时间(以秒为单位),越少越好
如果不启用新的构建选项,3.12和 3.13的性能非常相似。我们还清楚地看到,multiprocessing由于进程间通信的开销,实现速度甚至比单线程实现还要慢。
正如预期的那样,在运行没有 GIL 的 3.13tthreading时,基于的实现是最快的 ,并且 GIL 实际上不再限制线程的并行执行。
不过,在使用自由线程构建( 无论是否使用GIL)运行时,我们都会发现其他所有实现的速度都显著降低。这主要是因为自由线程构建需要禁用专门的自适应解释器,从而明显降低了其他实现的性能。在 3.14 版本中,这种开销应该会减少,因为专门的自适应解释器将是线程安全的,因此将重新启用。到那时,对于许多并行应用程序来说,迁移到自由线程构建应该是一件轻而易举的事,衡量性能变化将会很有趣。
对于所有其他图大小,结果非常相似,结论也相同。从这个测量结果中,我们可以看到 CPython 3.13 的新自由线程版本可以对并行应用程序的性能产生重大影响,为 带来了非常相关的替代方案multiprocessing。由于它引入了整体减速,因此它仍然是实验性的,尚未准备好用于生产,但这是朝着正确方向迈出的非常有希望的一步!
后记
该基准测试不包括子解释器,这是另一种无需使用 Python 3.12 中引入的 GIL 即可并行运行 Python 代码的方法。
事实证明,在大多数情况下,子解释器比其他方法慢,主要是因为数据共享和工作器间通信尚未完全解决。但是一旦有了子解释器,它绝对可能是一个不错的替代方案multiprocessing。
⏭️ JIT 和mimalloc性能将在下一篇文章中介绍。敬请大家期待!
作者:Alex 原文: https://codspeed.io/blog/state-of-python-3-13-performance-free-threading
本文为 @ 万能的大雄 创作并授权 21CTO 发布,未经许可,请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人,21CTO 平台仅提供信息存储空间服务。