[boost] Re: FSM Review

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-13 07:50:30

David Abrahams wrote:
> All I'm trying to say is that Andreas hasn't given me the impression
> that he feels high performance is a _crucial_ area for this library to
> address.

You are right inasmuch as that performance is only 2nd on my priority 
list. First comes satisfying the requirements and ease-of-use. However, 
it *is* important for me to deliver something that can be described as 
efficient, given the requirements.

> I come at FSMs from the "pure abstraction" point-of-view; the UML
> statecharts that this library is aimed at can have all kinds of warts
> and complications (some of which are very useful) on them that aren't
> part of the basic FSM abstraction.  Part of what makes FSMs fast may
> be the simplicity of the model.  It seems as though being able to
> model UML statecharts is a primary design goal for Andreas, and that

Yes.

> he doesn't consider providing some useful subset of that functionality
> in order to get high performance an option.  I could be
> misunderstanding; someone please correct me if so.

I did consider that and tried to explain why I failed. I'm afraid that I 
haven't been very successful in convincing people that the main 
obstacles aren't easy to overcome.

> It seems to me that if "orthogonal states" is the only feature in
> conflict with getting the highest dispatching performance, it ought to
> be possible to design a library whose performance only degrades if you
> use that feature.

I suppose you are inferring that from what I said in 
http://tinyurl.com/7ybeq?
I see that this can easily be misunderstood. Fact is that the current 
interface *theoretically* allows for constant time dispatch, as long as 
orthogonal states are not used. If they are used you get O(n) dispatch 
where n is the number of currently active orthogonal regions. However, 
there are a few practical problems for which I'll probably need help to 
overcome them.

> But this library seems to have a design that's
> fundamentally incompatible with an approach like that.  To get there,
> both the interface and the implementation would have to be redesigned
> IIUC.  So that sums up why I think evolving toward support for
> lightweight FSMs is not likely.

See above, a few optimizations are theoretically possible but it is 
clear that the proposed FSM library will probably never earn itself the 
predicate lightweight.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.