Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!snorkelwacker!think!kulla!barmar
From: barmar@kulla (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: CLOS speed
Message-ID: <31037@news.Think.COM>
Date: 25 Oct 89 06:41:04 GMT
References: <18769@pasteur.Berkeley.EDU>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 39

In article <18769@pasteur.Berkeley.EDU> faustus@yew.Berkeley.EDU (Wayne Christopher) writes:
>The CLOS book says in a few places that in a good implementation,
>method calls can be almost as fast as function calls.  I've used the
>Xerox version of CLOS (PCL), and it seems rather slow, but I haven't
>make any real comparisons.  My questions are:

No one ever said that PCL was a good implementation.  Its primary objective
was portability (that what the "P" stands for).  Since there are no
portable ways to implement compiler optimizations, it would be very
difficult for it to include any of these.  And on systems with
architectural support for objects and generic functions (e.g. Symbolics
machines) PCL can't take advantage of them.

>	Are there any really good implementations of CLOS yet, and will
>	they run under Allegro?

Symbolics announced in the Summer that their next release, which should be
released this winter, will include CLOS.  I suspect Lucid and Franz will be
including CLOS by the summer.

There was an attempt last year to organize a consortium of Lisp vendors to
develop a high-performance, portable implementation of CLOS.  It was
aborted because not enough people bothered to attend the organizing meeting
(held one evening during an X3J13 meeting).

>	Is it possible to compile CLOS code as efficiently as Lisp?

That's the theory.  Of course, it depends on the programmer including lots
of declarations so that the compiler can determine the class of objects and
optimize away most of the type dispatching.

Note that you shouldn't expect generic function calls to be as efficient as
normal function calls.  Remember that CLOS provides extra functionality per
line of code.  Naturally, there are some tradeoffs.

Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar