[boost] Re: FSM review

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-12 12:41:15

Jonathan Turkanis wrote:
> Instead of replying point by point, let me summarize your message and
> reply in general.
>
> 1. My one sentence summary of your rationale was unfair

I think so, yes. To me, the undertone of that summary and other 
sentences suggested arrogance on my part. You wrote:

"The requirements are X; I tried hard to satisfy X without compromising 
performance, but I couldn't; therefore, it can't be done."

To me, especially the last 8 words imply that I think I have tried 
*every* technique imagineable. This implies that I know pretty much 
everything there is to know about C++ and associated techniques. I'm 
very far from claiming that.

> 2. If I object to part of your library I should offer a concrete
> proposal to fix it

Either that or prototypes of techniques of which I said I can't see how 
they will work. I said that because I have invested considerable time in 
discussing things that might come to mind when one wants to improve 
performance. I can't think of much else I can say in support of the 
current design performance-wise. So I thought it would be more 
productive if you or anyone else could make concrete proposals. Such a 
proposal would either send me back to the drawing board or I would need 
to argue convincingly why it doesn't work.

> 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.

> I'm still not sure what part of my summary was wrong,

See above.

> but I'm sorry I
> offended you.

Apology accepted.

> What I would like to see in the rationale is a
> comparison of a small handful (2-5) of alternate implementation
> technique, either approaches taken by other libraries or approaches
> you tried yourself early in development, together with an explanation
> of why they fail to satisfy the requirements.

That's interesting. I was under the impression that exactly such a list 
of alternate implementation techniques would not satisfy you, because it 
would in no way show that the design I chose is the best 
performance-wise. And performance was your biggest concern, wasn't it?

> I realize you do
> mention some other frameworks, but you don't sketch their
> design/implementation or show how they fail to satisfy the
> requirements. Furthermore, readers wishing to understand the
> performance limitations of your library should not have to be told to
> examine the code.

That was never my intention, see above.

> You should provide a section giving a fairly
> detailed presentation of the implementation, explaining where the
> performance problems arise.

Ok, noted.

Regards,

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