[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 31 12:44:33 2001 
Subject:Re: Objectclass Efficiency 
From:Aaron Sloman See text for reply address 
Volume-ID:1010331.01 

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Nick Hawes <n.a.hawes@cs.bham.ac.uk> writes:

> Date: Wed, 28 Mar 2001 17:02:47 +0100

> Hi all, I'm about to start implementing an A* search in Pop11, and I
> plan to use the objectclass OO extension to define the nodes in the
> search space. This way I can make my code extensible and apply the
> search to other problems. I just wanted to know if anyone had any rough
> (or otherwise) ideas about how the use of objectclass effects the
> running time for programs. Is there any significant overhead involved in
> using object class, or will it not make a significant difference
> (although this will obviously depend on the problem size).

Steve Leach designed Objectclass and produced the first implementation
(later modified by Robert Duncan at Sussex, to integrate it more fully
into the pop-11 system, though I don't know how much was changed then).

Steve tried hard to balance the trade-offs between

1. Power
        E.g. supporting multiple inheritance and multi-methods
        (generic functions)

2. Flexibility
        E.g. allowing recompilation of methods or class definitions
        after editing, without having to restart everything.

3. Conformity to the Pop-11 style
        E.g. slot access and method invocation use the Pop-11 procedure
        invocation mechanisms and the same syntax (as opposed to
        introducing new syntax words which might have given more scope
        for inserting inline code for efficiency?)

4. Efficiency
        (Space efficiency and time efficiency)
        See comments on optimise_objectclass in REF objectclass

The RCLIB package uses objectclass classes, mixins and methods all over
the place. It would have been VERY hard to do in such a flexible, easily
extendable way, without Objectclass. So I have never even tried to work
out what the overhead is compared with using only recordclass and
purpose pop-11 mechanisms. In any case, I suspect that much of the
overhead is in system calls and access to X mechanisms, which would be
there with or without use of objectclass.

SimAgent uses objectclass to make it easy to add new classes of agents
with their own versions of things like sim_run_agent, sim_run_sensors,
and various kinds of tracing methods. Objectclass also made it very easy
to combine the core simulation mechanisms with RCLIB mechanisms in
LIB sim_picagent, so that simulations automatically acquire graphical
interfaces if that library is used.

I did not even consider efficiency issues because it was obvious to me
that the main overhead in use of sim_agent was not going to lie in the
objectclass methods but in the use of poprulebase to implement the
"mental" mechanisms of agents. There is a huge amount of list processing
and pattern matching involved if the agents do anything interesting.

(However if you have large numbers of agents the distance comparison to
tell whether items are in sensor range of one another can be one of the
dominant CPU consumers, since there are roughly n*n comparisons for n
agents. Following a suggestion from Matthias Scheutz, who uses large
numbers of interacting agents and objects, I have recently introduced an
experimental version of sim_agent which directly supports partitioning
of the set of agents, e.g. into different sub-regions of the world. That
sort of thing could easily make more difference to total time than any
change between using objectclass and recordclass. (Anyone interested in
checking out this new variant of sim_agent should contact me).

Whether it is worth using Objectlcass for your A* search package depends
on how much your planner is going to be used for different classes of
problems *in the same process* (like the different classes of picture
objects that can be simultaneously active in RCLIB).

If every program will use the package for only *one* class of problems
(so that all nodes are essentially of the same class) then use of
objectclass is pointless: you could simply specify a collection of
procedures that have to be supplied by the user and will be invoked by
the problem-solver.

Another possibility is to use a higher order functional programming
style and make the problem_solver take as arguments not only a problem
to be solved but also a collection of procedures that define various
tests. E.g. TEACH SEARCHING shows how to define a general problem
solving procedure called

    solve_problem(
        initial, current_goal, isgoal, nextstates, samestate) -> result;

where isgoal, nextstates, and samestate are problem_specific procedures.

It leaves as an exercise the task of generalising solve_problem so that
it uses an additional problem-specific procedure for implementing
heuristics of various kinds.

E.g. it could use a user-supplied prune_and_insert procedure which takes
a list of still viable nodes and a list of new nodes, and returns a
pruned ordered list of nodes.

You could try something like that to get the generality you want.

However if the problem solver is going to call itself recursively on
many different sorts of sub-problems which require different sorts of
methods then it may be useful to use objectclass to ensure that
sub-problems get the right methods invoked without you always having to
find the methods and hand them to the recursive class, which would be
more hassle but might be more efficient.

Whether the difference in efficiency is significant will depend on how
much time is spent doing other things than slot access and method
invocation. If that is a small proportion of the total time then the use
of objectlass will make no significant difference to total efficiency,
and it may add enormously to convenience and extendability.

(You can use LIB profile to check. See HELP profile)

I expect Steve will correct any errors or gaps in my response!

Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk   (ReadATas@please !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html