Newsgroups: comp.lang.clos
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!nntp.crl.com!pacbell.com!gw2.att.com!nntpa!ssbunews!iexist!not-for-mail
From: clarisse@iexist.flw.att.com (55437-olivier clarisse(haim)463)
Subject: Re: CMU-CL CLOS efficiency?
Message-ID: <D9EFxy.B2L@ssbunews.ih.att.com>
Originator: clarisse@tenet
Sender: clarisse@iexist (55437-olivier clarisse(haim)463)
Nntp-Posting-Host: tenet.flw.att.com
Organization: AT&T
References:  <mmcconn.801347647@klein.math.okstate.edu> <D9EC6p.9Cy@ssbunews.ih.att.com>
Date: Tue, 30 May 1995 16:17:58 GMT
Lines: 60


Resend... orignial distribution was restricted.

In article <mmcconn.801347647@klein.math.okstate.edu>, mmcconn@math.okstate.edu (Mark McConnell) writes:
|> I have recently started using CLOS to write a large mathematical
|> program that does lots of integer number-crunching.  Before this I was
|> using Common Lisp, a la CLtL1.  I have been using CMU-CL (thanks to
|> the advice of people on this group :-) ), and have been pleased with
|> it.  It gives tons of notes on how to optimize the number-crunching.
|> I was wondering if people had any thoughts on how efficient a
|> corresponding CLOS program would be.
|> 
|> One thing confusing me is that the CMU-CL documentation has a lot to
|> say about efficiency, but very little to say about CLOS.  It uses the
|> portable package PCL to get its CLOS, and I know nothing about PCL.
|> 
I am not familiar with CMU-CL, but with many other CLOS implementations.
Yet, CMU-CL must do the right thing if it talks a lot about efficiency,
since writing efficient integer number-crunching has very little to do
with CLOS but everything to do with numbers and type declarations in CL.

One can view CLOS as an object-oriented substrate placed over CL.
This *is* a nice feature: you can write programs in multiple paradigms,
and you can write very efficient number-crunching code within each CLOS
method you write, but you do not need to implement every single
arithmethic operation as a CLOS method. [I realize Smalltalk has done
this and done it very well. Is it necessary? I don't view mathematics
and arithmetics as "object-oriented".]

We have also gained experience using CLOS in real-time applications.
There we viewed CLOS as a wonderful abstraction language to write
less code. We got rid of countless switch (case) statements and
many more if statements by relying on CLOS to dispatch the right
methods to the right classes. This made code easier to maintain
and to evolve. There is a small cost for figuring out the initial
dispatch, but even that can be reduced by "training" the application
in most implementations (so the run-time cost can be minimized).

With PCL the cost of method invocation might be higher than with
other CLOS that have been optimized by their respective vendors.
However you can *never* go wrong if you use CLOS to model high level
concepts in your application and use CL functional style programming
and type declaration inside CLOS methods to encode efficient
algorithms. My experience indicates *very* efficient code can be
written this way.

It is also likely (even in PCL) that a single method definition
is as fast as a function definition (DEFUN), so you can
really use methods everywhere and stay aware that there is potential
overhead only in areas where CLOS will have to choose between
multiple methods based on object types. [And even that overhead
may not as bad as poorly written switch (case) and if statements
- instead of lookup tables.]

[My personal experience... Not necessarily It's.]
-- 
----------------
Olivier Clarisse
Member of Technicall Staff
AT&T Bell Laboratories
