Comments on: More on Fibonacci. Oops, Sorry Lisp… Haskell runs it 5 times faster

By: Muha

Muha — Thu, 24 Apr 2008 18:43:26 +0000

Fastest:

import Control.Monad
import Text.Printf

fibs :: [Integer]
fibs = 0:1:zipWith (+) fibs (tail fibs)

fib n = fibs !! n

main = forM_ [0..45] $ \i -> printf “n=%d => %d\n” i (fib i)

By: Isaac Gouy

Isaac Gouy — Mon, 07 Jan 2008 15:37:30 +0000

Geir Aalberg wrote
> this comparative test between SBCL Lisp and GHC Haskell

And note all those SBCL “due to type uncertainty” warnings.

By: Geir Aalberg

Geir Aalberg — Thu, 03 Jan 2008 03:18:28 +0000

You might also find this comparative test between SBCL Lisp and GHC Haskell useful. The “recursive” test does a series of recursive computations including Fibonacci, and here SBCL is only 20 % slower:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=sbcl&lang2=ghc

Also, note the wise words on the front page:

“How can we benchmark a programming language?
We can’t - we benchmark programming language implementations.
How can we benchmark language implementations?
We can’t - we measure particular programs.”

By: Mike Hansen

Mike Hansen — Wed, 26 Dec 2007 04:05:56 +0000

This nice thing about Python is that it has Cython ( http://www.cython.org ). The original Python code took 131s on my machine. The following is the conversion of that code to Cython:

cdef fib(int n):
if n == 0 or n == 1:
return n
else:
return fib(n-1) + fib(n-2)

def test(n):
for i in range(n):
print “n=%d => %d” % (i, fib(i))

This code runs in 2.08 CPU seconds on my machine.

By: Geir Aalberg

Geir Aalberg — Fri, 14 Dec 2007 16:11:57 +0000

Guys,

for precise benchmarking you should turn always off I/O during iterations. Running under clisp on my MacBook Pro (same config as yours), the recursive Fibonacci test takes 0.005539 sec for n=45, while turning off the call to the actual computation reduces it to 0.003004 sec, i.e. only a 45 % reduction in cpu time.

Granted, some of this is startup overhead, but commenting out the format statement gives only a run time of 0.000125 sec, so unless it’s smart enough to optimize out those function calls this can be neglected.

By: Brian Adkins

Brian Adkins — Sat, 01 Dec 2007 18:32:28 +0000

Compiling the Haskell code with optimizations made a *huge* difference. The fastest of several runs w/o optimization was 6.552s and with optimization was 0.860s. With that, the Lisp code took 1.8 times as long to execute.

Either one of those blows away Ruby which is what I typically code in. It took 95s

By: Antonio Cangiano

Antonio Cangiano — Sat, 01 Dec 2007 09:32:50 +0000

Ahah, that’s cool w-g. With all the optimizations on, and using Valentino’s optimized version, I can see that Lisp is very fast. That’s very good. We knew already that the main compilers for Lisp and Haskell were very fast, just like OCaml and F# are too. But establishing which one is faster and for what applications, is beyond the reach of our silly test.

By: w-g

w-g — Sat, 01 Dec 2007 08:44:53 +0000

For both non-tail-recursive versions:

Haskell (ghc with -O2):
real 3m7.850s (187.85s)
user 2m23.953s (143.95s)
sys 0m1.188s

Lisp (GCL with optimization turned on):
real time : 137.860 secs
run-gbc time : 117.470 secs
child run time : 0.000 secs
gbc time : 0.000 secs

“Sorry Haskell…”

By: w-g

w-g — Sat, 01 Dec 2007 01:04:19 +0000

- Include type declarations
- Set optimizations on
- Compile the functions using a fast Lisp compiler (SBCL or CMUCL)

- If you use CMUCL, then use block compilation

I tried both on my machine, and Lisp was several times faster.

By: Antonio Cangiano

Antonio Cangiano — Sat, 01 Dec 2007 00:28:42 +0000

Valentino wrote:
> Common Lisp is a wonderful wonderful language IMHO.

On this we entirely agree, and it’s fast too. Mine was a tongue in cheek reply to the Lisper who wrongly compared apples and oranges.