From: pisati
Subject: Re: CKOS performance (was Re: ANSI CLISP: strengths vs. weaknesses?)
Date:
Message-ID: <3260361E.26CE@nichimen.com>
Tim Bradshaw wrote:
>
> * Martin Cracauer wrote:
>
> > For Common Lisp, I'm unsatisfied mostly with CLOS. It's flexibility
> > greatly damages possible performance improvements and it is not very
> > integrated with the rest of the system. A dylan-like OO system with
> > sealing and standard types beeing normal classes would be nicer.
>
> I'd be interested in knowing if CLOS performance really is inherently
> very bad. Naively I would guess that it must be poor, because of all
> the redefinition stuff, but is it really true that it must be bad?
> There's a paper by some Symbolics people
> (http://www.apl.jhu.edu/~hall/text/Papers/CLOS-Optimizations.text)
> which talks about how they made their CLOS fast(er), which seems to
> imply that most of the improvements are not dependent on weird
> hardware, but I'm not sure if it's really right.
The issue of CLOS performance largely depends if the CLOS implementation
you are using is an ANSI only, or if it takes into account the (not
ANSI) Meta Object Protocol (MOP) specification.
MOP is actually the specifications on how to implement CLOS itself,
so that anybody can modify and specialize CLOS at will.
As an example, generic function dispatching in CLOS is defined as a
function which calls different methods depending on the type of its
arguments. With MOP is very simple to define a specialized kind of
Generic function wich dispatches depending on the result of predicates
on its arguments (or some context in which the evaluation is performed).
MOP clearly states where the implementor can optimize (and how), and
where the implementor must follow the specifications.
Anyway, both CLOS and MOP, are highly optimizable, and they have a
perfomance going from great to just ok, in the Lisp environment I
program with (ACL 4.3). In general CLOS is intended to be used where
you really need OO programming (and MOP where your OO language is not
suited for solving your problem). If you do not need OO (as is the case
for many problems) simple function call is definitively faster.
At Nichimen (as an example) we have an entire 3D animation package
completely built in CLOS (ACL), and we are satisfied by Lisp and CLOS
performance. If we do loose some speed in some parts of the product,
we do anyway gain much more in code flexibility and easiness to
program and maintain in most of the rest of the product.
As a final remark I do not think "weird" hardware is required to do
any CLOS optimization. Symbolics Lisp Machines had specialized hardware
mainly because of the data "tagging" necessary to "type" all the pieces
of information managed by the dynamic memory. The last processor
produced by Symbolics, the Ivory chip, was beneficial to Lisp mainly
because of its 40 bits architecture (32bits word + 8bits tag).
64bits processors and RISC processors are freeing Lisp from a lot
of previously "necessary" optimizations. But all this has nothing
to share with CLOS.
> Alternatively, if you're willing to do without MI, then presumably
> it should be easy to make methods defined on structure classes go fast
> because you don't have to deal with class redefinition?
The nice thing of MOP is that enables you to define any specific kind
of classes and methods. If you deal only with classes wich will never
be redefined, then you can define non redefinable classes, and rewrite
methods dispatching accordingly.
> --tim
Luca Pisati