为什么动态类型语言相对比较慢?

静态类型语言中,在声明变量时已经指定了数据类型和表示方法。动态类型语言是在运行期间检查数据的类型,不得不保持描述变量值的实际类型标记,程序在每次操作变量时,需要执行数据依赖分支。

间接分支(Indirect branch)数据局部性(data locality)对于运行时的性能是致命的。

这就是动态语言的JIT编译器基准测试要强调near-C的内循环速度,以及避免大的数据结构和数据处理问题的原因。

我也希望像Python这样的动态类型语言可以变快。我试过用Python来进行传统的服务器编程——“系统语言”领域——但是效果真的不好,我现在考虑用Java重写一个服务器。

因此,我花时间思考如何真正静态地编译Python。毕竟,那是我梦寐以求的编程语言!但当我思考如何将动态类型代码与静态编译Python结合起来时,我遇到了数据变慢的问题:

在动态语言中,通常所有数组中的元素(或其他数据结构)类型各不相同,所以有不同的表示值。因此,这些值都必须被单独存放为堆,而不是顺序地存为数组。这意味着如果对不相邻的内存执行数据依赖分支,则对缓存有更高的要求。

也有一些聪明的技巧,使用变量中的特殊bit,将一些原生类型(像整型)打包成一个类型,类似于指针,但这要求寄存器在操作过程中进行跟踪,会增加开销。

还有一些方法,比如使用JIT编译热路径(hot path)时,如果你直接插入没有标类型的值,而不是在堆里分别标记类型, 那么与JIT编译过的代码的互操作性会降低,如果其他代码改变了数组中的一个值的类型,就会出现非常严重的后果。

我一直在思考,在Python语言中,什么是静态的,什么不是。通过SSTA(统计静态分析)和逃逸分析可以判断,大量正常的程序是静态的。Paul Biggar给了我信心证实我的猜测是正确的,我的Python代码90%都是静态的。

有人会问,那另外的10%呢?通常情况下,我可以让所有的都是静态的,或者想象它被参数类型的限制范围特殊化了。除了Python语言的标准模式,其他模式都由Web服务器分配给基于HTTP方法(如果收到GET请求就称为“get”方法)的Web处理器,这也需要程序员依照switch语句(如elifs的长链)来进行修改。

Robert Harper对“从单一类型静态语言方面,动态语言是如何实现的”这个问题作出了很好的解释,下面这句话是我希望他能进一步进行解释的:

引用

 我深知“编译器可以优化它”,至少在某些情况下。

我确信他说的“某些情况”是指遇到non-escaping的情况,因为和后面的执行代码进行交互时,你应该要能够确定escape的类型。

一些动态调用是无污染的——编译器可以从代码检查中发现一些变量(或方法)是动态的,但动态的代码不表示其他变量也是动态的,因为不同类型的变量、方法、成员的存在或缺失都被限制成了可识别的类型(或null)。

但通常编译器是无法从代码检查中发现这些情况的,如果无法追踪到执行的情况,就无法知道代码如何依赖以及如何改变其他静态变量的值。因此,工作中断,所有变量再次变为动态的。

我一直在努力寻找把Monkey Patch(不改变初始源代码来扩展和修改动态语言运行代码的方法)、Set(属性或索引器元素赋值的“访问器”方法)、SetAttr(SetAttr 语句可以为一个文件设置属性信息)等解决办法移植到我虚构的Python编译器里,因为类型标记严重地降低了运行性能。

快速的数据结构对于内存访问模式和缓存位置是非常重要的,还可以减少分支和对这些分支的标记工作。

Jonathan Shapiro的文章Programming Language Challenges in Systems Codes非常棒,我很赞同文中的观点。

相关推荐