On Tue, Nov 18, 2008 at 1:40 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

As you have started to add other features in addition to the ratio+chrono libraries, I was wondering if in addition to procees CPU usage you can add thread CPU usage. What about CPU% for process and a threads?

The need that comes up over and over is for wall-clock time, and per process cpu user and system time. And that's what POSIX times() and equivalent Win32 functions have provided for many years. On some operating systems there are lots of other times available, but I have no idea if these other times have portable equivalents. Did you have something specific in mind, or was it a theoretical question?

Are these in the scope of your library?

process_timer gives real, user and system times. What about iowait?

It would be useful if generally available. Ideas for how to measure on Windows and POSIX would be appreciated. --Beman

On Nov 18, 2008, at 5:28 PM, Beman Dawes wrote:

On Tue, Nov 18, 2008 at 7:56 PM, Howard Hinnant <hinnant@twcny.rr.com> wrote:

...

It seems a shame that process_clock does not really meet the proposed standard clock requirements (its now() doesn't return the time_point). That being said, I can see why you didn't. This clock really has 3 distinct "time points" and one needs to set each of those three with one system call.

Yep, and I couldn't see any practical downside to the proposed now() signature. Other than that, I did try to make process_clock conform.

...

If one wanted, one could easily create a user_time_clock wrapper around processor_clock to adapt it to the standard clock requirements if needed.

Yes. Interesting. That hadn't occurred to me.

...

Just for general education purposes, here's a portable processor- time clock (just to show how easy it is to build a custom clock):

#include <ctime> #include <cstdio> #include <chrono>

class processor_clock { public: typedef std::clock_t rep; typedef std::ratio<1, CLOCKS_PER_SEC> period; typedef std::chrono::duration<rep, period> duration; typedef std::chrono::time_point<processor_clock> time_point; static const bool is_monotonic = true;

static time_point now() {return time_point(duration(std::clock()));} };

int main() { processor_clock::time_point t1 = processor_clock::now(); processor_clock::time_point t2 = processor_clock::now(); std::printf("%g seconds\n", std::chrono::duration<double>(t2-t1).count()); }

Output:

4e-06 seconds

I'll add that to the docs. The clock requirements are really nice; they are totally minimalist, yet provide all the functionality needed.

Did you look at the boost/chrono/timer.hpp header? It supplies a timer template to create a timer from any clock. I'd be curious to get your reactionsl

You caught me napping. :-) It looks like a nice utility. Comments: * It looks like you would like to see a standard overload of now: static time_point now(); // might throw static time_point now(system::error_code& ec); // nothrow Please feel free to submit an issue on this. That being said, I just reviewed several POSIX time functions and it really looks like they just don't fail. I know the ones on darwin don't. I know the C standard (and POSIX) say things like:

The value (time_t)(-1)is returned if the calendar time is not available.

