Light Speed Socket Connections

[Bengt Richter]

On 12 Jul 2001 20:59:26 +0300, Erno Kuusela <erno-news at erno.iki.fi> wrote:

>In article <3b4d6184.1698299906 at wa.news.verio.net>, bokr at accessone.com
>(Bengt Richter) writes:
>
>| For accurate timing, time.clock()
>| is recommended, I believe:
>
>[...]
>
>the docs recommend it, but on unix time.time() is far better
>
>time.clock() tries to measure "cpu time" instead of "real time"
>there, which results in terrible resolution. time.time() maps
>to gettimeofday(2).
>
>  -- erno

On my boxes, I know I have pentiums where it's ok, and I've
been doing C/C++ so here is what I've used. It gives very
good resolution ( 1 cpu clock at your CPU rate ): Executing
the instructions and storing the numbers takes a few cycles,
but I seem to remember 23 cycles minimum for something I did.
At my 300mhz, that was about 77 nanoseconds. So you just
substract that out when you time something ;-)

// for linux
typedef unsigned long long u64;

inline u64
getTick64() {
     u64 ticks;
     asm volatile ("rdtsc" : "=A"(ticks));
     return ticks;
}

This will get you an accurate tick count in a real hurry ;-)
What I do is save them raw, and convert to seconds after
computing the deltas. You can do the same on windows with

//for win32
#include <basetsd.h>
typedef UINT64 u64;

inline u64 getTick64()
{
   __asm
   {
	rdtsc		; puts counter in eax,edx
   }
}

Of course, this doesn't directly do you a lot of good
in Python, but I could see a useful extension using it,
building in proper checks for rdtsc availability.

NOTE WELL: THE ABOVE CODE PRESUMES YOU HAVE A PENTIUM THAT
SUPPORTS RDTSC !!

You can check with a bit that comes back from the cpuid
instruction. But this is the reason for using the windows
QueryPerformanceCounter API instead of going to the hardware
direct. Maybe there should be such an API on unix.
I'll be someone has done it. For PC's it's the same hardware after all.