windows – 为什么在lisp中计算到10亿这么慢？

(defun billion-test () 
  (setq i 0) 
  (loop while (< i 100) do 
    (setq i (+ i 1)))) 
(billion-test) 
(print "done")

我有上面的Lisp代码,简单地循环到十亿.问题是它确实存在
慢.比我写过的任何琐碎程序都要慢.这是它所花费的时间
运行我有的解释器(gcl和clisp).

Compiled  Uncompiled
GNU Common Lisp(gcl)    270-300s  900-960s
Clisp                   280-300s  960-1647s

我使用这个Python代码来计算Clisp的时间并使用系统时间进行近似
使用gcl,因为您无法从命令提示符运行它.

import sys
import time
import os

start=time.time()
os.system(" ".join(sys.argv[1:]))
stop=time.time()

print "\n%.4f seconds\n"%(stop-start)

以下是与其他语言的while循环的比较：

Kawa scheme     220.3350s
Petite chez     112.827s
C#              1.9130s
Ruby            31.045s
Python          116.8600s        113.7090s(optimized)
C               2.8240s          0.0150s(optimized)
lua             84.6970s

我的假设是循环而< condition>做的是Lisp相当于一段时间
环.我对那些1647(25分钟)有些怀疑,我正在看那些东西
时间,它可能会减慢执行速度,但差不多800s？我不知道.
这些结果很难相信.根据Norvig Lisp
比Python快3到85倍.从我得到的东西来看,最合乎逻辑的
这种缓慢执行的解释是Windows中的Clisp和gcl有某种
减慢大迭代的bug.怎么,你问,我不知道？
那么,我的问题是,为什么这么慢？
有没有人得到这样的东西？

更新1：
我运行了Joswigs的程序,得到了这些结果：

compiled   uncompiled
gcl    0.8s       12mins
clisp  5mins      18mins

gcl编译程序很好,但clisp给出了这个警告：

;; Compiling file C:\mine\.cl\test.cl ...
WARNING: in BILLION-TEST in lines 1..8 : FIxnuM-SAFETY is not a 
valid OPTIMIZE quality.
 0 errors,1 warning
;; Wrote file C:\mine\.cl\test.fas

     ;; clisp
     [2]> (type-of 1000000000)
     (INTEGER (16777215))

     ;;gcl
     (type-of 1000000000)
      FIxnuM

猜猜这可能是花了一分多钟的原因.

更新2：
我以为我会再次尝试另一个实现来确认
它真的是减缓它的bignum比较.我获得了sbcl
对于Windows并再次运行该程序：

* (print most-positive-fixnum)
   536870911

 * (compile-file "count-to-billion.cl")
   ; compiling file "C:/mine/.cl/count-to-billion.cl"
   (written 09 OCT 2013 04:28:24 PM):
   ; compiling (DEFUN BILLION-TEST ...)
   ; file: C:/mine/.cl/count-to-billion.cl
   ; in: DEFUN BILLION-TEST
   ;     (OPTIMIZE (SPEED 3) (SAFETY 0) (DEBUG 0) (FIxnuM-SAFETY 0))
   ;
   ; caught WARNING:
   ;   Ignoring unkNown optimization quality FIxnuM-SAFETY in:
   ;    (OPTIMIZE (SPEED 3) (SAFETY 0) (DEBUG 0) (FIxnuM-SAFETY 0))

 * (load "count-to-billion")

我希望我可以告诉你需要多长时间,但我从来没有看到它的结束.我等了
2个小时,观看了一集吸血鬼日记(呵呵),但还没有结束.
我期待它比Clisp更快,因为它的MOST-POSITIVE-FIxnuM更好
正.我正在保证缓慢的实施点,因为只有gcl可以拉动
跑了不到一分钟.

用gcl运行Rörd的代码：

(time (loop with i = 0 while (< i 1000000000) do (incf i))) 

gcl with Rords's code:
>(load "count-to-billion.cl")
Loading count-to-billion.cl
real-time : 595.667 secs
run time : 595.667 secs

>(compile-file "count-to-billion.cl")
OPTIMIZE levels: Safety=0 (No runtime error checking),Space=0,Speed=3
Finished compiling count-to-billion.cl.
#p"count-to-billion.o"

>(load "count-to-billion")
Loading count-to-billion.o
real time : 575.567 secs
run time  : 575.567 secs
start address -T 1020e400 Finished loading count-to-billion.o
48

更新3：

这是最后一个,我保证.我试过Rords其他代码：

(defun billion-test ()
  (loop with i fixnum = 0
        while (< i 1000000000) do (incf i)))

令人惊讶的是,它的运行速度与Joswig一样快,不同之处在于关键字fixnum和
有：

gcl的输出：

real time : 0.850 secs
run time  : 0.850 secs

sbcl的输出(运行大约半秒钟然后吐出来)：

debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {23FC3A39}>:
  The value 536870912 is not of type FIxnuM.

clisp的输出：

Real time: 302.82532 sec.
Run time: 286.35544 sec.
Space: 11798673420 Bytes
GC: 21413,GC time: 64.47521 sec.
NIL