[Shootout-list] timer problems

[Brandon J. Van Every]

Bengt Kleberg wrote:
>
> sure it is somebody-else's-problem. brents, in this case. :-)

Guffaw.

> how do you stand on the subject of having to check the timers all the
> time during the test? will that not influence the test result? ie, a
> language with fast timer access will get better score that a language
> with slow timer access.
> which is ok for a timer test, but this is a thread spawn test.

Hm, I thought I'd gotten rid of the 'guess N' problem, but I guess I
didn't.  :-)  You'd need to guess N for between the timer checks, so
that a sufficiently large amount of work is done.  Hm, what is a
'sufficiently large' chunk of time?  0.1 second?  Your timing could only
be roughly that accurate, then.  If you checked every 1 second, you'd
need a somewhat long run to avoid skewing error.  Like 100..1000
seconds.  I'm having trouble with epsilons in my mind right now.  1:1000
sounds about right to suppress error.

Or you could go for a CPU hardware timer rather than an OS timer.  Much
more accurate, much more tedious to deal with.

Or maybe Knuth wasn't so dumb putting timers outside the process as I
thought.  Maybe 'guess N' calibration is inevitable, and you just end up
doing it at either a macro or a micro level.

> soething similar could be argued for a language with really inexact
> timers that will let the test run for a longer time.

Well, each language could have one required test: 'Timer'.  It would
have to be measurably as accurate as some Shootout reference timer.  Are
there any languages which can neither provide an accurate timer, nor
call a C function?


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur