Re: [boost] Re: FSM review

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-22 11:41:07

From: "Jonathan Turkanis" <technews_at_[hidden]>
> Andreas Huber wrote:
> > Jonathan Turkanis wrote:
> >> Andreas Huber wrote:
> >>>
> >>> <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?
> >
> > I'm not saying responding should be easy. My point was that such
> > statements are not likely to bring up useful answers.
> 
> Since you apparently don't know what I was suggesting, and you didn't bother to
> ask, I don't see how you can say this.

The discussion is devolving.  I think you both are seriously
trying to understand the other, but both are failing.

Without digging out the previous messages and confirming the
matter, I think Jonathan's suggestion, quoted above, was simply
that *when* the user wants separate translation units *and* the
features that would typically require tight coupling, you could
introduce a weaker link -- some form of indirection -- that would
slow the resulting FSM or even complicate its specification, but
would at least permit the functionality.

> >> What I found shocking in your documentation was the statement that
> >> hand-written machines can be much faster than framework-generated
> >> machines.
> >
> > One could probably produce an equally shocking case for just about any
> > non-trivial library out there. My "mistake" was to measure it and
> > publish the numbers.
> 
> This is ridiculous. Consider, for example, the iterators library, or Andrei and
> Dave's smart pointer library. If incrementing an iterator constructed using the
> framework could take up to twenty times as long as incrementing a hand-written
> iterator, or if copying a framework-generated smart pointer was twenty times as
> expensive as copying a hand-written smart pointer, these libraries would be dead
> in the water.
> 
> A case closer to home is the iostreams library. I conducted measurements showing
> that a stringstream constructed using the library was essentially
> indistinguishable from Dinkumware stringstream, and that a library-generated
> fstream was slightly faster (See
> http://lists.boost.org/MailArchives/boost/msg71285.php for caveats) I couldn't
> honestly recommend that somebody use a library-generated socket_stream, say, if
> it would involve any significant slowdown.

This is right on target.  *Since* the current design, with all of
its requirements is so much slower, then the onus is on Andreas
to explain why the requirements his library meets exceed those
met by other FSM libraries and directly lead to the performance
overhead.  Clear distinctions regarding the performance
improvements gained by avoiding the performance draining features
in an FSM while still using this library will help to demonstrate
that situation, too.

> >> 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.
> >
> > That became sufficiently apparent during the review. My hope was that
> > people would understand that the provided functionality must have a
> > significant overhead. I was obviously wrong and there will be better
> > documentation in this direction.
> >
> >> As a
> >> reviewer, I could have done my job simply by pointing to the absence
> >> of justification, and left it at that.
> >
> > Fortunately, there are many other things that matter in a review.
> 
> My objection to your library was based on a deficiency in the rationale. I don't
> know if this deficiency could be remedied without exposing fundamental problems
> in your library. The only way to find out would be to try to fix it.

It is also possible that the only way to remedy the deficiency is
to remove a requirement.

> >> 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.
> >
> > This is exactly something that I don't think I will ever be able to
> > prove. I can only provide evidence that hints in this direction. New
> > C++ techniques and idioms are discovered almost on a monthly basis and
> > there's always the possibility that such a technique enables a much
> > better implementation (e.g. I wouldn't have imagined that it is
> > possible to enumerate overloads like Alexander does or I couldn't
> > possibly have conceived the technique that makes possible the FOREACH
> > macro). I think it is close to impossible for an individual to be
> > proficient in all the currently known techniques, not to mention the
> > ones that have yet to be discovered.
> 
> Okay, I shouldn't have said "impossibility"; maybe "impossibility, using known
> methods" or "unliklihood, using known methods" would have been more accurate.
> But seriously, you must know that I'm not insisting you prove that you're
> library could not possibly be improved by yet-to-be-discovered-techniques.

I think too much emotion is being attached to words both
consciously and subconsciously.

> >>> 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.
> >
> > What else should I have tried?
> 
> Normally, in designing a framework one considers a small handful (say two to
> six) of alternate designs which view the subject matter from completely
> different perspectives. In your case, what were those alternate designs?

Note that Jonathan is asking that those alternatives be
documented.  That way, other developers who wonder why you didn't
try X will see that you did and they'll see why you decided it
was not appropriate.

> Let me make one last attempt to explain what should be in the rationale. Look at
> section 16.2 of "The C++ Programming Language", 3d ed. Here Stroustrup gives two
> design criteria for a containers library, and then discusses three designs:
> 
>   "Specialized containers and iterators" - satisfies the first criterion
>   "Based Containers" - satisfies the second criterion
>   "STL" - satifies both criteria
> 
> I'm not suggesting that you give such a detailed treatement as Stroustrup.
> However, if you were to give a similar overview of the landscape of possible FSM
> frameworks, and thoughtfully discuss the tradeoffs in flexibility and performace
> which each involves, reviewers might have some confidence that you are aware of
> the techniques which might be used to construct a fast, flexible FSM framework,
> and have carefully considered the design.
> 
> This type of overview would probably be a useful component of any library's
> documentation; in your case it is made absolutely essential by the performance
> figures you cite.

I don't think I can add any more to that.  I think it is
reasonable and clear.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;