On 4/12/07, Brandon, Nicholas (UK) <[EMAIL PROTECTED]> wrote:
> > You used to be able to compile with -DVDBE_PROFILE=1 to enable some
> > special assembly-language instructions that would use
> hi-res timers on
> > ix586 chips to provide the cycle counts needed to execute each
> > instruction in a VDBE program. But I haven't used that feature in
> > years so I don't know if it still works or not.
>
> If you are talking of the "rdtsc" instruction, then to work
> with current dual core CPUs the test must be "pinned" to a
> single CPU, or you could be reading TSC values from different CPU's.
>
> Other than that, as long as the code works on a "single-core"
> CPU, it should work on newer ones.
>
> Off course, there is that word: "should" ;-)
I would add that if using windows I recommend using
QueryPerformanceCounter() instead of "rdtsc" as this function/call
already handles the above mentioned issue which affects
multiprocessor/multicore systems. In a previous job I did some
performance metrics since I presumed it would be slow but remember being
pleasantly surprised that it was as fast (circa 4 clock cycles to
retrieve and store in integer) as using assembler code. This was using
VS C++ 2003 compiler.
I'm not aware of a similar call in Unix
The "standard" similar calls on Linux are gettimeofday() and
clock_gettime(). But they require (at least last time I checked) a
system call, so maybe not as light as the windows call (I remember
some talk for the new linux kernels to have a faster way of fetching
the "timeofday" value, but don't know how that ended).
On the other hand, they are usually enough, because when measuring
times from userspace you already have some degree of uncertainty, like
having a higher priority process slowing down the app you are running.
I seem to remember something about QueryPerformanceCounter() not
taking into account things like the new thermal management features of
modern CPUs (like dynamic frequency scaling) and could give different
results on different CPUs (the motherboard can include a high-res time
source, but many don't, and some are just too slow to fetch a value).
Regards,
~Nuno Lucas
Regards
Nick
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