This strikes me as a situation where the function either never fails (it is supported), or always fails (it isn't supported). I'm not positive that the error_code overload is warranted for this situation. My preference would be that if the platform doesn't support system_clock (for example) that code using system_clock not compile instead of always fail at run time. Thus there would be no reason to check the error code (or expect an exception from now()). Currently the only thing [time] has to say on this subject is in [time.duration]/5:

Requires: Members of duration shall not throw exceptions other than those thrown by the indicated operations on their representations.

Perhaps we should widen that sentiment to time_point and clock::now(). * I've written utilities like this in the past. I've always put the functionality of elapsed() plus a print statement in ~timer() so that use cases looked like: int main() { timer _("Entire Program"); // do stuff } Output: Elapsed time for Entire Program was 15 seconds. I've had start(), and I think I probably renamed elapsed() to something like report() (due to the printing functionality), and I also had stop(). If report() was called prior to ~timer(), without another start(), then ~timer() did not report(). There was also a way to construct timer() without implicitly calling start(). Perhaps an elapsed() would have been a good addition to what I've done in the past. Wrist watch timer's I've seen have two versions of elapsed: 1. Get the elapsed time and keep the timer going. 2. Get the elapsed time and stop the timer. Maybe #1 could be handled by elapsed(), and #2 could be handled by having stop() return the elapsed time? There are disadvantages to the way I've done it (auto-report): One doesn't always want a print out, and if one does, one doesn't always want it to go to the same stream. For me this was always a debugging utility and thus such matters weren't that important. Since it did "auto-report", I really liked being able to distinguish among multiple timer outputs: void f1() { timer _("f1"); // ... } void f2() { timer _("f2"); // ... } int main() { timer _("main"); f1(); f2(); } Output: Elapsed time for f1 was 3 seconds. Elapsed time for f2 was 2 seconds. Elapsed time for main was 5 seconds. * I can't imagine ever using any clock but std::chrono::high_resolution_clock for timer. Even if high_resolution_clock isn't monotonic, I'm usually using this utility in a debug/test context and know better than to go resetting system clocks during a test. On OS X, high_resolution_clock will be monotonic (if I have anything to say about it). * Here's one way to get the total time spent in f1(), as opposed to the time per call: void f1() { static timer t("Total time spent in f1"); t.start(); // first start is redundant and ignored // ... t.stop(); } One might write a timer-wrapper which put the t.stop() in ~wrapper() (and took a timer& in its ctor and started it). void f1() { static timer t("Total time spent in f1"); timer_start_stop _(t); // ... } class timer_start_stop { timer& t_; public: explicit timer_start_stop(timer& t) : t_(t) {t_.start();} ~timer_start_stop() {t_.stop();} timer_start_stop(const timer_start_stop&) = delete; timer_start_stop& operator=(const timer_start_stop&) = delete; }; -Howard

On Nov 19, 2008, at 6:29 AM, Beman Dawes wrote:

...

That being said, I just reviewed several POSIX time functions and it really looks like they just don't fail. I know the ones on darwin don't.

The POSIX clock_gettime function can fail with [EINVAL] "The clock_id argument does not specify a known clock."

The Windows QueryPerformanceCounter/QueryPerformanceFrequency functions can fail "if the installed hardware does not support a high-resolution performance counter".

Ok, I had overlooked these run time failure modes. So the ec& overload looks much more appealing to me now.

...

* I've written utilities like this in the past. I've always put the functionality of elapsed() plus a print statement in ~timer() so that use cases looked like:

int main() { timer _("Entire Program"); // do stuff }

Output:

Elapsed time for Entire Program was 15 seconds.

Sure. The name of the type is "run_timer" and it is declared in header <boost/chrono/process_times.hpp>

I had overlooked run_timer (I didn't do a proper review). <nod> this looks quite nice. Very nice formatting capability and streaming options.

Howard, I'm pressed for time so only skim read the remainder. My quick impression was that my proposed decomposition into clocks (some provided by the std lib, some by Boost or users), raw timers, and then elaborated timers derived from raw timers provides all the functionality you mention in a easy to use package, yet allows users to avoid functionality they don't need for a particular application.

Agreed. The only functionality I'm not sure I see is the ability to get the total time in a function across multiple calls: void f1() { static run_timer t("Total time spent in f1 was %r seconds."); // sum times over many calls to f1() t.start(); // first start is redundant and ignored // ... t.stop(); // I don't see this functionality } The stop() functionality would add more complexity/data members to run_timer (like a "running duration" which sums previous start/stop sequences, and a count of start/stop sequences so an average can be reported), so might conceivably be another class derived from run_timer, possibly written by the client instead of by boost. Not sure, I haven't tried that route. And it may be that there isn't a sufficiently large market for this functionality for the boost lib to worry about. I'm just relating my experience. Nice work Beman. I know what you have will be greatly appreciated by the boost community. -Howard

On Wed, Nov 19, 2008 at 1:42 PM, Michael Marcin <mike.marcin@gmail.com> wrote:

Shouldn't the implementation use boost::throw_exception rather than throw?

Yes, and originally it did. But there was an issue with Intel 11.0 so for the moment the implementation is just plain throwing. I've stuck a TODO list near the front of chrono.hpp to track issues so they don't get forgotten.

In the past I've seen QueryPerformanceCounter give incorrect results, especially with SpeedStep processors on laptops. This was many years ago and might have been fixed by service packs and drivers.

Yeah, I'm aware that QueryPerformanceCounter is widely considered to be problematical. I'm still in the phase of development where getting the interface/tests/docs complete is more important than the implementation.

Typically you check the results of QPC against GetTickCount to see if the results are reasonable. http://support.microsoft.com/kb/274323

I've also heard of problems with QueryPerformanceCounter in multi-processor systems.

I know some people SetThreadAffinityMask to 1 for the current thread call their QueryPerformance* functions then restore SetThreadAffinityMask. This seems horrible to me because it forces your program to jump to another physical processor if it isn't already on cpu0 but they claim it worked well in practice because they called the timing functions infrequently.

I'm wondering if there are really two separate needs; a high-precision low-overhead timer that may give incorrect results if not used carefully, and an always reliable timer that has more internal overhead and may have lower precision.

In the past I have chosen to use timeGetTime with timeBeginPeriod(1) for high resolution timers to avoid these issues.

I wasn't aware of that API. I'll take a look. Thanks for the comments, --Beman