I found out that there's already <boost/date_time/microsec_time_clock.hpp>, but on windows it uses GetSystemTimeAsFileTime(). This raises a potential issue: I don't know if GetSystemTimeAsFileTime() works at millisecond resolution like QueryPerformanceCounter() does, and I don't know if QueryPerformanceCounter() returns some kind of epoch.. the docs are rather lowly-documented on this. I also noticed that getimeofday() wasn't checked for failure in the current boost headers. I also fell on a page which stated that "On Windows, clock() returns the nearest approximation to wall-clock time since the first call to this function, based on the Win32 function QueryPerformanceCounter(). The resolution is typically better than one microsecond.". While I doubt it it might be interesting for our problem if it happen to be true. After the suggestions & having read the wiki I think we should indeed modifiy parts of date_time and template the timer class like mentionned. Should I try to give it a go ? Philippe On 5/15/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:

Carlo Wood wrote:

...

On Sun, May 14, 2006 at 05:09:28PM +0200, Silex wrote:

...

Would boost be interested by including this class in boost::timer ?

Even more so when it had microsecond precision.

...

I'm all ear for your suggestions / bugs / whatever fits it :)

It would be better when the object itself can be handled as variable (independent of it's internal structure).

For that to work best, there shouldn't be any 'double's in the internal structure. Two int's, one for seconds and one for microseconds, would be best, imho. There could be an accessor to get a rounded double in seconds, ie 'rseconds()' (I'd reserve 'seconds()' for returning the integer number of seconds.

I agree with this and it's been discussed before. Note I haven't looked at the new proposals, and can't till later, but I would like everyone interested in this topic to please look at:

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Timer

This is a proposal for the current timer to be replaced with a core template that can use date_time types (including the microsecond clock type) and time durations. Please edit and update this page with additional thoughts.

Thx,

Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Silex wrote:

I found out that there's already <boost/date_time/microsec_time_clock.hpp>, but on windows it uses GetSystemTimeAsFileTime().

This raises a potential issue: I don't know if GetSystemTimeAsFileTime() works at millisecond resolution like QueryPerformanceCounter() does, and I don't know if QueryPerformanceCounter() returns some kind of epoch.. the docs are rather lowly-documented on this.

Ah, I suspect there may be problems with the CPU clock changing speed with some of these timers, I'm not sure though...

I also noticed that getimeofday() wasn't checked for failure in the current boost headers.

I also fell on a page which stated that "On Windows, clock() returns the nearest approximation to wall-clock time since the first call to this function, based on the Win32 function QueryPerformanceCounter(). The resolution is typically better than one microsecond.". While I doubt it it might be interesting for our problem if it happen to be true.

After the suggestions & having read the wiki I think we should indeed modifiy parts of date_time and template the timer class like mentionned. Should I try to give it a go ?

I guess it depends what the class is supposed to do: whether it measures real-world time, or some performance metric that isn't really time related. John.

The problem with QueryPerformanceCounter is that QueryPerformanceFrequency is not (AFAIK) required to return the same value every time. It may be CPU clock based, and a low power CPU can vary its frequency depending on load.

No, "the frequency cannot change while the system is running." (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui...)

FWIW, I have found timeGetTime pretty reliable on Windows as a monotonic time provider. It only has 1ms resolution, though.

timeGetTime() is good but QueryPerformanceCounter() has lower overhead. Their resolution is similar tho. Philippe

On 5/15/06, Peter Dimov <pdimov@mmltd.net> wrote:

Silex wrote:

...

...

The problem with QueryPerformanceCounter is that QueryPerformanceFrequency is not (AFAIK) required to return the same value every time. It may be CPU clock based, and a low power CPU can vary its frequency depending on load.

No, "the frequency cannot change while the system is running." (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui...)

You are right, a variable frequency is explicitly disallowed in the documentation now. Most chipset bugs that affected QPC also don't seem to be an issue nowadays.

Does anyone know if the issue mentioned in this KB article is still relevant? http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323& --Michael Fawcett

On 5/15/06, Silex <silex0r@gmail.com> wrote:

...

Does anyone know if the issue mentioned in this KB article is still relevant?

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&

If I read correctly, it's an hardware problem, and those are the fabricants involved:

PCI ID Hardware Vendor 1039:0530 Silicon Integrated Systems (SiS) 1039:0620 Silicon Integrated Systems (SiS) 10B9:0533 Acer Labs, Inc. (ALi) 10B9:1533 Acer Labs, Inc. (ALi) 1106:0596 VIA Technologies, Inc. (VIA) 1106:0686 VIA Technologies, Inc. (VIA) 1166:004F Serverworks Corporation 1166:0050 Serverworks Corporation 8086:7110 Intel Corporation

Ah, I see that now. It also looks like those IDs are stored in the registry, so one could theoretically check to see if QPC/QPF performed correctly for the system, and then fall back on a lower precision but correct implementation. --Michael Fawcett

Michael Fawcett wrote:

There is also a problem with using QPC/QPF on SMP systems, but I am not knowledgeable about the specifics.

Actually I now recall hearing about QPC returning different results on the two cores of an Athlon x2, but I haven't verified it personally. A friend of mine claimed that he did, though.

I did some tests with the current boost::posix_time::microsec_clock and it *looks* like GetSystemTimeAsFileTime() has low level resolution, BUT I read somewhere that it's overhead is huge compared to QueryPerformanceCounter. I'll try to see if there's a way to get the epoch from QueryPerformanceCounter or timeGetTime, so I could make a usable microsec_clock based on it. Philippe

Silex wrote:

I did some tests with the current boost::posix_time::microsec_clock and it *looks* like GetSystemTimeAsFileTime() has low level resolution,

The resolution is good, but the time isn't updated any more often than the system clock (usually some 10-15 milliseconds).

BUT I read somewhere that it's overhead is huge compared to QueryPerformanceCounter.

I'd say it's usually the opposite way around, unless somethings changed due to some later WinXP service pack or hot fix. QPC can be a real performance killer on single CPU systems. It's been a while since I tested thought, so I can't speak for certain for how the performance counter is implemented on HT and/or dual-core platforms.

I'll try to see if there's a way to get the epoch from QueryPerformanceCounter or timeGetTime, so I could make a usable microsec_clock based on it.

Are you really talking about getting an absolute time with milli-/microsecond resolution? Be prepare to put down some work - there's no supported way of getting a correlation between the monotonic counters and calendar time. // Johan

Pavel Vozenilek wrote:

"Silex" wrote

...

I think I'll try to do two windows implementation for the template parameter of the timer class, one with QueryPerformanceCounter and one with timeGetTime which would try to #pragram comment(lib,etc) it.

I'll think more about it and propose something.

It may be interesting to take a look how Cygwin emulates gettimeofday() functionality.

IIRC, the last time I checked the time returned isn't updated any more often than the underlying (Windows) system time. It's been a while since that, though. // Johan

Ok, here's the new templated timer class from the suggestions. It's basically the code from Jeff with extensions and some slight corrections. Jeff, can you validate/correct the header text about copyrights ? I'm really not used to this so I did how I thought it should be done. I added two templates for the time type and time_duration type to make it more generic : template<class clock_type, class time_type = boost::posix_time::ptime, class time_duration_type = boost::posix_time::time_duration> class timer {}; I also added two typedefs for convenience: typedef boost::timer<boost::posix_time::second_clock> second_timer; typedef boost::timer<boost::posix_time::microsec_clock> microsec_timer; To see it in action do as usual, copy timer_new.hpp to the boost folder and compile main.cpp. This code seems to works fine on both windows & unixes and seems to do microsecond resolution as provided by boost::posix_time::microsec_clock. Now the question is, how should I do another microsec_clock class based on QPC or timeGetTime ? It's obvious that if I do one, it should not be used by the user as localtime() would not have a real meaning. As the initial goal is somewhat attained, do we want to make a QPC implementation at all ? At the moment the pros here are that we only change timer.hpp and the cons is a possible overhead on windows. Waiting of hearing from you :) Philippe

Peter Dimov wrote:

Johan Nilsson wrote:

...

My guess is that a monotonic timer solution based on QPC/QPF should be good enough for at least 90% of all applications.

People (game programmers) have been repeatedly running into problems with QPC in practice. It may be good enough for 90% of the _cases_, but if your _application_ depends on QPC for accurate timing, it can break and you may get a baffling bug report.

Of course. If someone needs accurate timing under Windows that should work everywhere, QPC is probably not the way to go. So don't use e.g. boost::timer<performance_counter> in this case - roll your own. A performance counter based implementation should still be usable for a large audience. If milliseconds is enough - perhaps the mmlib functionality is good enough (I have too little experience with that). Just out of curiousity - do you know if the performance counter was tsc-based, PIT-based, or whatever in the mentioned problem cases above?

...

...

We don't have a good TIME_MONOTONIC solution, and we really do need one for the threading library.

I guess the TIME_MONOTONIC stuff would mostly be used for sleep(). As there is no way to explicitly make a thread sleep less than the clock tick under Windows[*] - why do we need a high-res monotonic counter solution for the thread library? Or did I misunderstand you (probably)?

We need a monotonic time for condition::wait. It may not be high resolution (depending on your definition of high), it just needs to work reliably, which the current xtime implementation does not.

Sorry for being vague. I didn't see much of a point being able to specify a condition wait time with a microsecond resolution, when systems generally aren't capable to wake up the waiting thread in a shorter time than decided by the tick rate of the system. OTOH, if you can't specify a microsecond wait time you'll never be able to use this on platforms that provide this functionality (haven't seen one myself though).

I'm not sure which clock do you mean when you say that a thread can't sleep for less than a clock tick. If you mean the CPU clock, then yes, a no-op Sleep function that returns immediately would probably consume more than one clock tick, so it is impossible to make a thread sleep for less.

I referred to the timer tick period (~10-15 ms for the NT family). // Johan

Johan Nilsson wrote:

...

I'm not sure which clock do you mean when you say that a thread can't sleep for less than a clock tick. If you mean the CPU clock, then yes, a no-op Sleep function that returns immediately would probably consume more than one clock tick, so it is impossible to make a thread sleep for less.

I referred to the timer tick period (~10-15 ms for the NT family).

It used to be the case that you can't get better than 10ms precision on NT without calling timeBeginPeriod, but that was years ago, I think (NT 3.5, not sure about 4). I'm getting ms-precise timing (not hard realtime, obviously, but correct most of the time) on Windows XP.

Peter Dimov wrote:

We need a monotonic time for condition::wait. It may not be high resolution (depending on your definition of high), it just needs to work reliably, which the current xtime implementation does not.

Perhaps I am misunderstandig you, but how would a separate implementation of "monotonic time" help with condition::wait ? The key issue of (I assume you mean) timed_wait is, that the scheduler wakes up the thread in question. So no provision of any means capable of measuring time differences would be of help here. Any implementation will need to rely on the underlying threading API's notion of timed_wait, be it pthread_cond_timedwait or WaitForMultipleObject's timeout parameter. What do you think are xtime's pitfalls in this respect? Roland

Hello, As I didn't receive the answers I was looking for, here is my last proposal. My imlpementation does the templating of the timer class as suggested. By using boost::posix_time::microsec_clock as the template parameter, we are able to do microsec timing. This works fine, at least in the environnements I tested it (windows 2000 and gentoo). I added two typedefs: typedef boost::timer<boost::posix_time::second_clock> second_timer; typedef boost::timer<boost::posix_time::microsec_clock> microsec_timer; Now one can simply use boost::microsec_timer and time his code at microsecond level. Because of the long discussion about QueryPerformanceCounter that didn't came to a real conclusion, I decided to implement two additionnal timers: - boost::qpc_timer, which use QueryPerformanceCounter() for its resolution. - boost::tgt_timer, which use timeGetTime() for its resolution. As using those timers would make no sense on another platform than windows, those are not defined by default. One must #define BOOST_QPC_TIMER to get boost::qpc_timer and must #define BOOST_TGT_TIMER to get boost::tgt_timer. Trying to do those defines on another platform than windows results in an #error. Please tell me what do you think of the code (review ?) and tell me if this is ok for boost. To test it simply put timer_new.hpp into the boost folder and compile main.cpp, uncommenting the macros at top to test the second/qpc/tgt timers if wanted. The goal is that timer_new.hpp is then renamed to timer.hpp and replaces the current header. Thank you Philippe

That's fine with me, assuming documentation is updated as needed.

I can do it if nobody wants to do it, but someone have to explain me where are the files/how to submit them etc. Philippe

Well, I thought that the ultimate plan was to deprecate timer and move it into date_time -- my fault this hasn't happened -- although maybe it would be better to leave it stand-alone and let it depend on some date-time core. Regardless I would highly suggest looking at Quickbook to do new documentation.

Jeff

I have nothing against moving it into date_time. I'll take a look at Quickbook to see how it works... While I'm doing that, can you tell me if the header copyright text suits you ? I asked you a while ago if it was ok because I'm not experienced in writing those so I did how I thought it'd be. Philippe

Silex wrote:

Hello,

As I didn't receive the answers I was looking for, here is my last proposal.

[snip]

Because of the long discussion about QueryPerformanceCounter that didn't came to a real conclusion, I decided to implement two additionnal timers:

- boost::qpc_timer, which use QueryPerformanceCounter() for its resolution. - boost::tgt_timer, which use timeGetTime() for its resolution.

As using those timers would make no sense on another platform than windows, those are not defined by default. One must #define BOOST_QPC_TIMER to get boost::qpc_timer and must #define BOOST_TGT_TIMER to get boost::tgt_timer.

I've always found it really awkward having to define global macros to get features. Why not simply: (in "main" timer include file) ------- #if defined (BOOST_WINDOWS) # include <boost/.../qpc_timer.hpp> # include <boost/.../tgt_timer.hpp> #endif ------- and/or (in specific implementations - qpc/time_get_time_timer) ------- #if defined (BOOST_WINDOWS) namespace boost { class <windows_specific_timer> { ... }; } #endif // BOOST_WINDOWS ------- // Johan

Here attached is my last work on the timer, the qpc_timer/tgt_timer are in a file of their own now. This made me remove the time_type template argument, as on my last imlpementation the qpc / tgt timers where only template specializations of the timer class. They are now class on their own, and it's probably better this way. Can someone review ? Thank you. Philippe

On Mon, May 15, 2006 at 06:02:34PM +0200, Gerhard Wesp wrote:

Having implemented several major frameworks in C++ in which time played a crucial rule, I have a pretty firm view on the subject: No time type should include information about relative to which point it is measured.

This doesn't give arguments.

...

that the two are the same thing, but I'd argue that it would be better to make TWO types.

I strongly disagree, for the above reasoning.

Though you are theoretically correct to say that also the time as returned by -whatever- (ie, gettimeofday) is relative to some point, it isn't very practical to consider it's value relative. The concept of "NOW" seems clear to me. And "NOW" is an absolute time, not a relative one. The fact that one HAS to store/represent it as a relative time is exactly what is so confusing, and THEREFORE calls for a separate type. It makes no sense to code, Time t1 = now(); Time t2 = now(); Time t3 = t1 + t2; as the result of the addition would be dependent on the time that the *implementation* of Time is relative to (ie, 1970). But the coder in general will not care if 'now' is relative stored relative to 1970 or to 2005: he should be shielded from that. Therefore, adding Time + Time should not compile. I think these are sound argument FOR two types, and AGAINST just a single type for relative time. -- Carlo Wood <carlo@alinoe.com>

On Tue, May 16, 2006 at 01:20:46AM +0200, Carlo Wood wrote:

The concept of "NOW" seems clear to me. And "NOW" is an absolute time, not a relative one. The fact that one HAS to

Maybe Einstein would disagree... :) Another poster pointed out that t1 + t2 is a perfectly valid expression, and I have to add scalar multiplication to the requirements a time type should support. -Gerhard -- Gerhard Wesp ZRH office voice: +41 (0)44 668 1878 ZRH office fax: +41 (0)44 200 1818 For the rest I claim that raw pointers must be abolished.

For whatever datatype the "elapsed" function returns, I think we had better have istream/ostream overloads for it. The current one returns "double", which works fine with istream/ostream. The overload should return or parse secs.fracsecs in all various forms.

Interesting, but this is a change request for the date_time lib then ? Maybe there's already an ostream& operator<< for the boost::posix_time::ptime etc types, I'll have a look. Philippe

Silex wrote:

Hello

Here attached is the latest version of the boost::timer modification.

About doing the documentation I must say that QuickBook & BoostBook confused me. I understand QuickBook generates BoostBook's documentation but how to use it ?

At the moment I'm only doing the documentation in a plain text file waiting for your answers... I *think* I understood that I'm supposed to write a .qbk file, but how to then make Spirit generate the xml for BoostBook is beyond me, I'm not used to Spirit yet.

Hi Philippe - Sorry I haven't got a chance to look at this till now. First, it might be nice if you could upload a version to the vault so other people can try it out. http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=date_time Now a couple questions on the code. What is the time_duration_type elapsed() const { if(m_start.QuadPart) { LARGE_INTEGER current; if(!QueryPerformanceCounter(¤t)) throw std::runtime_error("qpc: QueryPerformanceCounter() failed"); boost::uint64_t milliseconds = (current.QuadPart - m_start.QuadPart) / m_frequency.QuadPart; boost::uint32_t seconds = milliseconds / 1000; boost::uint32_t minutes = seconds / 60; boost::uint32_t hours = minutes / 60; milliseconds = milliseconds % 1000; m_elapsed += time_duration_type(hours, minutes, seconds, milliseconds); m_start = current; } return m_elapsed; } I think this code is both inefficient and likely non-portable. As I understand it, QueryPerformanceCounter has a hardware defined resolution that can be queried by calling QueryPerformanceFrequency. QPF provides the counts per second. You should be able to use this to more simply construct the time_duration. So, for example, if QPF returned 1000 you could simply say m_elapsed += boost::posix_time::milliseconds(current-previous); I'm guessing nanoseconds might be the best duration type to use in the calculation. Thx for your effort in this area. Jeff

"Philippe Vaucher" wrote:

As I understand it, QueryPerformanceCounter has a hardware defined

...

resolution that can be queried by calling QueryPerformanceFrequency. QPF provides the counts per second. You should be able to use this to more simply construct the time_duration.

The measurement will be exact if the execution runs on single processor. On multiprocessor there's always chance that the thread moves elsewhere and the measured value will be slightly different. /Pavel

"Jeff Garland" wrote: [ QueryPerformanceCounter ]

...

The measurement will be exact if the execution runs on single processor. On multiprocessor there's always chance that the thread moves elsewhere and the measured value will be slightly different.

Yeah, isn't there something I read in the MSDN pages about giving QPC thread affinity to solve this issue? Given the number of dual core chips making their way into the world now this is certain to be a serious problem.

SetThreadAffinityMask() The tool likely needs to check presence of multiple processors, temporarily fix the affinity and then return it back to original state. If the timer will measure time on several levels of call tree only the top timer should do this to avoid expensive system calls. Another problem may be CPU that changes its frequency (Transmeta did this and some CPUs for notebooks may do as well). I think handling this would be over the top for simple timer, though. /Pavel

"Philippe Vaucher" wrote

Hello,

Here's the latest version:

http://boost-consulting.com/vault/index.php?action=downloadfile&filename=new_timer_2006-06-28.zip&directory=date_time&

I did the different correction people suggested... I'm now struggling with trying to set up QuickBook but it really lacks documentation :)

Try the Boostbook documentation for setting up the toolchain. Its quite comprehensive. (Thanks Doug Gregor). I put Quickbook.exe in my path ( actually in Boosts <dist/bin/> directory, from wherever bjam puts it when it does the boost build (or just run Bjam in the Quickbook source directory). Finally you need a Jamfile.v2 in the same directory as the timer.qbk or whatever its called. Look at similar jamfiles for Quickbook source docs for other libarries. I basically copied mine over and substituted the names from them. Invoke Bjam in that directory and you should be 'cooking with gas' as they say. Anyway its definitely worth persevering with. The whole Quickbook, Boostbook , DocBook thing is very powerful. HTH regards Andy Little

Hello, I have quickbook up and running and I'm currently doing the documentation, it goes quite well except I lose most of my time learning the quickbook format instead and sometimes I'm tempted to just screw it and write plain html instead :) But I'll resist and it seems indeed quite powerfull. My question is about where to place this new timer class, there were suggestion to remove boost::timer entirely and move it into boost::date_time, if so, where ? as it uses boost::posix_time::ptime as default argument I guessed boost::posix_timer::timer ? If it stays as boost::timer standalone lib, what do I do of the "old" boost::timer ? plain replacement ? I'll post my current documentation in a few days. Thank you for your input, Philippe

On Thu, 13 Jul 2006 23:56:08 +0200, "Philippe Vaucher" <philippe.vaucher@gmail.com> wrote:

My question is about where to place this new timer class, there were suggestion to remove boost::timer entirely and move it into boost::date_time, if so, where ? as it uses boost::posix_time::ptime as default argument I guessed boost::posix_timer::timer ?

I guess the whole component has to go through a fast track review, at least <http://www.boost.org/more/formal_review_process.htm#Fast-Track> At a first glance there are a couple of points which perplex me, for instance the auto_start/manual_start option. Also, wouldn't an std::clock() based Clock be worth having anyway? AFAICS, only a Win32 Clock is provided. What I've found with some experiments (I was writing a timer template myself) is that though std::clock() has obvious limitations, and though we are probably all waiting for this <http://david.tribble.com/text/c0xtimet.htm> the biggest problem is with those implementations (guess which one(s)? :)) that think it has to yield wall-clock time rather than process time. However for those implementation(s) one might use (guess what?) qpc_clock. It would also be useful to make a quick comparison with an implementation based on GetProcessTimes(), if this hasn't already been discussed. Don't be too formal, just a couple of sentences for us to understand :) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

if you want the timer to start immediatly when it is created of if you want to manually start it with tmr.start ().

That isn't very clear : If you want the timer to start immediatly when the object is created you use auto_start, if you want to manually start it you use manual_start and then tmr.start(). A code makes it more clear : // Timer will start automagically microsec_timer tmr; // Timer won't start microsec_timer tmr2(microsec_timer::time_duration_type(0, 0, 0), manual_start); // Start timer now ! tmr2.start(); Philippe

...

Well it thought it was pretty obvious, if you want the timer to start immediatly when it is created of if you want to manually start it with tmr.start().

Yes, I understood what the effect was :) I just wasn't sure it was a good design choice, as the manual_start mode leaves to the user's responsibility to correctly couple start/stop calls.

