From: J W Dalton
Subject: Re: ANSI C style `pointers' in LISP??!?? (and musings about CL)
Date:
Message-ID: <CB59Cv.F6B@festival.ed.ac.uk>
···@dennis.flw.att.com (Lawrence G. Mayka) writes:
>In article <············@life.ai.mit.edu> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
> More generally, one problem I have with CL is that I don't know what my
> implementors considered important, and code that works well using some
> features on one implementation may run slowly on another
> implementation.
It's not too hard to get a pretty good idea of what will be
reasonably fast. The same problem does occur for other languages
(eg, implementations of C in which character pointers have a
different representation from other pointers so that conversion
from one to the other isn't a no-op; machines that lack fixed-point
multiply and divide), but the conventions of reasonable
implementation are better established.
>- I would be happy enough simply to have available a comprehensive
>benchmark suite for CL constructs.
It often helps to simple run some programs you're familiar with
and, if performance seems odd, try some profiling tools.
-- jd
From: Thomas M. Breuel
Subject: Re: ANSI C style `pointers' in LISP??!?? (and musings about CL)
Date:
Message-ID: <23k1nlINNpcr@life.ai.mit.edu>
In article <··········@festival.ed.ac.uk>, ····@festival.ed.ac.uk (J W Dalton) writes:
|> >In article <············@life.ai.mit.edu> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
|>
|> > More generally, one problem I have with CL is that I don't know what my
|> > implementors considered important, and code that works well using some
|> > features on one implementation may run slowly on another
|> > implementation.
|>
|> It's not too hard to get a pretty good idea of what will be
|> reasonably fast.
I have a good idea of what's fast in AKCL, what's fast in CMU CL,
and what's fast in Lucid (at least, I used to).
|> The same problem does occur for other languages
|> (eg, implementations of C in which character pointers have a
|> different representation from other pointers so that conversion
|> from one to the other isn't a no-op; machines that lack fixed-point
|> multiply and divide), but the conventions of reasonable
|> implementation are better established.
Yes, that's the point. One reason why conventions are better
established for C is that there is less for which conventions needed to
be established.
Hence, my suggestion of banishing significant chunks of the CL standard
into libraries so that both users and implementors have an easier time
on coming up with conventions (not that it will ever happen).
|> It often helps to simple run some programs you're familiar with
|> and, if performance seems odd, try some profiling tools.
I know. I just don't like having to do that for every CL program
that I get, and/or to patch up somebody else's program tuned for
ACL to run well under CMU CL.
Thomas.