Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!accuvax.nwu.edu!anaxagoras!krulwich
From: krulwich@ils.nwu.edu (Bruce Krulwich)
Newsgroups: comp.lang.scheme
Subject: LISP vs LISP->C performance
Message-ID: <1438@anaxagoras.ils.nwu.edu>
Date: 21 Aug 90 14:16:20 GMT
References: <9008151749.AA23832@mailhost.samsung.com>
Sender: news@anaxagoras.ils.nwu.edu
Reply-To: krulwich@ils.nwu.edu (Bruce Krulwich)
Organization: Institute for the Learning Sciences, Northwestern University, Evanston, IL 60201
Lines: 25
In-reply-to: gjc@mitech.COM

In article <9008151749.AA23832@mailhost.samsung.com>, gjc@mitech writes:
>Interesting side-note: A company called Chesnut software was at AAAI
>showing their LISP->C translator. It was interesting in that it
>produced *readable* C code.
...
>The disturbing thing was that it seemed to give BETTER performance
>than native lisp implementations from the other 3rd-party lisp vendors.
>Tells you something about the state of the art of lisp implementation
>if such a crude but effective hack as idiomatic LISP->C can do better.

I too saw this product and was intrigued.  I asked the vendor (who actually
seemed to know the technical aspects of the system) why he got a speedup
over most LISP's, and his thought was that it was because most LISP systems
are written in a system-independant way, while most systems have a C
compiler that is heavily optimized in system-specific ways.  In other words,
more work has gone into making sure the C compiler uses all the fastest
machine operations whenever possible, while LISP compiler writers have
presumably worried about other things like run-time environment and
portability.


Bruce Krulwich
krulwich@ils.nwu.edu