lua加速python_Lua vs. Python

最新推荐文章于 2024-05-13 16:06:31 发布

weixin_39869043

最新推荐文章于 2024-05-13 16:06:31 发布

阅读量429

点赞数

文章标签： lua加速python

在《 Programming in Lua 》系列里谈了 Lua 的 stackless 实现。说到 stackless 设计，难免和 Python 的 stackful 实现比较一下。

以前总有一个疑惑。为什么 Python 既要采用 native thread，又要用 great-lock 将其变成实质上的协作式 thread。像 Lua 这样的 coroutine 不好么？现在知道了，非不为，不能也。既要尽量保证虚拟机的可移植性，又采用了非常依赖 CRT stack 的 stackful 设计，语言本身没有 synchronous primitive，不能应付真正的 preemptive 多线程。这种情况下，多线程加 big-lock 是唯一的折衷了。由此也知道了 Python 的 generator 为什么只允许在第一层函数中 yield，因为 stackful 设计不允许保存 call stack (说老实话，只允许在第一层函数中 yield 的 coroutine 不过是两个函数调来调去，在 C 里实现起来也不难)。Python 3.3 开始支持更宽松的 yields，不过实现的方式和 Lua 的 yields-in-C 差不多，作为基于虚拟机的语言是比较原始的手段。

拿 Lua 和 Python 做比较令人恍惚感觉正在比较 Objective-C 和 C++。Lua/Python 和 Objective-C/C++ 都是在共同基础上发展出来：后者扩展 C 语言；前者用 C 语言实现基于 byte-code 的虚拟机。它们都有理想的「标杆」：Objective-C/C++ 的标杆是 Smalltalk/Simula 等面向对象语言先驱；Lua/Python 是 Lisp 这样的高级动态语言先驱。努力的方向都是降低「标杆」过大的性能开销和简化「标杆」过于复杂 (或者过于精简) 的概念。Python 和 C++ 相对较早的尝试，都采用了比较低级的机制：C++ 用函数指针模拟成员函数；Python 依赖 CRT stack 直接实现 byte-code stack。这些「第一次」都没能「do things right」。后来的第二次尝试才作出了更妥当的取舍。

在《 The Art of UNIX Programming 》里指出了系统设计的「第二系统综合症 (second-system effect)」。乔布斯也提到过「第二个产品」的问题。在一个成功的系统上衍生的第二个系统有时会因为没有理解第一个系统成功的真正原因而失败。但是，如果还有机会的话，由此衍生的「第三系统」往往会做得更好。对于上面所说的语言发展来说，它们的基础 (C 语言) 和「标杆」是「第一系统」，第一次改进的尝试毁誉参半，而后来的「第三系统」更加出色。

赞过：

赞正在加载……