Re: Time to sleep under different platforms
You're perfectly right. My goal was not to develop a tool to measure the
sleep performances. Just to speak about the difference between sleep and the
mp package functions. I suppose that the difference observed with this loop
are not contradicted by your test (at least if we speak of practical
situations and not of pure theory).
Naturally a scheduler cannot be based on a loop like this one, as you said
the time for operations must be included. Moreover, it is why it's not
possible to have a ms scheduler on pure lisp, even with sleep, because to
have one wee need a smaller time definition than ms. The procedure I use on
mac is based on machine time at a resolution of 1.000.000 per second on an
intel mac (less on power pc). With this resolution it's possible to include
the time of the tasks in the computation and have, globally, an ms
resolution (the wait function is not based on an interval but on a point to
reach always relative to the start point).
This message was also to said that something similar is certainly possible
on XP, otherwise I really don't know how some software I used on XP
(especially for sound edition) could works at a 88khz definition...
Anyway, thanks for your very interesting demonstration !
Best regards
Denis
Le 22/07/10 16:43, « [NOM] » <[ADRESSE]> a écrit :
>
>
> On Jul 22, 2010, at 7:53 AM, Denis Pousseur wrote:
>
>> On my system cl::internal-time-units-per-second return 1000 (and I suppose
>> on every systems running lw). The result of the test is 500, so it's not the
>> same thing. But you're right, it's certainly much precise to say : this test
>> compute the EFFECTIVE number of ticks per second.
>
>
> What you're measuring here is the overhead of doing all of these things every
> time though the loop
> 1. the loop counter increment
> 2. get-internal-real-time
> 3. the comparison with the start time
> 4. the call to sleep
>
> these things do take some finite time to execute. The counter increment and
> some sort of comparison are unavoidable - we can't have a finite loop without
> them, and the calls to sleep are precisely what we want to time. However, if
> you want to see how far off internal-time-units-per second is wrt sleep, you
> shouldn't also be doing a call to get-internal-real-time every pass though the
> loop, and to be precise, we should back out the time for an empty loop of the
> same size. As it turns out, the empty loop time is negligible (< 1
> millisecond), so we can ignore it.
>
> so:
>
> (defun dotimes-ticktest (&optional (times 1000))
> (declare (optimize (speed 3) (safety 0) (debug 0) (compilation-speed 0)
> (space 0) (fixnum-safety 0) (float 0)))
> (let* ((sleeptime (float (/ internal-time-units-per-second) 0.0s0))
> (start (get-internal-real-time))
> (stop
> (mp:with-interrupts-blocked
> (dotimes (n times (get-internal-real-time))
> (declare (fixnum n))
> (sleep sleeptime)))))
> (declare (fixnum start stop) (single-float sleeptime))
> (float (/ (- stop start) times))))
>
> on my machine this returns 1.11, or an 11% overhead for the calls to sleep. I
> get similar results with Clozure Common Lisp and sbcl btw - both show about
> 10-11% overhead for a large number of calls to sleep.
>
> warmest regards,
>
> Ralph
>
>
>
>
> Raffael Cavallaro
> raffaelcavallaro@me.com
>
>
>
>
>
-------------------------------------------------------
Denis Pousseur
70 rue de Wansijn
1180 Bruxelles, Belgique
Tel : 32 (0)2 219 31 09
Mail : denis.pousseur@gmail.com
-------------------------------------------------------