[Openmcl-devel] sleep function in Cocoa.
Jeff Caldwell
jcaldwell at clozure.com
Wed Jan 1 03:55:32 PST 2014
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/cd4bf9a3/attachment.htm>
More information about the Openmcl-devel
mailing list