"BartC" <b...@freeuk.com> writes:
> "Pascal J. Bourguignon" <p...@informatimago.com> wrote in message
> news:87sk0qkzhz....@kuiper.lan.informatimago.com...
>
>> Nothing extraordinary here. Common Lisp is more efficient than C.
>> http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf
>> http://portal.acm.org/citation.cfm?id=1144168
>>
>> Actually, it's hard to find a language that has no compiler generating
>> faster code than C...
>
> I had a quick look at Lisp to see if your claims had any basis. I
> tried this program:
>
> (defun fib (n)
> (if (< n 2)
> n
> (+ n (fib (- n 1)) (fib (- n 2)) )
> ))
>
> But it gave the wrong results and it took ages to figure out why. Even
> after downloading a working version for comparison, it's was difficult
> to spot the extraneous 'n' (I think I was concentrating on getting the
> round brackets all in the right places).
>
> I thought you were saying that Lisp (and dynamic typing in general)
> was better for pointing out errors? The above error in C would have
> been picked up more easily I think (due to less parentheses clutter,
> and more obvious separators between terms).
There are more parentheses in C (you must take into account {} and []
too, and <> in C++), and the additionnal separators in C are clutter.
> As for speed, executing fib(38) took about 60 seconds on my machine
> (gnu clisp with no switches set).
Yes, you choosed the ONLY CL implementation having an interpreter by
default, and which when compiling, compiles to a virtual machine. This
happens also to be my favorite CL implementation, which tells you how
much I care about those silly time benchmarks.
If you want to try a CL implementation generating faster code, try SBCL.
> (Compared with 3.5 seconds, for my
> own interpreted, dynamic language, and 0.6 seconds for C.)
--
__Pascal Bourguignon__ http://www.informatimago.com/
--
http://mail.python.org/mailman/listinfo/python-list
