Pyrex 是一种专门设计用来编写 Python 扩展模块的语言。根据 Pyrex Web 站点的介绍，“它被设计用来在友好易用的高级 Python 世界和凌乱的低级 C 世界之间搭建一个桥梁。”虽然几乎所有的 Python 代码都可以作为有效的 Pyrex 代码使用，但是您可以在 Pyrex 代码中添加可选的静态类型声明，从而使得这些声明过的对象以 C 语言的速度运行。
加速 Python
从某种意义上来说，Pyrex 只是不断发展的 Python 类语言系列的一个部分：Jython、IronPython、Prothon、Boo、Vyper（现在没人用了）、Stackless Python（以一种方式）或 Parrot runtime（以另外一种方式）。按照语言的术语来说，Pyrex 本质上是在 Python 中添加了类型声明。它的另外几个变化没有这么重要（不过对 for 循环的扩展很漂亮）。
然而，您真正希望使用 Pyrex 的原因是它编写的模块比纯 Python 运行得更快，可能会快很多。
实际上，Pyrex 会从 Pyrex 代码生成一个 C 程序。中间文件 module.c 依然可以用于手工处理。然而对于“普通的” Pyrex 用户来说，没有什么理由需要修改所生成的 C 模块。Pyrex 本身可以让您访问那些对速度至关重要的 C 级代码，而节省了编写内存分配、回收、指针运算、函数原型等的工作。Pyrex 还可以无缝地处理 Python 级对象的所有接口；通常它都是通过在必要的地方将变量声明为 PyObject 结构并使用 Python C-API 调用进行内存处理和类型转换而实现的。
对于大部分情况来说，Pyrex 不需要不断对简单数据类型变量进行装箱（box） 和 拆箱（unbox） 操作，因此速度比 Python 更快。例如，Python 中的 int 类型是一个具有很多方法的对象。它有一个继承树，自己有一个计算好的“方法解析顺序（mothod resolution order，MRO）”。它有分配和回收方法可以用于内存处理。它知道何时将自己转换为一个 long 类型，以及如何对其他类型的值进行数值运算。所有这些额外的功能都意味着在使用 int 对象进行处理时需要经过更多级的间接处理或条件检查。另外一方面，C 或 Pyrex 的 int 变量只是内存中各个位设置为 1 或 0 的一个区域。使用 C/Pyrex 的 int 类型进行处理不需要涉及 任何 间接操作或条件检查。一个 CPU “加”操作在硅芯片中就可以执行完了。
在仔细选择的情况中，Pyrex 模块的速度可以比 Python 版本的相同模块的运行速度快 40 到 50 倍。但是与使用 C 本身 编写的模块相比，Pyrex 版本的模块几乎都不会比 Python 版本的模块更长，代码更类似于 Python，而不是 C。
当然，当您开始谈论加速（类）Python 模块时，Pyrex 并不是惟一可用的工具。在 Python 开发者的选择中，也可以使用 Psyco。Psyco 可以保持代码非常简短；它是（x86）机器代码中的一个 JIT Python 代码编译器。与 Pyrex 不同，Psyco 并不会精确地限定变量的类型，而是根据数据 可能 是哪种类型的每种假设为每个 Python 代码块创建几种可能的机器代码。如果在一个给定的代码段中数据是是简单类型，例如 int，那么这段代码（如果是一个循环，这种情况就更为突出）就可以很快地运行。例如，x 在一个执行一百万次的循环中可以是 int 类型，但是在循环结束时可以依然是一个 float 类型的值。Psyco 可以使用与在 Pyrex 中显式指定的类型相同的类型来加速循环。
虽然 Pyrex 也并不难，但是 Psyco 更加简单易用。使用 Psyco 不过是在模块的末尾加上几行；实际上，如果加上正确的代码，那么即使在 Psyco 不可用时，模块也可以同样运行（只是速度较慢）。
清单 1. 只有在 Psyco 可用时才使用 Psyco
|
1
2
3
4
5
6
|
# Import Psyco if availabletry: import psyco psyco.full()except ImportError: pass |
要使用 Pyrex，需要对代码进行的修改会更多（但也不过是多一点而已），系统中还需要安装一个 C 编译器，并正确对生成 Pyrex 模块的系统进行配置。虽然您 可以 分发二进制的 Pyrex 模块，但是为了能使您的模块在其他地方也可以运行，Python 的版本、架构和终端用户需要的优化选项必须匹配。
速度初体验
我最近为 developerWorks 的文章 Beat spam using hashcash 创建了一个纯 Python 的 hashcash 实现，但是基本上来说，hashcash 是一种使用 SHA-1 提供 CPU 工作的技术。Python 有一个标准的模块 sha，这使得编写 hashcash 非常简单。
与我编写的 95% 的 Python 程序不同，hashcash 模块缓慢的速度让我心烦，至少有那么一点点心烦。按照设计，这个协议就是要吃光所有的 CPU 周期，因此运行效率非常关键。hashcash.c 的 ANSI C 二进制文件运行的速度是这个 hashcash.py 脚本的 10 倍。而且启用了 PPC/Altivec 的优化后的 hashcash.c 二进制文件的速度是普通的 ANSI C 版本的 4 倍（1Ghz 的 G4/Altivec 在处理 hashcash/SHA 操作时的速度相当于 3Ghz 的 Pentium4?/MMX；G5 的速度会更快）。因此在我的 TiPowerbook 上的测试显示，这个模块的速度比优化后的 C 版本速度慢 40 倍（不过在 x86 上的差距没有这么大）。
由于这个模块的运行速度很慢，可能 Pyrex 会是一个比较好的加速方法。至少我认为是如此。“Pyrex 化” hashcash.py 的第一件事情（当然是在安装 Pyrex 之后）是简单地将其拷贝为 hashcash_pyx.pyx，并试图这样处理：
|
1
|
$ pyrexc hashcash_pyx.pyx |
创建二进制模块
运行这个命令会生成一个 hashcash.c 文件（这会对源文件进行一些微小的改动）。不幸的是，调整 gcc 开关刚好适合我的平台需要点技巧，因此我决定采用推荐的捷径，让 distutils 为我做一些工作。标准的 Python 安装知道如何在模块安装过程中使用本地的 C 编译器，以及如何使用 distutils 来简化 Pyrex 模块的共享。我创建了一个 setup_hashcash.py 脚本，如下所示：
清单 2. setup_hashcash.py 脚本
|
1
2
3
4
5
6
7
8
9
10
|
from distutils.core import setupfrom distutils.extension import Extensionfrom Pyrex.Distutils import build_extsetup( name = "hashcash_pyx", ext_modules=[ Extension("hashcash_pyx", ["hashcash_pyx.pyx"], libraries = []) ], cmdclass = {'build_ext': build_ext}) |
运行下面的命令，完整地编译一个基于 C 的扩展模块 hashcash：
|
1
|
$ python2.3 prime_setup.py build_ext --inplace |
代码修改
我把从 hashcash.pyx 生成基于 C 的模块的工作有些简化了。实际上，我需要对源代码进行两处修改；通过查找 pyrexc 抱怨的位置来找到要修改的位置。在代码中，我使用了一个不支持的列表，将其放入一个普通的 for 循环。这非常简单。我还将增量赋值从 counter+=1 修改为 counter=counter+1。
就这么多了。这就是我的第一个 Pyrex 模块。
测试速度
为了可以简单地测试要开发的模块的速度提高情况，我编写了一个简单的测试程序来运行不同版本的模块：
清单 3. 测试程序 hashcash_test.py
|
1
2
3
4
5
6
7
8
|
#!/usr/bin/env python2.3import time, sys, optparsehashcash = __import__(sys.argv[1])start = time.time()print hashcash.mint('mertz@gnosis.cx', bits=20)timer = time.time()-startsys.stderr.write("%0.4f seconds (%d hashes per second)\n" % (timer, hashcash.tries[0]/timer)) |
令人兴奋的是，我决定来看一下只通过 Pyrex 编译可以怎样提高速度。注意在下面所有的例子中，真实的时间变化很大，都是随机的。我们要看的内容是“hashes per second”，它可以精确可靠地测量速度。因此比较一下纯粹的 Python 和 Pyrex：
清单 4. 纯 Python 和 “纯 Pyrex”的比较
|
1
2
3
4
5
|
$ ./hashcash_test.py hashcash1:20:041003:mertz@gnosis.cx::I+lyNUpV:167dca13.7879 seconds (106904 hashes per second)$ ./hashcash_test.py hashcash_pyx > /dev/null6.0695 seconds (89239 hashes per second) |
噢！使用 Pyrex 几乎慢了 20%。这并不是我期望的。现在应该来分析一下代码可能加速的地方了。下面这个简短的函数会试图消耗所有的时间：
清单 5. hashcash.py 中的函数
|
1
2
3
4
5
6
7
8
9
10
11
12
|
def _mint(challenge, bits): "Answer a 'generalized hashcash' challenge'" counter = 0 hex_digits = int(ceil(bits/4.)) zeros = '0'*hex_digits hash = sha while 1: digest = hash(challenge+hex(counter)[2:]).hexdigest() if digest[:hex_digits] == zeros: tries[0] = counter return hex(counter)[2:] counter += 1 |
我需要利用 Pyrex 变量声明的优点来进行加速。有些变量显然是整数，另外一些变量显然是字符串 —— 我们可以指定这些类型。在进行修改时，我将使用 Pyrex 的经过改进的 for 循环：
清单 6. 经过最低限度 Pyrex 改进的 mint 函数
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
cdef _mint(challenge, int bits): # Answer a 'generalized hashcash' challenge'" cdef int counter, hex_digits, i cdef char *digest hex_digits = int(ceil(bits/4.)) hash = sha for counter from 0 <= counter < sys.maxint: py_digest = hash(challenge+hex(counter)[2:]).hexdigest() digest = py_digest for i from 0 <= i < hex_digits: if digest[i] != c'0': break else: tries[0] = counter return hex(counter)[2:] |
到现在为止一切都非常简单。我只声明了早已知道的一些变量类型，并使用最干净的 Pyrex counter 循环。一个小技巧是将 py_digest（一个 Python 字符串）赋值给 digest（一个 C/Pyrex 字符串），目的是确定其类型。经过实验，我还发现循环字符串比较操作速度都非常快。这些会带来什么好处呢？
清单 7. Pyrex 化 mint 函数的速度结果
|
1
2
|
$ ./hashcash_test.py hashcash_pyx2 >/dev/null20.3749 seconds (116636 hashes per second) |
这下好多了。我已经对原有的 Python 进行了一些细微的改进，这可以稍微提高最初的 Pyrex 模块的速度。不过效果还不明显，仅仅提高了很少的百分比。
剖析
有些东西似乎不对。速度提高几个百分比和 Pyrex 主页（以及很多 Pyrex 用户）那样提高 40 倍有很大的差距。现在应该来看一下 这个 Python _mint() 函数中 哪些 地方真正消耗了时间。有一个 quick 脚本（此处没有给出）可以分解复杂操作 sha(challenge+hex(counter)[2:]).hexdigest()：
清单 8. hashcash 的 mint 函数的时间消耗
|
1
2
3
4
5
6
7
8
9
|
1000000 empty loops: 0.559------------------------------1000000 sha()s: 2.3321000000 hex()[2:]s: 3.151 just hex()s: <2.471>1000000 concatenations: 0.8551000000 hexdigest()s: 3.742------------------------------Total: 10.079 |
显然，我并不能将这个循环从 _mint() 函数中删除。虽然 Pyrex 改进后的 for 循环可能有一点加速，但是整个函数主要是一个循环。我也不能删除对 sha() 的调用，除非要使用 Pyrex 重新实现 SHA-1（即使我要这样做，也没有自信自己可以比 Python 标准的 sha 模块的作者做得更好）。而且，如果我希望得到一个 sha.SHA 对象的 hash 值，就只能调用 .hexdigest() 或 .digest()；前者的速度更快。
现在真正要解决的是 hex() 对 counter 变量的转换，以及结果中时间片的消耗情况。我可能需要使用 Pyrex/C 的字符串连接操作，而不是 Python 的字符串对象。然而，我见过的惟一一种避免 hex() 转换的方法是手工在嵌套循环之外构建一个后缀。虽然这样做可以避免 int 到 char 类型的转换，但是需要生成更多代码：
清单 9. 完全 Pyrex 优化过的 mint 函数
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
cdef _mint(char *challenge, int bits): cdef int hex_digits, i0, i1, i2, i3, i4, i5 cdef char *ab, *digest, *trial, *suffix suffix = '******' ab = alphabet hex_digits = int(ceil(bits/4.)) hash = sha for i0 from 0 <= i0 < 55: suffix[0] = ab[i0] for i1 from 0 <= i1 < 55: suffix[1] = ab[i1] for i2 from 0 <= i2 < 55: suffix[2] = ab[i2] for i3 from 0 <= i3 < 55: suffix[3] = ab[i3] for i4 from 0 <= i4 < 55: suffix[4] = ab[i4] for i5 from 0 <= i5 < 55: suffix[5] = ab[i5] py_digest = hash(challenge+suffix).hexdigest() digest = py_digest for i from 0 <= i < hex_digits: if digest[i] != c'0': break else: return suffix |
虽然这个 Pyrex 函数看起来仍然比对应的 C 函数更加简单易读，但是它实际上最初的纯 Python 的版本更为复杂。通过这种方式，在纯 Python 中展开后缀生成与最初的版本相比会对总体速度有些负面的影响。在 Pyrex 中，正如您期望的一样，这些嵌套的循环都是很少花费时间的，因而我节省了转换和分时调度的代价：
清单 10. mint 函数 Pyrex 化优化后的速度结果
|
1
2
|
$ ./hashcash_test.py hashcash_pyx3 >/dev/null13.2270 seconds (166125 hashes per second) |
当然，这比我开始的时候好多了。但是速度提高也不过是两倍。大部分时间的问题是（此处也是）消耗了太多的时间在对 Python 库的调用上，而我并不能对这些调用编写代码来提高速度。
令人失望的比较
速度提高 50% 到 60% 似乎是值得的。达到这个目标我并没有编写 多少 代码。但是如果您认为是在原来的 Python 版本中添加 两条 语句 import psyco;psyco.bind(_mint)，那么这种加速方法就不会给您多深的印象：
清单 11. mint 函数 Psyco 化的加速结果
|
1
2
|
$ ./hashcash_test.py hashcash_psyco >/dev/null15.2300 seconds (157550 hashes per second) |
换而言之，Psyco 之不过添加了两行通用的代码，就几乎能实现相同的目标。当然，Psyco 只能用于 x86 平台，而 Pyrex 可以在具有 C 编译器的所有环境上执行。但是对于这个特定的例子来说，os.popen('hashcash -m '+options) 的速度会比 Pyrex 和 Psyco 都快很多倍（当然，假设可以使用 C 工具 hashcash）。
