On Thu, Feb 27, 2003 at 12:52:24PM -0500, Jeff Urlwin wrote:
> Too many questions :)
:)
> > What's your operating system? (and perl -V output?)
> > And, out of interest, what's the spec of your machine?
> > (cpu/memory etc)
>
> Windows XP service pack 1.
> Pentium 4 (mobile), 2.2 Ghz
> 1 GB RAM
>
> > What does this say:
> > $ perl -MDBI=dbi_time -e '$a=dbi_time; 1 while (dbi_time eq
> > $a); $a=dbi_time;++$c while (dbi_time eq $a); warn
> > "$a\n$c\n".dbi_time' 1046365974.8218 1
> > 1046365974.82187
>
> I changed it to a separate script since I'm under windows and the
> command shell is a pain, but I don't think I changed semantics on it:
>
> use DBI qw(dbi_time);
> my $a=dbi_time;
> 1 while (dbi_time == $a);
> $a=dbi_time;
> ++$c while (dbi_time == $a);
> warn "$a\n$c\n".dbi_time;
>
> With eq
>
> 1046367427.69059
> 1058
> 1046367427.7006
>
> > The 1 in the middle line is often missing, meaning that
> > dbi_time produces a different value faster than the loop
> > loops. If I change the "eq"'s to "==" then I can't even get a
> > 1 to appear.
> >
>
> With ==
>
> 1046367479.27631
> 5547
> 1046367479.28632 at t.pl line 7.
Seems the problem is that Windows has a lower 'hi res' time resolution.
My machine only gets round the loop once between 'ticks' of the time
but your can do thousands of loops.
[...later...] Ah, I could have saved us the bother if I'd looked
at the code...
static double
dbi_time() {
# ifdef HAS_GETTIMEOFDAY
struct timeval when;
gettimeofday(&when, (struct timezone *) 0);
return when.tv_sec + (when.tv_usec / 1000000.0);
# else /* per-second is almost useless */
# ifdef _WIN32 /* use _ftime() on Win32 (MS Visual C++ 6.0) */
struct _timeb when;
_ftime( &when );
return when.time + (when.millitm / 1000.0);
# else
return time(NULL);
# endif
# endif
}
So windows _ftime only has millisecond resolution (whereas unix
gettimeofday has nanosecond resolution, at least in theory).
Okay, I'll add the loops to the tests and document the lower resolution on
Windows.
Could you do some experimentation for me to determine the smallest
numer of loops that avoid the problem on your system? I'll then use
some multiple of that as a safety margin. (Just email me direct and
include a copy of your edited test files. Thanks.)
Tim.
