Jeff Garland wrote:
I'll be happy to replace the current microsec_clock implementation as long as you can deal with rollover and multi-threading.
I guess it depends on what you're using the timer for. I really don't mind either way as long as the behaviour is well-documented. When I'm using a "microsecond timer", it is because I want to measure short intervals, not long ones. But perhaps there should be clearer ways of specifying the precision/accuracy/resolution trade-offs desired? Philippe Vaucher wrote:
This also raise another question, if we chose to implement microsec_timer with QPC, what will we name the timer implemented with posix_time::microsec_clock (which is just a typedef for date_time::microsec_clock) ?
On second thought, apparently Java calls their QPC implementation is called "nano" instead. Perhaps we could use that terminology as well? On the QPC implementation, someone here (http://channel9.msdn.com/ShowPost.aspx?PostID=156175) suggested that it's might be good enough to call SetThreadAffinityMask() to cpu 0 and then set it back to the old value when done. I have no idea what type of overhead it imposes though. For more robust QPC implementations, the following two links have some more ideas. As Jeff suggests here, this is not new but this is the first time I've really looked seriously at the issue as QPC always worked well enough for my profiling purposes. http://msdn.microsoft.com/msdnmag/issues/04/03/HighResolutionTimer/ http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323& Regards, -Edward