|
Home > Archive > Unix Programming > July 2006 > CPU timestamp and 1 second relation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
CPU timestamp and 1 second relation
|
|
| Gustavo Rios 2006-07-19, 7:25 pm |
| I have the following function that returns the number of CPU ticks:
typedef unsigned long long xadk64_t;
void
apx_rdtsc(xadk64_t * const t)
{
__asm__ __volatile__ (".byte 0xf;.byte 0x31": "=A"(*t));
}
How could i know the number of CPU ticks per second for a given
processor?
Thanks a lot for your time and cooperation.
Best regards.
| |
| davids@webmaster.com 2006-07-20, 7:51 am |
|
Gustavo Rios wrote:
> I have the following function that returns the number of CPU ticks:
>
> typedef unsigned long long xadk64_t;
>
> void
> apx_rdtsc(xadk64_t * const t)
> {
> __asm__ __volatile__ (".byte 0xf;.byte 0x31": "=A"(*t));
>
> }
>
> How could i know the number of CPU ticks per second for a given
> processor?
Read the tick count, wait ten seconds, read it again, subtract, divide
by ten.
DS
| |
| Casper H.S. Dik 2006-07-20, 7:51 am |
| "Gustavo Rios" <rios.gustavo@gmail.com> writes:
>I have the following function that returns the number of CPU ticks:
>typedef unsigned long long xadk64_t;
>void
>apx_rdtsc(xadk64_t * const t)
>{
> __asm__ __volatile__ (".byte 0xf;.byte 0x31": "=A"(*t));
>}
>How could i know the number of CPU ticks per second for a given
>processor?
You can't and the above code does not give you anything you can
reliably use, specifically not in the case of power management
and multiple CPUs.
Use the system's specific timers such as gettimeofday() or
gethrtime().
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| davids@webmaster.com 2006-07-20, 7:24 pm |
|
Casper H.S. Dik wrote:
>
[vbcol=seagreen]
[vbcol=seagreen]
> You can't and the above code does not give you anything you can
> reliably use, specifically not in the case of power management
> and multiple CPUs.
Well, it depends upon what information you are looking for. If you want
to know how many clock ticks have passed, the code is very useful. If
you want to know how much wall time, not so much.
You are correct that SMP machines with unsynchronized TSCs will be a
problem. Also, of course, this will only work on Pentium-class machines
that have a TSC.
However, this is extremely useful for measuring how many clock cycles a
chunk of code takes on machines where it is known to work.
DS
| |
| Gustavo Rios 2006-07-21, 1:29 am |
| Let me refrase the question:
What is the low-level resource upon which gettimeofday is based on?
I believe it needs a precise way of account microseconds for instance!
How could i access those resource directly?
davids@webmaster.com escreveu:
> Casper H.S. Dik wrote:
>
>
>
>
> Well, it depends upon what information you are looking for. If you want
> to know how many clock ticks have passed, the code is very useful. If
> you want to know how much wall time, not so much.
>
> You are correct that SMP machines with unsynchronized TSCs will be a
> problem. Also, of course, this will only work on Pentium-class machines
> that have a TSC.
>
> However, this is extremely useful for measuring how many clock cycles a
> chunk of code takes on machines where it is known to work.
>
> DS
| |
| Rick Jones 2006-07-21, 1:20 pm |
| Gustavo Rios <rios.gustavo@gmail.com> wrote:
> Let me refrase the question:
> What is the low-level resource upon which gettimeofday is based on?
That is platform specific. For x86 (well AMD64 and EMT64 at least) I
think there are a couple of choices an OS can use, each with different
resolutions, accuracies and trade-offs.
And then when you start talking about other platforms...
rickjones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
|
|
|
|
|