On 2011-08-14 23:22:38 +0200, Gordon Woodhull said:

On Aug 14, 2011, at 3:40 PM, Kraus Philipp wrote:

...

timer t; run_algorithm; std::cout << t.elapsed << std::endl;

Boost.Timer has some problems, I've seen it measure CPU time instead of wall time on some platforms and I'm not sure about the accuracy.

I don't know about the MPI timer, but I would go with Chrono until Stopwatches is out.

Do you know anything about "CPU cycling"? Can I detect the CPU cycles which are elapsed during runtime? I need a "time value" for detecting runtime only. Thanks Phil

On 08/14/2011 04:45 PM, Gordon Woodhull wrote:

On Aug 14, 2011, at 5:26 PM, Philipp Kraus wrote:

...

Do you know anything about "CPU cycling"? Can I detect the CPU cycles which are elapsed during runtime? I need a "time value" for detecting runtime only.

Hmm, sorry I've only heard of low level assembly ways of doing that. Doesn't sound very platform-independent! ;-)

Cheers Gordon

It's not Boost, but you can have a look at PAPI ( http://icl.cs.utk.edu/papi/ )

If you are on an x86 platform, you can use the "rdtsc" assembly instruction to obtain processor tick counts. When I needed accurate timing, I created a function to wrap around "rdtsc", a Timer class with an API something like class Timer { public: void start(); void stop(); ulonglong elapsed(); }; Then created class using the Guard idiom around that: class AutoTimer { public: AutoTimer(Timer& t) : t_(t) { t_.start(); } ~AutoTimer() { t_.stop(); } private: Timer& t_; }; Becomes very easy to time segments of code: ... Timer t1; ... { AutoTimer a(t1); ...do stuff... } One can also continue to start/stop a Timer, thus accumulating total tick counts. Conversion of tick counts back to real time is done external to any of these classes.

On Mon, Aug 15, 2011 at 9:07 AM, Lars Viklund wrote:

On Mon, Aug 15, 2011 at 08:54:09AM -0500, Chris Cleeland wrote:

...

If you are on an x86 platform, you can use the "rdtsc" assembly instruction to obtain processor tick counts.

Note that many processors do not synchronize such low-level tickcounts between cores or packages, so unless you have thread affinity for a single particular one, you're in deep water unless you know your hardware does not exhibit these kinds of behaviours.

Good point; thanks for pointing that out. In my case, I have thread affinity, guaranteed by other software requirements that pre-date the timing, so I'd forgotten.