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.