[erlang-questions] System timers, now/0, and instrumentation

[Amy Lear]

On Tue, May 24, 2011 at 11:45 PM, Richard O'Keefe <ok@REDACTED> wrote:

>
> On 25/05/2011, at 7:09 AM, Jack Moffitt wrote:
> > QueryPerformanceCounter() is pretty readily available as far as I
> > remember. Here's something Google brought up for implementing
> > microsecond timers with it:
> > http://www.decompile.com/cpp/faq/windows_timer_api.htm
>
> Er, there's a problem with the performance counters, isn't there?
> now() is supposed to give you a clock, something that ticks
> regularly.
> The performance counters count events in the CPU, and today's
> power-sensitive CPUs do things like scaling back the CPU clock
> frequency when they think they aren't busy.
>
> I know people keep telling me that time monitoring using cpu
> cycle counters doesn't work any more; I can't say of my own knowledge
> whether they are right.
>

According to msdn, QueryPerformanceCounter() is the solution to problems
like RDTSC slipping in power management (
http://msdn.microsoft.com/en-us/library/ee417693%28v=vs.85%29.aspx circa
2005), but some later discussions (
http://www.red-gate.com/supportcenter/Content?p=ANTS%20Performance%20Profiler&c=ANTS_Performance_Profiler\knowledgebase\app_speedstep.htm)
suggest that newer power management techniques (such as AMD
cool'n'quiet)
could defeat the efforts of that timer to maintain a steady beat. It's hard
to tell if that has been addressed by Microsoft or not since then.

I'm really at a loss as to what the right solution here could be. I have
trouble imagining there isn't one, but I'm not well-versed enough in the
architecture to know where else to look.

I do know that right now there is a higher resolution timer available than
what now/0 uses, but I'm not clear on what the performance penalty of
os:timestamp/0 is in comparison, and I wouldn't know how to properly measure
it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110525/60551021/attachment.htm>