[Gcl-devel] Re: Potential speed

[Camm Maguire]

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Greetings!

Adam Warner <address@hidden> writes:

> Hi Peter Scott,
> 
> > That depends on how you define "a good deal". I used "a good deal
> > slower" to mean "if you transform a C program into a Lisp one, chances
> > are that the Lisp one will be slower".
> 
> If you transform a non-trivial Lisp program into a C one, chances are the
> the C one will be slower. Much slower. You are very likely to run into
> Greenspun's Tenth Rule of Programming[1] while trying to produce C code
> with the same semantics as the Lisp version. To avoid this you should use
> a pre-existing, debugged, high performance Lisp to C compiler. GCL is a
> potential candidate.
> 

Just a quick note here affirming the non-triviality of getting a
correct translation/conversion.  GCL has spent considerable effort to
get where it is now wrt the gcl random compiler tester.  To my
understanding, GCL and clisp are the only systems which pass these
tests essentially indefinitely at the present time, and of course you
get native code with the former.

Take care,


> It's even possible to appreciate some of this complexity with a trivial
> program:
> 
>   (defun factorial (n) (if (zerop n) 1 (* n (factorial (- n 1)))))
> 
> What's your C translation of:
> 
>   (mapcar #'factorial (mapcar #'random (make-list 10 :initial-element 100)))
> 
> Regards,
> Adam
> 
> [1] <http://philip.greenspun.com/research/>
>     "Any sufficiently complicated C or Fortran program contains an ad-hoc,
>      informally-specified bug-ridden slow implementation of half of Common
>      Lisp."

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah