[Openmcl-devel] sleep function in Cocoa.
Gary Byers
gb at clozure.com
Wed Jan 1 11:43:21 PST 2014
What Apple calls "timer coalescing" presumably means that if some thread
schedules a timer interrupt to occur at time T and there's already
an interrupt scheduled for time T+/- N, then one or the other request
is adjusted so that they can both be serviced by the same interrupt
(avoiding the costs associated with having two interrupts fire in
rapid succession.) We don't know what N is (at least not from
the link you cited), but if it's reasonably small (a small fraction
of a second) this change isn't going to have a perceptable effect
on anything: (SLEEP 1) will generally take a little more than 1
second, as it always has. If N is more than "a small fraction
of a second", that would likely have perceptable effects.
Park SungMin said that he was seeing (SLEEP 1) take several seconds;
I said that I couldn't reproduce that on 10.9.0 and other people
reported similar results for 10.9.1. I don't think that we have
a good explanation for the behavior that Park is seeing, but knowing
that Apple has changed some of the related code recently certainly
opens the possibility that they botched something. (Among other
possibilities, of course.)
On Wed, 1 Jan 2014, Greg Gilley wrote:
> 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
>
>
>
>
More information about the Openmcl-devel
mailing list