[boost] Re: FSM review

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-20 15:51:20

Andreas Huber wrote:

>> I've read the documentation and most if not all of the review
>> discussion, and still I do not find your explanations satisfying.
>
> It helps if you explain exactly what you don't find satisfying, see
> below.

Of course. I was just summarizing my previous messages.

>> It's very tempting to try to design an FSM library with better
>> performance characteristics, but I don't have anywhere near enough
>> time, esp. because I'd have to start out by becoming an FSM expert. I
>> don't think I should have to do this before writing a review.
>
> Certainly not. However, I do expect that people questioning the
> performance (and along with it the implementation) are able to ask
> concrete questions why some things are the way they are. You partially
> did that in your previous posts but only partially.

> I think it is
> difficult to respond to statements like:
>
> <quote>
> Possibly the joints between parts of machines defined in separate TUs
> must be weaker (i.e., less known at compile time) than the connections
> between collections of states implemented in a single TU.
> </quote>

Why should it be easy to respond?

What I found shocking in your documentation was the statement that hand-written
machines can be much faster than framework-generated machines. To accept a
library with such poor performance (even if it is adequate in many cases)
requires a very convincing justification, which I believe is obviously absent
from the documentation. As a reviewer, I could have done my job simply by
pointing to the absence of justification, and left it at that. (This is similar
to a motion for summary judgment by the defense in an American trial: if the
plaintiff hasn't presented evidence, you just point out that fact and you're
done.)

All my other vague suggestions were attempts to suggest either (i) how the
library could have been redesigned to yield better performance or (ii) how you
might have documented the impossibility of achieving better performance given
your requirements. I'm aware they were not fully fleshed-out proposals. I was
hoping you would try to meet me half-way, by trying to figure out what I was
getting at and explaing why it wouldn't work. At the very least, you could have
asked me what I meant.

> As I said before, I think it is close to impossible to prove that a
> certain design is the best performance-wise. Also, I don't claim that
> there isn't any room in the current implementation for improvements,
> rather I think it has reached a stage where substantial (>= 2x faster)
> optimizations are non-trivial.
> I can only describe why common optimizations don't work or why they
> would violate one ore more of the requirements.

All I wanted is a succint description of the various known approaches to
implementing FSMs -- including existing frameworks and stuff you tried in the
early stages of developing your framework -- together with an explanation of the
performance tradeoffs.

> Things that I
> *consciously* avoided or unsuccessfully tried are described in the
> rationale.

If all the things you unsuccessfully tried are described in the rationale, then
you didn't try very much. I was giving you the beneift of the doubt by assuming
you had omitted describing your alternate designs.

> Moreover, during any programmer career a bag of knowledge
> is acquired that is unconsciously applied to every programming job.
> Naturally, this bag of knowledge is not the same for everyone

This is obviously true.

> which is
> probably the main reason why the rationale seems to be sufficient for
> some people while others find it unsatisfying.

This is just funny. People who find your rationale satisfying could be people
who don't care about performance as long as it's good enough for their
application or people who failed to consider the same design alternatives you
failed to consider.

> Ergo, the only thing I
> can do is listen to the questions people ask and either add
> explanations to the rationale or change the implementation.

>>>> 3. If I want to understand where the performance bottlenecks are, I
>>>> should examine the code.
>>>
>>> No, I didn't mean that in the generality your summary suggests. In
>>> *one* *specific* case I thought it is better if *you* (Jonathan)
>>> look at the code before I explain all the details in text. I did
>>> that because I *assumed* (maybe wrongly) that you want a very
>>> detailed description for which I really don't have the time at the
>>> moment.
>>
>> But this one specific case -- the expense of implementing state local
>> storage -- forms the basis for your argument that dispatch time is
>> not so important, right?
>
> Right. Here's a description of the relevant parts of the
> implementation:

<snip detailed description>

This sort of stuff should be in the docs.

Jonathan