Python几种并发实现方案的性能比较..doc

前言1. 偶然看到Erlang vs. Stackless python: a first benchmark， 对Erlang和Stackless Python的并发处理性能进行了实验比较，基本结论认为二者有比较相近的性能。我看完产生的问题是，Stackless Python与Python的其他并发实现机制性能又会有多大区别呢，比如线程和进程。因此我采用与这篇文章相同的办法来对Stackless Python、普通Python的thread模块、普通Python的threading模块、普通Python的processing模块这四种并发 实现方案进行了性能实验，并将实验过程和基本结果记录在这里。 后来看到了基于greenlet实现的高性能网络框架Eventlet，因而更新了实验方案，将greenlet也加入了比较，虽然greenlet并非是一种真正意义上的并发处理，而是在单个线程下对程序块进行切换轮流执行。 (Edit Section ↓) 实验方案2. 实验方案与Erlang vs. Stackless python: a first benchmark是相同的，用每种方案分别给出如下问题的实现，记录完成整个处理过程的总时间来作为评判性能的依据： 由n个节点组成一个环状网络，在上面传送共m个消息。 将每个消息（共m个），逐个发送给1号节点。 第1到n-1号节点在接收到消息后，都转发给下一号节点。 第n号节点每次收到消息后，不再继续转发。 当m个消息都从1号逐个到达第n号节点时，认为全部处理结束。 (Edit Section ↓) 硬件平台2.1 Macbook Pro 3,1上的Vmware Fusion 1.0虚拟机中，注意这里给虚拟机只启用了cpu的单个核心： 原始Cpu：Core 2 Duo，2.4 GHz，2核心，4 MB L2 缓存，总线速度800 MHz 分配给虚拟机的内存：796M （单个CPU，还能比较并发吗？） (Edit Section ↓) 软件平台2.2 Vmware Fusion 1.0下的Debian etch： 原始Python：Debian发行版自带Python 2.4.4 Python 2.4.4 Stackless 3.1b3 060516 processing-0.52-py2.4-linux-i686.egg 原始Python下的greenlet实现：py lib 0.9.2 (Edit Section ↓) 实验过程及结果3. 各方案的实现代码见后文。实验时使用time指令记录每次运行的总时间，选用的都是不做任何输出的no_io实现（Python的print指令还是挺耗资源的，如果不注释掉十有八九得影响测试结果），每次执行时设定n=300，m=10000（Erlang vs. Stackless python: a first benchmark文章中认为n可以设置为300，m则可以取10000到90000之间的数值分别进行测试）。 (Edit Section ↓) Stackless Python的实验结果3.1 real 0m1.651s user 0m1.628s sys 0m0.020s 即使将m扩大到30000，实验结果仍然很突出： real 0m4.749s user 0m4.716s sys 0m0.028s (Edit Section ↓) 使用thread模块的实验结果3.2 real 1m13.009s user 0m2.476s sys 0m59.028s (Edit Section ↓) 使用threading模块配合Queue模块的实验结果3.3 不太稳定，有时候这样： real 1m9.222s user 0m34.418s sys 0m34.622s 也有时这样： real 2m14.016s user 0m6.644s sys 2m7.260s (Edit Section ↓) 使用processing模块配合Queue模块的实验结果3.4 real 3m43.539s user 0m15.345s sys 3m27.953s (Edit Section ↓) greenlet模块的实验结果3.5 real 0m9.225s user 0m0.644s sys 0m8.581s (Edit Section ↓) eventlet模块的实验结果3.6 注意！eventlet 的这个实验结果是后来增补的，硬件平台没变，但是是直接在 OSX 自带 Python 2.5 环境下执行出来的，同时系统中还有 Firefox 等很多程序也在争夺系统资源。因此只能作为大致参考，不能与其他几组数据作直接对