Re: Timing bug?

[Pascal J. B. <pj...@in...>]

Matthew Stickney <mts...@gm...> writes:

> Hi,
>
> I've come across a strange performance problem with CLISP 2.49 while
> working on a project today. I have the following function, simplified
> from some code for doing IO with timeouts (is there a better way to do
> this than polling?):
>
> (defun poll-test ()
>   (let ((deadline (+ (get-internal-real-time)
>                           (* .5 internal-time-units-per-second))))
>     (loop while (<= (get-internal-real-time) deadline)
>        do (sleep 0.01))))
>
> Most of the time the loop is never run, which is surprising (is there
> really a .5 second lag between computing/storing the deadline value

You don't want .5 second lag, you want 1/2 second lag.

.5 is read as a floating point number of type specified by
*read-default-float-format* which is single float by default.
Therefore deadline will be a number with 6 decimal digits of precision,
and of the order of 1e15 currently.  Therefore it will be on the order
of 1e9 seconds in the future.

Read that:

    http://www.exploringbinary.com/the-four-stages-of-floating-point-competence/  
    What Every Computer Scientist Should Know About Floating-Point Arithmetic
    http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
    http://portal.acm.org/citation.cfm?id=103163
    http://focus.hut.fi/docs/WorkShop/common/ug/goldberg1.doc.html

and reach the same conclusion as I have: 

     NEVER USE FLOATING POINT NUMBERS.


If you near real numbers, integrate such a library:

    RealLib3:
    http://www.brics.dk/~barnie/RealLib/


Also, about time, have a look at:

http://unix4lyfe.org/time/
http://naggum.no/lugm-time.html
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time-wisdom



> Is this a bug? 

Yes.


> Is my system (or code) broken? 

No.


> Is this just my scheduler going crazy?

No.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.