When executing (time (loop for i below (expt 10 8) count t))
it takes a long time, sbcl takes less than a second on this. So not useful when speed is required. More: (time (loop for i below 1000000 count t) takes 7 seconds on my computer, so counting to (exp 10 8) would take 700 seconds, and sbcl do that in 0.1 seconds, so in this example the ratio is 7000 times slower than sbcl.
SL-USER> (time (loop for i below (expt 10 8) count t))
Evaluation time: 19376ms
100000000
SL-USER> (time (loop for i below 1000000 count t))
Evaluation time: 272ms
1000000
SL-USER> (defun fib (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))
#'FIB
SL-USER> (time (fib 32))
Evaluation time: 1601ms
2178309
These timings are in Firefox; Chromium is almost 2x faster. Also, it doesn't completely freeze the browser in the mean time (we have green threads).
I used to think it's quite slow, but somehow it's much faster than any other posted here. The only Lisp in browser I know to beat SLip (by a large margin) is JSCL, which compiles to JS.
I can see what happens there in JSCL.. I took a look at
(disassemble (lambda () (loop for i below (expt 10 8) count t)))
Seems TAGBODY is compiled into a while(true) which sets an exception handler on each iteration. (and then, LOOP macroexpands into a TAGBODY). I don't think there's a better way to do it, BTW — JS is simply not a friendly compilation target. But `try` on each iteration is quite costly, that's most probably the bottleneck here.
Hm, you're right, JSCL seems abnormally slow on this loop (27.5 sec here). SLip consistently takes 19.3 sec. My CPU is rather beefy (Ryzen 9 HX 370). What's your hardware and browser?
But JSCL is much faster on the fib example, that's why I thought it should be generally faster. After all, it compiles to JS.
Bytecodes compiler used in this build from repl is one-pass with very little optimizations, so it is not surprising. Natively compiled code is much faster.
