31

我发现在 Python 和 Ruby 中，函数调用和循环之类的简单事情，甚至只是增加计数器的循环都比在 Chicken Scheme、Racket 或 SBCL 中花费的时间要多得多。

为什么会这样？我经常听到人们说慢是为动态语言付出的代价，但 Lisps 非常动态，而且速度也不是很慢（它们通常比 C 慢不到 5 倍；Ruby 和 Python 可以达到两位数）。此外，Lisp 风格使用递归，并不总是尾递归，很多，堆栈是堆中延续的链表等，这似乎是应该使 Lisp 比命令式 Python 和 Ruby 慢的东西。

Racket 和 SBCL 是 JITted，但 Chicken Scheme 要么是静态编译的，要么使用非优化的解释器，这两者都应该非常不适合动态语言并且速度很慢。然而，即使使用csiChicken Scheme 的简单解释器（它甚至不进行字节码编译！），我的速度也远远超过 Python 和 Ruby。

与类似的动态 Lisp 相比，为什么 Python 和 Ruby 如此慢得离谱？是因为它们是面向对象的并且需要巨大的 vtable 和类型层次结构吗？

示例：阶乘函数。Python：

def factorial(n):
    if n == 0:
        return 1
    else:
    return n*factorial(n-1)

for x in xrange(10000000):
    i = factorial(10)

球拍：

#lang racket

(define (factorial n)
  (cond
   [(zero? n) 1]
   [else (* n (factorial (sub1 n)))]))

(define q 0)

(for ([i 10000000])
  (set! q (factorial 10)))

计时结果：

ithisa@miyasa /scratch> time racket factorial.rkt
racket factorial.rkt  1.00s user 0.03s system 99% cpu 1.032 total
ithisa@miyasa /scratch> time python factorial.py
python factorial.py  13.66s user 0.01s system 100% cpu 13.653 total
4

4 回答 4

25

本地编译的 Lisp 系统通常比非本地编译的 Lisp、Ruby 或 Python 实现快很多。

定义：

  • 本机编译 -> 编译为机器码
  • 已编译 -> 编译为机器码或其他目标（如字节码、JVM 指令、C 代码……）
  • 解释 Lisp -> 直接运行 s 表达式，无需编译
  • 解释 Python -> 在字节码解释器中运行编译的 Python。默认的 Python 实现并没有真正解释，而是使用编译器对字节码指令集进行编译。字节码被解释。通常字节码解释器比执行本机代码慢。

但请记住以下几点：

  • SBCL 使用本机代码编译器。它不使用字节码机器或类似 JIT 编译器的东西从字节码到本机代码。SBCL 在运行前将所有代码从源代码编译为本机代码。编译器是增量的，可以编译单个表达式。因此它也被 EVAL 函数和 Read-Eval-Print-Loop 使用。
  • SBCL 使用一个优化编译器，它利用类型声明和类型推断。编译器生成本机代码。
  • Common Lisp 允许进行各种优化，使代码不那么动态或不动态（内联、早期绑定、无类型检查、专用于声明类型的代码、尾调用优化……）。利用这些高级特性的代码可能看起来很复杂——尤其是当编译器需要被告知这些事情时。
  • 如果没有这些优化，编译的 Lisp 代码仍然比解释代码快，但比优化的编译代码慢。
  • Common Lisp 提供了 CLOS，即 Common Lisp 对象系统。CLOS 代码通常比非 CLOS 慢——这种比较是有意义的。动态函数式语言往往比动态的面向对象语言更快。
  • 如果语言实现使用高度优化的运行时，例如对于 bignum 算术运算，则慢速语言实现可能比优化编译器更快。一些语言有许多用 C 实现的复杂原语。这些原语往往很快，而语言的其余部分可能非常慢。
  • 也可以有 Python 的实现，它们生成和运行机器代码，比如 PyPy 的 JIT 编译器。从 Ruby 2.6 开始，Ruby 现在也有了 JIT 编译器。

此外，一些操作可能看起来相似，但可能有所不同。for遍历整数变量的循环真的与遍历范围的循环相同吗for？

于 2013-11-09T16:37:13.587 回答
14

Ruby/Python/etc 中的方法分派成本很高，Ruby/Python/etc 程序主要通过调用方法进行计算。甚至forRuby 中的循环也只是方法调用的语法糖each。

于 2013-11-09T21:13:16.847 回答
3

我不知道你的球拍安装，但apt-get install如果没有标志运行，我只是使用 JIT 编译的球拍。运行 with--no-jit给出的时间更接近 Python 时间（racket: 3s, : 37s racket --no-jit, python: 74s）。此外，由于语言设计原因（非常自由的模块系统），模块范围内的赋值比 Python 中的本地赋值慢，将代码移动到函数中会使 Python 处于 60 年代。剩余的差距可能可以解释为巧合、不同的优化重点（Lisp 中的函数调用必须非常快，Python 人们不太关心）、实现质量（引用计数与适当的 GC、堆栈 VM 与寄存器 VM）的某种组合等，而不是各自语言设计的基本结果。

于 2013-11-09T16:16:01.687 回答
-5

我认为不是 Python 本身变慢，而是 Python 解释器以较慢的速度在代码中移动。如果您尝试使用 py2exe 之类的工具编译代码，那么它可能比 lisp 更快。您必须尝试一下，但我认为它的解释器速度很慢。

于 2013-11-09T15:13:43.657 回答