Re: [boost] Low-level precision timer proposal - Part II

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-07-16 18:39:38

On Sun, 16 Jul 2006 23:09:29 +0200, "Philippe Vaucher"
<philippe.vaucher_at_[hidden]> wrote:

>What I don't understand is why you didn't talk earlier in this thread ? You
>seem to have missed a lot of discussion where your input would have been
>interesting.

I haven't followed this thread closely. But precisely where I should
have spoken?

>* it separates the "elapsed timer" notion from the notion of "clock
>> device" (the "source"); the advantage is that you can plug-in any
>> source you want.The only requirement on the source class is that it
>> provides:
>>
>>   - a time_duration_type typedef
>>   - void start();
>>   - time_duration_type elapsed()
>
>
>It's basically the same design than Jeff proposed (about it being templated
>on the clock) except it's not tied to the boost::date_time interface

I don't know. What I noticed in your code is that you have to call
clock_type::local_time() in some places. And I didn't think this was
the case when seeing the interface specification. That's certainly due
to my ignorance on boost::date_time; but, admittedly, you don't need
any time point from a logical point of view (or you can go with an
irrelevant "instant zero" time point reference which doesn't affect
results).

>which
>makes it suitable for timers like QueryPerformanceCounter, that's why I
>think I'll refactor it a bit to follow your design so we can have one
>generic template class instead of template specializations.

BTW, those were partial template specializations, which rule out VC6
and other compilers.

>That should cover the basics and make the code comments more
>> understandable. In short, we are still at the drawing board, but once
>> the design is in place, it really takes a little time to write down
>> the code.
>>
>
>Right so you are actually proposing whole new round of discussions... ok, I
>thought we had this behind :) I'm not used to the boost mailing list enough
>I guess.

Sorry, but, if that may comfort you, it's a good thing. The more it
will be at the drawing board, the less in the debugger and in the
feature request list ;)

PS: I'm also experimenting a bit in assembly with time stamp counters;
I've tried them on an Intel P4 and the results are impressive. The way
to insert assembly code vary with the compiler but that can be easily
be managed. Probably other CPU brands could be supported. For now I
haven't considered AMDs (the Intel documentation is quite long already
:) But it's a joy to read) and SMP systems. Furthermore, cache misses
during frequency measurements are taken into account, but dynamic
frequency adjustments, such as performed via SpeedStep, are not. But
it's just a first cut. And then, I don't think one would want to use
these facilities with SpeedStep in the way.

--
[ Gennaro Prota, C++ developer for hire ]
[    resume:  available on request      ]