[Openmcl-devel] sleep function in Cocoa.

Greg Gilley ggilley at gerg.org
Wed Jan 1 09:56:26 PST 2014 

OS X does timer coalescing to improve battery life. Sleep(1) is not guaranteed to be one second on battery.

http://www.apple.com/osx/advanced-technologies/

	Greg

On Jan 1, 2014, at 3:57 AM, Rainer Joswig <joswig at lisp.de> wrote:

> 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
>> 
>> 
> 
> _______________________________________________
> 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/054d9655/attachment.htm>

More information about the Openmcl-devel mailing list