写在前面
最近看了本书,"python 高性能编程". 其实买书的时候还是对这个书抱有很大的希望的, 但是读了一遍之后, 感觉, 翻译, 对, 翻译, 实在是太烂了. 好多中式英语不说, 甚至有些地方不是很通顺. 不过对于我这样英文一般的人来讲肯定还是比英文书看的效率高些. 书中其次讲述了优化 python 效率, 增强计算性能和节省空间的方法, 部分内容还是很有启发性的, 这里简单的聊一聊.(下面的内容和书中的介绍顺序不一定一致, 但是大多数内容都是可以在书中找到对应的)
python 高性能的局限
我之前在学习大气模式的时候也是解除了一些编程语言, C,c++,fortran. 但是这次是第一次使用动态语言来实现高性能. 各种原因主要是 python 是一个高级语言, python 解释器为了抽离底层用到的计算元素做了很多工作, 我们实际上面对的就是一个 python 黑箱, 只是知道我们的操作和计算是可以做到的但是执行的具体过程对开发者是不透明的; 另一个原因就是开发 python 解释器的时候为了线程安全所引入的全局解释器锁, 这就是 "臭名昭著的 GIL".
对于前一个问题, 所造成的影响比较直观, 比如由于 python 虚拟机的影响使得矢量操作不能直接可用了, 但是其实我们可以用例如 numpy 这样的外部库实现, 这个并不是一个根本性的问题; 另外就是数据局部性的问题, python 抽象影响了任何需要为下一次计算所准备的缓存安排, 这是由于 python 是一个垃圾收集语言, 虽然对象在无引用的时候会进入垃圾收集过程, 但是内存是自动分配并在需要的时候释放的, 这会导致内存碎片并且会影响向 CPU 缓存的传输; 最后一个就是由于 python 是高级语言, 所谓高处不胜寒. 高级语言在让开发者方便的实现程序原型的时候也带来了一个问题, 就是没有来自编译器的恰当优化. 当我们编译静态代码时, 编译器可以做很多的操作来改变对象的内存布局以及优化 CPU 的指令来优化. 此外由于 python 支持动态类型, 张三可能一开始还是个草履虫, 转眼间就是人了, 这让优化过程更是难上加难.
对于后一个问题, 首先谈一谈 GIL 本身. 前面已经说过了, GIL 中文名称是全局解释器锁. 但是需要明确一点, 就是虽然这里提到了这个是影响 python 高性能的缺点, 但是这并不是 python 语言的特性, 这只是在实现 python 解释器 (CPython) 的时候所引入的特性. 一些其他的 python 解释器是没有这样的问题的, 如 JPython. 但是谁让现在是 CPython 的天下呢?
回到 GIL, 官方的解释是这样的:
In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython's memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)
可以看到, 为了解决多线程之间的数据完整性和状态同步, 前人们用了最自然的解决方法, 就是加锁. 但是由于这么干了之后很多库的开始接受这样的设定, 就导致这个并不是 python 特性非常像 "特性". 但是随着 python3 开始的优化设计, 至少在高密度 I/O 问题时, 多线程仍然是一个可行的加速方案.
一些性能检测工具
来源: http://www.bubuko.com/infodetail-3360030.html