Hum, manual_start simply has the effect that the timer doesn't starts automatically when the object is created, nothing more. I dont really understand what's bad in that as the defaut parameter is auto_start... care to explain a bit more ? If you give me a day or two I can try and cleanup the code I already

have. I guess we could "merge" the two solutions in some way.

Sure ! Philippe

On Sun, 16 Jul 2006 14:37:18 +0200, "Philippe Vaucher" <philippe.vaucher@gmail.com> wrote:

We don't get the file as an attachment, at least on gmail. Upload to vault.

Did I say I hate the vault? :) That's why I attached unzipped text files (zip archives don't easily go through mail firewalls). They also are in the vault now, in Home/System -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

On Sun, 16 Jul 2006 16:41:41 +0200, "Philippe Vaucher" <philippe.vaucher@gmail.com> wrote:

...

They also are in the vault now, in Home/System

Hum there's something I need to understand, what you uploaded is what needs to be merged with the code I did ?

Er, no. I didn't use the word "merge" in that sense. It was meant as "we can combine the best of the two approaches" in a new design. I started working on the timers after noticing some flaws in the current boost::timer, particularly the fact that it doesn't take into account that std::clock() can fail. In the first draft of my code no boost::date_time facility was used, partly because I wanted to come up with an autonomous solution and partly because I'm a billy goat with the date-time library in general (I wanted my code to be interoperable with date-time, but not depending on it; just like you can often make a template mpl-compatible by just providing a nested "type" typedef). Well, so far with history :) The main idea in my code is that "elapsed timers" are all about *durations*, and do not need to involve *time points*. A duration is not affected by what your system time is, whether you switched to DST or things like that. That's a key point. The code I provided added the interface that Jeff Garland proposes on the wiki page to the code I had already written (secondary point: there are some comments about the interface itself in the code). Basically: * 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() As you see, just a typedef and two functions. Note that the source doesn't need to know about "pauses" and "resumes"; I find that very close to the actual logic of any involved physical devices: you don't want to really pause, say, a NTP server, even if you could. Pauses, etc., are handled by the elapsed timer template class, which offers Jeff's interface. Other two ideas which are IMHO worth considering are: * [std::clock() specific ] when you first invoke std::clock() you could actually be between two ticks. Since the time between two consecutive ticks can be as long as one second or more, that's not negligible, and here's the point of the synchronized start: it waits until the clock really ticks. Secondly, elapsed_min() is actually what c_clock_precision() computes, at run-time, and cannot be inferred from CLOCKS_PER_SEC, which is a mere conversion factor (posix requires it to be fixed at 1,000,000 but that doesn't mean you can measure millionth of seconds) * use of exceptions: clock device classes, and thus elapsed_timer<T> can provide strong exception guarantees; and, yes, std::clock(), GetProcessTimes, etc. can all actually fail in practice. 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. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

