python主要用于做系统编程_用PYTHON进行系统级编程

什么是系统级编程

什么是系统级编程？似乎不太好用一两句话给出一个很清晰定义。不过我们到是可以列举下系统级编程都有哪些特点。性能要求高。具体表现为对处理时间、空间占用、IO效率等方面都有很高的要求，常见的应用场景：游戏引擎、数据库引擎、搜索引擎等等。

直接与设备打交到。具体表现为需要能够方便、高效的处理内存缓存区等，常见的应用场景：设备驱动及相关的上层应用软件。

对于第一点，实践中为了能够同时满足时间、空间及IO方面的要求，往往也需要开发工具能够对内存、线程甚至是寄存器级别的操作提供很好的支持。这也是为什么在各种新的编程语言层出不穷的今天，C/C++的地位仍然不可动摇的原因之一。

使用PYTHON进行系统级编程会有哪些问题

PYTHON做为一种通用的高级语言，在应用级开发方面的能力是有目其睹的，那么，它是否也能用于系统级开发呢？我相信有这种想法的人并不是少数，不然，也不会有像GO、DUST这样的新的系统级开发语言被开发出来。它们的初忠都是一样，就是开发一种即像PTYHON那样支持高级的语言特性，又能像C/C++那样支持高性能的系统级开发的编程语言。

那么为什么不是直接用PYTHON吗？最显而易见的问题就是性能，做为一种解释型的语言，PYTHON的执行效率一直被人诟病，而GIL的存在更是雪上另霜，使得PYTHON甚至无法支持当下主流的多核处理器。即便是同样是解释执行的PHP、LUA等语言比起来，PYTHON的执行效率也是要慢上一大截。为什么会这么慢？原因就在于为了支持各种高级的语言特性，PYTHON不得不设计了一套非常复杂的对象模型，即便只是简单的c = a + b，在PYTHON内部也要经过一系列复杂步骤才能完成。

除了语言本身的性能，用PYTHON进行系统级开发还有另一个问题，那就是PYTHON语言本身并没有提供完备的对内存缓存区进行操作的语言特性。想从指定地址的内存中取读一指定类型的数据？很遗憾，在不依懒开发库的前提下，PYTHON做不到呀。不过，PYTHON还是有很多开发库可以完成这种事情，比如内建的bytearray, 标准库里的array、struct、ctypes，以及第三方的cffi等。但问题在于，受限于PTYHON的对象模型，在数据的读取和写回过程中不可避免的要进行转换操作，类似JAVA和C#中的拆箱、封箱操作，所以在执行效率上，远远无法达到系统级开发的需求。

高性能的PYTHON——PYPY

PYTHON本身只是一套语言规范，它有很多具体实现，比如最常用的CPYTHON，比较著名的还有基于JVM的JYTHON以及基于.NET的IRONPYTHON。做为后起之秀PYPY发展也非常迅速，并提供了很多有用的新特性。其中与本文关系最密切的特性就是JIT了，简单来说就是PYPY可以把PYTHON代码实时的编译为机器进行执行，以大大提升执行效率。

还是以c = a + b为例，在PYTHON的标准实现中，实际上等价于c = a.__add__(b)，它至少要包含一次函数调用操作，再加上是解释执行，所以其执行效率是很差的。而在PYPY中，解释器会跟据代码的上下文对a、b的类型进行推断并生成对应的机器码。比如，如果推断出a,b都是整数型，则会生成类似movl -4(%rbp), %esi

addl -8(%rbp), %esi

movl %esi, -12(%rbp)

的机器码。所以不难看出，PYPY的执行效率，在理论上是可以接近于C代码的。

接下来，即然PYPY可以推断出变理的类型，并生成原生的机器码，那么，在进行对内容缓冲区的操作时，是不是也就不再需要拆箱和封箱了呢？理论上是这样的，实际中则取决于目前PYPY所实现的优化算法的完备成度了。

PYTHON vs PYPY vs C

为了验证上面的猜想，设计一个简单的实验进程，并比较其在PYTHON/PYPY和纯C实现方式下的性能差异。

实验进程的功能简单，就是对一个4K长度的数组进行冒泡排序，数组每个元素都是一个结构体，以结构体的第一个字段做为排序的KEY。纯C实现的版本的完整代码参考：block_test.c。

接下来用PYTHON实现了同样的功能，其中，数据缓冲区的实现分别使用PYTHON内建的list类型、标准库中的array、内建的bytearray。对数据的拆箱、封箱操作分别用array默认、struct模块、c扩展(代码参考：buffer_proxy.c)、cffi库来实现，最后分别用PYTHON和PYPY执行实验脚本。完整的代码参考：array_test.py。

测试环境：DEVICE: Macbook Pro 13寸 Retina

CPU: 2.6 GHz Intel Core i5

MEM: 8 GB 1600 MHz DDR3

GRAPHIC: Intel Iris 1536 MB

OS: OS X Yosemite 10.10.2

CPYTHON: 2.7.6

PYPY: 2.5.0

纯C版本的执行时间为：24ms (未开启优化编译)实现方式CPYTHON执行时间(ms)CPYTHON相对于C的执行时间(倍)PYPY执行时间(ms)PYPY相对于C的执行时间(倍)说明内建list115147.96281.17PYTHON内置类型，虽然效率最高，但无法用于内存缓冲区的操作，不适用于系统级开发。

标准库Array130454.33291.21标准库提供的缓冲区操作类，但功能过于简单，同样无法满足系统级开发的需要。

标准库Array + Struct4576190.6724110.04同样是PYTHON标准库，功能上可以满足系统级开发的需要，但效率上还是不太能接受。

标准库Array + C Extention3044126.84--使用自定义的C扩展代替Struct类，相比之struct虽有提升，但比较有限。此外，由于兼容性问题，在PYPY上无法执行。

标准库Array + CFFI--321.33CFFI在功能上与ctypes类似，比struct还要更胜一筹，完全可以满足需要。性能上，由于CFFI的安装稍微有些复杂，所以没有在CPYTHON上测试，但其原理决定了跟C扩展的方法应该在同一级别。但PYPY上，由于PYPY对其进行了针对性的适配，所以性能上的表现也非常不错，完全可以满足大部系统级开发的需要。

从结果上可以看到，PYPY + CFFI的组合让人眼前一亮，要知道，目前PYPY的JIT引擎还没有支持太多的编译优化技术，如果未来PYPY的JIT能够进一步的优化，其结果是非常让人值得期待的。另一方面，PYPY也准备引入STM技术以解决GIL的问题，目前也已经实现相应的技术原型，可以想想一下，能够同时支持高性能与高并发的PYTHON离我们已经不远了。

© 本文版权所有，转载引用请注明出处