Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!pacbell.com!pacbell!att!cbnewsc!lgm
From: lgm@cbnewsc.att.com (lawrence.g.mayka)
Newsgroups: comp.lang.scheme
Subject: Re: LISP vs LISP->C performance
Summary: Lisp-to-C translator "staticizes" for speed
Message-ID: <1990Sep10.231320.6461@cbnewsc.att.com>
Date: 10 Sep 90 23:13:20 GMT
References: <9008151749.AA23832@mailhost.samsung.com> <258@cadlab.sublink.ORG>
Organization: AT&T Bell Laboratories
Lines: 40

> krulwich@ils.nwu.edu (Bruce Krulwich) writes:
> >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.

The literature I've seen indicates that Chestnut's Lisp-to-C
translator requires that the entire Common Lisp program be submitted
at one time.  The translator essentially makes compile-time decisions
(e.g., as to the argument list expected by each function) that a
genuine Common Lisp implementation has no right to make.  Chestnut's
product may be very useful in its own right, but I would not classify
it as a true Common Lisp system.

Kyoto Common Lisp and its progeny, on the other hand, are genuine
Common Lisp implementations that happen to use C as an intermediate
code representation, primarily for portability reasons.  Some such
Lisp systems actually perform competitively, but not spectacularly.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.