On Sun, 16 Jul 2006 23:09:29 +0200, "Philippe Vaucher" <philippe.vaucher@gmail.com> 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 ]

On Mon, 17 Jul 2006 13:08:28 +1000, Martin Slater <mslater@hellinc.net> wrote:

...

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.

I think it should at least detect SpeedStep and fail or fall back to a possibly lower precision but stable timer. IMO without this its unusable except for very basic performance tests.

Actually there are some usages where one wants the cycle count, rather than the elapsed time, so I was thinking to provide a cpu_cycle_timer (that's not a "timer" in the strict sense but seems to fit in the framework) anyway. Of course the elapsed time is just the cycle count divided by the frequency, if the frequency is fixed. I'll see in the Intel docs if it is possible to detect SpeedStep activation (you won't believe what the processor is actually able to tell you :)) or if other solutions exist. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

On Tue, 18 Jul 2006 23:54:11 +1000, Martin Slater <mslater@hellinc.net> wrote:

[I'll see in the]

...

Intel docs if it is possible to detect SpeedStep activation (you won't believe what the processor is actually able to tell you :)) or if other solutions exist.

I hope your successful ;)

Thanks. It's actually not difficult, and fascinating, so I'm well willing to do it. I just hope there's no drop of interest here, as that will likely make me move on to something else.

A good guide to pc timers you may not have seen is here http://www.mindcontrol.org/~hplus/pc-timers.html which has some good ideas for a stable timer on windows x86

Thanks, I'll have a look later. I've to say the Bible is quite good too (I mean the Intel document :)). Basically the processor does everything for you, you just need to ask and take some extra care for cache misses and other issues. The basic idea (sorry for any typos) is: __forceinline __int64 cpu_cycle_count() { __int64 prelim; __int64 actual; // pentium or above required asm { cpuid rdtsc lea ebx,prelim mov [ebx],eax mov [ebx+4],edx <repeat the above a few times...> cpuid rdtsc lea ebx,actual mov [ebx],eax mov [ebx+4],edx } // basic cache miss protection, but // something better can be done return prelim < actual? prelim : actual; } -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

I think it should at least detect SpeedStep and fail or fall back to a possibly lower precision but stable timer. IMO without this its unusable except for very basic performance tests.

How many are affected by Speedstepping exactly ? Isn't that only for laptops ? Doesn't mean we shouldn't take care of it, but I'd like to know the practical implications :) Philippe

...

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?

Hum, where we spoke about the available timers on windows (QueryPerformanceCounter, etc) where no one mentionned GetProcessTimes or when we spoke about the design problem of timers that aren't based on time, but nevermind :) What counts is that I now can modify my code with a better design. I'll post code change in some days. Philippe

I'd also like you and other participants to try answering to points marked with "gps" in the source code.

------------------------------------------------------------------------------ // gps - temporary helper void global_throw_helper(const char* msg) { throw std::runtime_error(msg); } We'd just use boost::throw_exception here. ------------------------------------------------------------------------------ template <typename T> struct clock_device_traits { // gps TODO //has_synch_start? }; I think maybe we'd have a clock_device_base that is inherited by every clock_devices, that would be templated on the time type and typedefs time_duration_type, so the elapsed timer that accepts a clock_device can also typedef those. ------------------------------------------------------------------------------ // gps - do we need these two typedefs? // typedef TimePoint time_type; // typedef typename Device::time_point_type time_point_type; I think it's convenient, I even propose we do : typedef ClockDevice clock_type; typedef typename ClockDevice::time_type time_type; typedef typename time_type::time_duration_type time_duration_type; So the user can know the clock_type for when he uses a convenience typedef like "typedef timer<microsec_device> microsec_timer;" which is likely to be declared in the library. ------------------------------------------------------------------------------ void resume(); // gps - what if you call twice pause, twice resume consecutively?? // bool is_running() const // gps - add this?? // gps: I see no point in having clear_elapsed() I think calling twice pause or resume should have no effect. Not doing so is too error prone imho. is_running() sounds like good idea tho I can't really think of a use for it so maybe not if that means having to add a data member to implement it. I think reset() was good, why don't you see a point for it ? If you want to time two consequent things individually and use the same object ? ------------------------------------------------------------------------------ template <typename D> void elapsed_timer<D>::start() // may throw { restart(); // this is just the same as restart(); // maybe we can come up with a common name -gps } I think calling start() twice should not reset it, I think restart should call reset() then start(). ------------------------------------------------------------------------------ template <typename D> void elapsed_timer<D>::pause() { // throw if(!is_running) ?? - gps duration += device.elapsed(); is_running = false; } Again, I think pause should pause if not already paused, otherwise do nothing, like the implementation I uploaded based on Jeff's design. ------------------------------------------------------------------------------ // Specific Clock Devices // gps - should this be copyable? Why not ? Anyway, I'll skip the other points as it's more implementation detail it seems, but I'll explain more how I think the timer should behave : - Calling start() should start if not already started, subsequents calls to start() do nothing. - Calling pause() should pause if not already paused, subsequents calls to pause() do nothing. - Calling resume() should start the timer again at the time duration the timer was if not already start, subsequents calls to resume() do nothing. - Calling reset() should reset the current elapsed time to 0. - Calling restart() should call reset() then start(). - Calling elapsed() should return the current timer value. I also think your interface lacks the hability to set the initial time offset, which could be usefull in some situations. Ok, it's a start ! I'll see if I can comment on the other gps points in a near future. Philippe

I'm afraid I didn't make my point clear. It wasn't about supporting BOOST_NO_EXCEPTIONS (which I'd like not to --it would require in any case a re-examination of the code, as I didn't design it with that in mind). It was to discuss what type of exception(s) we want to throw and what additional info, if any, we want to add to exception objects. Maybe Boost.Date-Time already has a well thought-out solution.

Then I have no clue for this :) I'm not sure we are understanding each other. The main advantage of my

solution is that it doesn't logically imply/require any usage of a "time point". That means: if you measure while someone (or some program/service) adjusts the system clock, or a DST switch happens, you are *not* affected.

We are, it's just I copy pasted too much for my example. My point was mostly for the clock_device and the time_duration_type that should be able as typedefs.

------------------------------------------------------------------------------

...

void resume(); // gps - what if you call twice pause, twice resume consecutively?? // bool is_running() const // gps - add this?? // gps: I see no point in having clear_elapsed()

I think calling twice pause or resume should have no effect.

Maybe.

It's not a media player where the interface tries to be friendly and pressing pause toggles play/pause, it's a timer where pause means pause no ?

Not doing so is

...

too error prone imho. is_running() sounds like good idea tho I can't really think of a use for it so maybe not if that means having to add a data member to implement it.

Basically you are saying you are in doubt. I was too, hence my question (incidentally: what's your concern with an additional data member??).

I'm just explaining why it's a doubt yes. The concern about an additional data member is silly but it's something about if the feature is never used and the object gets bigger then it's just lose-lose. But after more thinking is_running also helps the implementation clarity so I think we'd add it.

I think reset() was good, why don't you see a point for it ? If you want to

...

time two consequent things individually and use the same object ?

restart()?

Restarts resets and starts again, it's two actions. You don't provide the 1st one.

------------------------------------------------------------------------------

...

template <typename D> void elapsed_timer<D>::start() // may throw { restart(); // this is just the same as restart(); // maybe we can come up with a common name -gps }

I think calling start() twice should not reset it, I think restart should call reset() then start().

Honestly, did you really look at my code? Looks like you keep thinking in terms of yours. I had no concept of reset() at all.

Maybe I wasn't clear: I said your interface lacks the reset() concept, and that restart() should be reset() then start().

Again, I think pause should pause if not already paused, otherwise do

...

nothing, like the implementation I uploaded based on Jeff's design.

I see. But the point is: if the user code happens to call pause() twice without intervening restarts, is that a sign of a logical error? It's similar to set a pointer to null after a delete, to ensure a double deletion is harmless. It may make you feel safer, but in practice it hides programming errors by eating their immediate ill effects.

For me it's not an error. If the user wants to do cout.set_precision(23); cout.set_precision(23); it's his problem :) What we could do is return a bool that'd tell pause() success tho.

------------------------------------------------------------------------------

...

// Specific Clock Devices // gps - should this be copyable?

Why not ?

It's a choice, and I annotated it to make sure I gave it another thought at the end of the work.

It's usually a choice driven by the fact that copying it might be harfmul or imply extra design decisions (resources etc) but here I don't see why it wouldn't be.

I also think your interface lacks the hability to set the initial time

...

offset, which could be usefull in some situations.

Care to explain?

For the "I want to create a timer that starts with 100 second elapsed already" kindof requests. Philippe