Re: PCL/CLOS performance

[Jeff Dalton <jeff@aiai.edinburgh.ac.uk>]

>     Date: Fri, 14 Oct 88 15:27:30 BST
>     From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

> I assume that since you have sent your message (6 days) enough other
> messages have gone by to clarify this.  But this is important enough
> that it is worth addressing directly.

Actually, I haven't seen that many replies, and none said all
that you did.  So thank you.

>     Well, (1) is it not the case that TICLOS is not PCL?  If so, it may
>     not say all that much about PCL performance.  
> 
> Yes, TICLOS is not PCL.  But it has an architecture quite similar to the
> one PCL has.  There are some differences which stem from having the kind
> of hardware tag checking they have, and some other differences which are
> a matter of differing philosophy.  

OK.  One reason I asked is that we're often told in WG-16 meetings
not to judge CLOS by PCL but rather (so it seems) by TICLOS.  And
by a sort of transitivity argument it seemed that we shouldn't judge
PCL by TICLOS.

I also asked in a slightly earlier message whether there were any
implementations other than TICLOS and PCL and whether any were on
stock hardware (as opposed to adaptable to stock hardware).  My
motives there were similar, I suppose, namely to find out what
the evidence for CLOS performance amounts to.  I don't mind if
CLOS and PCL turn out to be fast.  Indeed, I would be pleased.

>                                                (2) If a Common Lisp
>     is reasonably fast otherwise but slow for PCL, it is at least
>     reasonable to suspect PCL rather than the Common Lisp's code
>     generation.
> 
> No No No.  If an unoptimized port of PCL is slow in a Common Lisp which
> otherwise has good performance it says absolutely nothing about real PCL
> performance.  PCL is fundamentally designed to require implementation
> specific tuning.  There are certain critical code sequences which must
> be "hand coded" because no sane Common Lisp compiler will emit the
> proper code sequence.

Now I understand.  I thought the message I was answering had in
mind that PCL was slow in KCL because KCL code generation was
poor *in general*, not that certain adaptations hadn't been made.

> The feature of PCL is that these code sequences are quite isolated,
> quite small, and it should be possible to write them for any Common
> Lisp (any one I have seen anyways).

>     Besides, not everyone can afford a super-CL.  The object system should
>     be such that it is not too hard to get performance from it comparable
>     to that of the rest of CL.
> 
> I think the fact that PCL can be gotten to competitive performance in
> any Common Lisp satisifies this concern.