[sldev] QueryPerformanceCounter()

[Thomas Rowland]

Available to all via google 'rdtc' is;
http://www-unix.mcs.anl.gov/~kazutomo/rdtsc.html
Which also gives a PPC equiv. function, and is as good as any.
There are energy saving CPU clock frequency changes on some systems.
Hopefully this would be negated by the intensity of CPU load prior to the
call.
Perhaps it would be prudent to also attempt a rough 'call overhead'
measurement & adjustment.
 
-----Original Message-----
From: sldev-bounces at lists.secondlife.com
[mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Dzonatas
Sent: 31 May 2007 10:35
To: sldev at lists.secondlife.com
Subject: Re: [sldev] QueryPerformanceCounter()



Paul TBBle Hampson wrote: 

Now you're looking at using it for Linux,

The performance counter is a bonus to finish the port of the frequency
detection.

Here is my suggestion to wrap up rdtsc for x86_64. (despite the format)

 __asm__ volatile ( "
"    rdtsc                               \n"
"    shlq $32, %%rdx              \n"
"    orq %%rax, %%rdx          \n"
: "=rdx" (start) :: "rax" );

This avoids an extra cache hit with two movl's (like in the example
provided).

I do not have immediate access to test this on 64bit Linux at this time. If
I can get a confirmation it works, that will be helpful, and I'll update the
patch.

I could still use "=A" here, but after I read different articles on its
usage I decided its best not to confuse it for readability. For example,
this  could work for both 32 bit and 64 bit

 __asm__ volatile ( "
"    rdtsc                               \n"
#if defined(_x86_64_)
"    shlq $32, %%rdx              \n"
"    orq %%rdx, %%rax          \n"
#endif
: "=A" (start) :: "d" );


Back to QueryPerformanceCounter()...

It is helpful to have a consistent port of the frequency detection just in
case we want to crunch the numbers.


-- 



No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.4/825 - Release Date: 30/05/2007
15:03




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/7865842a/attachment.htm