为什么 cython embedded plugins 在 cpython 解释器中比 rust-c 接口版本有更高的性能?

Why cython embeded plugins has higher performance in cpython interpreter than rust-c interface versions?

想请教一些关于python解释器底层原理的问题,因为我自己搜索的时候没有得到太多有用的信息。

我最近一直在使用 rust 编写 python 插件,这大大加快了 python 的 cpu 密集型任务,并且编写比较也更快到c。但是它有一个缺点就是,相对于老的用cython加速的方案,rust(我用的是pyo3)的调用开销好像比c(我用的是cython)要大,

例如,我们这里有一个空的 python 函数:

def empty_function():
    return 0

通过 for 循环在 Python 中调用它一百万次并计算时间,这样我们可以发现每次调用大约需要 70 纳秒(在我的电脑中)。

如果我们将它编译成一个 cython 插件,使用相同的源代码:

# test.pyx
cpdef unsigned int empty_function():
    return 0

执行时间将减少到 40 纳秒。这意味着我们可以使用 cython 进行一些细粒度的嵌入,我们可以期望它总是比原生执行得更快 python.

然而,当涉及到 Rust 时,(老实说,我现在更喜欢使用 rust 进行插件开发而不是 cython,因为不需要在语法上做一些奇怪的黑客攻击),调用时间将增加到 140 纳秒,几乎是原生 python 的两倍。源码如下:

use pyo3::prelude::*;
use pyo3::wrap_pyfunction;

#[pyfunction]
fn empty_function() -> usize {
    0
}

#[pymodule]
fn testlib(_py: Python, m: &PyModule) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(empty_function, m)?)?;
    Ok(())
}

这意味着 rust 不适合 python 的细粒度嵌入替换。如果有一个任务调用时间很少,每次调用时间都比较长,那么用rust就完美了。但是如果有一个task会在代码中被调用很多,那么似乎不适合rust,因为类型转换的开销会占用大部分加速时间。

我想知道这是否可以解决,更重要的是,我想知道这种差异的根本原因。 cpython 解释器在它们之间调用时是否存在某种差异,例如调用 c 插件时 cpython 和 pypy 之间的差异?我在哪里可以获得更多信息?谢谢

===

更新:

不好意思各位,没想到我的问题会这么模棱两可,毕竟三者的源码都给了,用timeit测试函数运行时间几乎是python中的惯例发展。

我的测试代码与注释中@Jmb 的代码几乎完全相同,有一些细微的差别,我使用 python setup.py build_ext --inplace 方式构建而不是裸 gcc,但这不应该造成任何影响区别。总之谢谢补充

正如评论中所建议的,这是一个自我回答。

由于评论区的讨论没有得出明确的结论,我去pyo3的repo提了一个issue,得到了pyo3的main maintainer的回复。

总之,结论是cpython调用pyo3和cython编译出来的插件没有本质区别。当前的速度差异来自于不同的优化深度。

这是问题的link: https://github.com/PyO3/pyo3/issues/1470

这里还值得注意的是,使用 python setup.py build_ext --inplace 编译 rust 扩展会在未优化模式下构建它们(python setup.py developpip install -e . 也是如此)。

以下是 :

输出的摘录
Finished dev [unoptimized + debuginfo] target(s) in 0.02s

要使用优化的二进制文件在“发布”模式下构建,请使用:

pip install .

pip install . --verbose你可以看到区别:

Finished release [optimized] target(s) in 1.02s

这会产生 巨大的 差异,在我的例子中,未优化的构建比优化的构建慢 9 倍。