[Openmcl-devel] sleep function in Cocoa.

Wed Jan 1 03:57:41 PST 2014

Btw., my Macbook Air ran on battery for these tests.

Am 01.01.2014 um 12:55 schrieb Jeff Caldwell <jcaldwell at clozure.com>:

> I ran your dotimes example on a 2011 MacBook Pro running 10.9.1 and CCL Version 1.10-dev-r15974M-trunk  (DarwinX8664). The average run time was around 100.07 seconds, ranging from 100.05 to 100.09 seconds. I had CCL running in an Emacs window in tmux and was connected to CCL via slime-connect in Emacs for OS X. Neither Emacs window was on display during most of the run.
> 
> 
> On Wed, Jan 1, 2014 at 6:36 AM, Rainer Joswig <joswig at lisp.de> wrote:
> This is what I see on my 2012 Macbook Air with Mac OS X 10.9.1. iTunes was running in the background. Most of the time CCL was not the front application and its windows were hidden behind Apple Mail.
> 
> 
> Welcome to Clozure Common Lisp Version 1.8-store-r15418  (DarwinX8664)!
> ? (dotimes (i 5)
> (time (dotimes (i 100)
>        (sleep 1))))
> (DOTIMES (I 100) (SLEEP 1))
> took 100,110,658 microseconds (100.110660 seconds) to run.
> During that period, and with 4 available CPU cores,
>          149,869 microseconds (  0.149869 seconds) were spent in user mode
>           48,910 microseconds (  0.048910 seconds) were spent in system mode
>  1,066 minor page faults, 5 major page faults, 0 swaps.
> (DOTIMES (I 100) (SLEEP 1))
> took 130,075,484 microseconds (130.075490 seconds) to run.
> During that period, and with 4 available CPU cores,
>           67,339 microseconds (  0.067339 seconds) were spent in user mode
>           32,443 microseconds (  0.032443 seconds) were spent in system mode
>  1,335 minor page faults, 3 major page faults, 0 swaps.
> (DOTIMES (I 100) (SLEEP 1))
> took 131,043,588 microseconds (131.043580 seconds) to run.
> During that period, and with 4 available CPU cores,
>           76,666 microseconds (  0.076666 seconds) were spent in user mode
>           32,517 microseconds (  0.032517 seconds) were spent in system mode
>  1,076 minor page faults, 3 major page faults, 0 swaps.
> (DOTIMES (I 100) (SLEEP 1))
> took 137,310,368 microseconds (137.310360 seconds) to run.
> During that period, and with 4 available CPU cores,
>          109,781 microseconds (  0.109781 seconds) were spent in user mode
>           40,377 microseconds (  0.040377 seconds) were spent in system mode
>  588 minor page faults, 3 major page faults, 0 swaps.
> (DOTIMES (I 100) (SLEEP 1))
> took 100,122,436 microseconds (100.122430 seconds) to run.
> During that period, and with 4 available CPU cores,
>           93,868 microseconds (  0.093868 seconds) were spent in user mode
>           36,627 microseconds (  0.036627 seconds) were spent in system mode
>  577 minor page faults, 3 major page faults, 0 swaps.
> NIL
> 
> 
> 
> Am 01.01.2014 um 01:59 schrieb Gary Byers <gb at clozure.com>:
> 
>> I can't reproduce this on a fairly recent version of the CCL trunk and
>> OSX 10.9.0; I haven't yet "upgraded" to 10.9.1.  I find that (SLEEP 1) takes
>> very slightly more than 1 second; I've seen TIME claim that (SLEEP 10) takes
>> very slightly less than 10 seconds, but I assume that the small discrepancy
>> there has to do with slight differences between clock sources.  I tried this
>> both running CCL in the shell and running under the Cocoa IDE; I got essentially
>> the same results in both cases and don't remember any recent CCL change that
>> would explain the results that you're seeing.
>> 
>> There's usually some latency involved: the calling thread can wake up after
>> having slept for the specified time interval, but it may be a little while
>> before the OS actually wakes it up.  If there's a very heavy load on the system
>> (lots of other threads running) this latency will be higher than it would be
>> otherwise, but if system load was causing the results that you're seeing you'd
>> likely be very aware of that (everything would have slowed to a dead crawl.)
>> 
>> On Unix-based systems, SLEEP is implemented in terms of the #_nanosleep system
>> call; the OSX implementation of #_nanosleep has had a bug off and on since OSX
>> 10.5, and (until around 2 years ago) CCL's attempts to work around that bug
>> sometimes made things worse.  (If #_nanosleep is interrupted by a signal before
>> the timeout is reached, it's supposed to return a value indicating that that
>> had happened and optionally another value which indicated how much time was remaining; on OSX, if #_nanosleep was interrupted after the scheduled
>> deadline, it claimed that it was interrupted and that a small negative
>> amount of time remained.  The field in the data structure was unsigned,
>> so the "small negative remaining time" was interpreted as a very large
>> positive remaining time, and retrying the #_nanosleep effectively slept
>> forever.)  I don't think that that's been present in the last few OSX
>> releases and I think that current versions of CCL work around it correctly.
>> 
>> So: it took me a while to say it, but I can't reproduce the problem and don't
>> have a good guess as to what it might be.
>> 
>> 
>> 
>> On Tue, 31 Dec 2013, Park SungMin wrote:
>> 
>>> in Mavericks(OS X 10.9)? I call sleep function..(in CCL IDE and slime(require ?cocoa))
>>> (sleep 1)? sometime sleep to over 10 seconds,?
>>> ?also, NSTimer sometime have long interval in repeats.
>>> 
>>> so I tested it?. is it bug?  Thanks.
>>> 
>>> 
>>> Welcome to Clozure Common Lisp Version 1.10-dev-r15993M-trunk  (DarwinX8664)!
>>> ? (dotimes (i 5)
>>> (time (dotimes (i 100)
>>>        (sleep 1))))
>>> 
>>> (DOTIMES (I 100) (SLEEP 1))
>>> took 310,040,206 microseconds (310.040200 seconds) to run.
>>> During that period, and with 4 available CPU cores,
>>>        121,045 microseconds (  0.121045 seconds) were spent in user mode
>>>         40,618 microseconds (  0.040618 seconds) were spent in system mode
>>> 2,119 minor page faults, 3 major page faults, 0 swaps.
>>> 
>>> (DOTIMES (I 100) (SLEEP 1))
>>> took 297,074,248 microseconds (297.074250 seconds) to run.
>>> During that period, and with 4 available CPU cores,
>>>         95,682 microseconds (  0.095682 seconds) were spent in user mode
>>>         32,199 microseconds (  0.032199 seconds) were spent in system mode
>>> 2,327 minor page faults, 6 major page faults, 0 swaps.
>>> 
>>> (DOTIMES (I 100) (SLEEP 1))
>>> took 450,511,262 microseconds (450.511260 seconds) to run.
>>> During that period, and with 4 available CPU cores,
>>>         85,223 microseconds (  0.085223 seconds) were spent in user mode
>>>         32,064 microseconds (  0.032064 seconds) were spent in system mode
>>> 2,588 minor page faults, 9 major page faults, 0 swaps.
>>> 
>>> (DOTIMES (I 100) (SLEEP 1))
>>> took 361,880,357 microseconds (361.880340 seconds) to run.
>>> During that period, and with 4 available CPU cores,
>>>         83,736 microseconds (  0.083736 seconds) were spent in user mode
>>>         24,041 microseconds (  0.024041 seconds) were spent in system mode
>>> 1,110 minor page faults, 4 major page faults, 0 swaps.
>>> 
>>> (DOTIMES (I 100) (SLEEP 1))
>>> took 453,001,014 microseconds (453.001040 seconds) to run.
>>> During that period, and with 4 available CPU cores,
>>>        103,395 microseconds (  0.103395 seconds) were spent in user mode
>>>         24,570 microseconds (  0.024570 seconds) were spent in system mode
>>> 958 minor page faults, 1 major page faults, 0 swaps.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>> 
>>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20140101/6fd8e12e/attachment.htm>