[SDL] SDL_GetTicks() goes backwards - blame assigned

[Daniel Phillips]

On Wednesday 25 December 2002 10:50, Ryan C. Gordon wrote:
> > Second moral: Dividing the time result into two longs, one part with
> > microseconds, was an incredibly stupid design decision on the part of the
> > glibc people and just had to bite sometime.  Long longs are not that
> > scary, people.
>
> ...but they ARE expensive on many platforms, especially at the granularity
> of a "tick".

Actually, since time doesn't fit into 32 bits, it's generally cheaper to use 
long long than two ints.  For example, a 64 bit by 32 bit division costs the 
same as 32 by 32.  Anyway, the difference is miniscule, I guarantee you won't 
be able to measure it in a running system.

> > Recommendation for SDL: USE_RDTSC should be the default.  It's more
> > reliable and faster, and where exactly are you going to find a 486
> > running SDL?
>
> You would be surprised about the 486 thing, but don't forget the PowerPC,
> Sparc, ARM, and probably at least 10 other CPUs that SDL is known to run
> on.
>
> If you find the bug in glibc, let me know...I'm genuinely curious as to
> why that happens (and why rdtsc doesn't demostrate this problem).

If you find a 486 system with SDL on it, please let me know ;-)  Actually, 
the only real issue I can see with TSC is that you want to be sure it always 
reads from the same cpu (cpu0, say) on a multiprocessor system.  I don't know 
how or if that's enforced, but it obviously needs to be.  What SDL should do 
by default is use TSC if it's available, so this is my ammended 
recommendation.  I'll submit a patch in due course, if nobody beats me to it.

Also, SDL *should* include code to detect and filter out time reversals.  
We're talking about 4 lines of code here.  The only argument against that 
would be: if you cover up the error it reduces the motivation to fix it.  SDL 
can log the number of time reversal events into a static variable:

  SDL_errorcount_timereversal++;

We're talking maybe 30 bytes of new code altogether, so there's no argument 
for not doing this.  This will not be the last time somebody runs into a 
clock that jumps backwards.

--
Daniel