David St-Hilaire was experimenting with the following program:
(define n 0)
(thread-start! (make-thread (lambda () (let loop () (set! n (+ n 1)) (thread-sleep! .0001) (loop)))))
(thread-sleep! 1)
(pp n) ;; expected value of n is approximately 10000
The value printed for n on his Linux computer is approximately 100. When I try the program on my Mac OS X computer I get a value much closer to the expected 10000.
After digging around it seems that the resolution of the "timeout" parameter to the "select" system call (which is used by the scheduler to wait for I/O and/or a timeout) can vary greatly from one OS to another.
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
I also wrote the C program below to test the resolution of select's timeout. You can try that too.
Marc
Afficher les réponses par date
On Jan 27, 2009, at 8:36 PM, Marc Feeley wrote:
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
Does Solaris count as unusual nowadays?
zuse-2% gsc select.scm zuse-3% gsi select 103
I also wrote the C program below to test the resolution of select's timeout. You can try that too.
zuse-5% gcc -o select-test -O2 -Wall -W select-test.c select-test.c: In function 'sleep_using_select': select-test.c:45: warning: implicit declaration of function 'memset' select-test.c:45: warning: incompatible implicit declaration of built- in function 'memset' select-test.c: In function 'main': select-test.c:62: warning: unused parameter 'argc' select-test.c:62: warning: unused parameter 'argv' zuse-8% time ./select-test 0.01u 0.00s 1:40.04 0.0%
zuse-9% uname -a SunOS zuse.math.purdue.edu 5.9 Generic_118558-06 sun4u sparc SUNW,Sun- Fire-280R
For what is worth here are my results. I hope the result are not just adding noise, as it is yet another linux box only.
$ gsc test.scm $ gsi test 101 $ uname -a Linux dudrenov 2.6.25-gentoo-r8 #1 SMP Sat Nov 8 14:58:34 PST 2008 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux
Pavel
On Tue, Jan 27, 2009 at 6:19 PM, Bradley Lucier lucier@math.purdue.edu wrote:
On Jan 27, 2009, at 8:36 PM, Marc Feeley wrote:
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
Does Solaris count as unusual nowadays?
zuse-2% gsc select.scm zuse-3% gsi select 103
I also wrote the C program below to test the resolution of select's timeout. You can try that too.
zuse-5% gcc -o select-test -O2 -Wall -W select-test.c select-test.c: In function 'sleep_using_select': select-test.c:45: warning: implicit declaration of function 'memset' select-test.c:45: warning: incompatible implicit declaration of built- in function 'memset' select-test.c: In function 'main': select-test.c:62: warning: unused parameter 'argc' select-test.c:62: warning: unused parameter 'argv' zuse-8% time ./select-test 0.01u 0.00s 1:40.04 0.0%
zuse-9% uname -a SunOS zuse.math.purdue.edu 5.9 Generic_118558-06 sun4u sparc SUNW,Sun- Fire-280R _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
2009/1/28 Marc Feeley feeley@iro.umontreal.ca:
David St-Hilaire was experimenting with the following program: ..... (pp n) ;; expected value of n is approximately 10000
The value printed for n on his Linux computer is approximately 100. When I try the program on my Mac OS X computer I get a value much closer to the expected 10000.
After digging around it seems that the resolution of the "timeout" parameter to the "select" system call (which is used by the scheduler to wait for I/O and/or a timeout) can vary greatly from one OS to another.
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
Are you sure? I'm also on OS X (10.5 on a reasonably fast x86) and I get almost exactly 100 every time for the program you pasted:
Lyrebird:sicp oisin$ gsi test-threads.scm 99 Lyrebird:sicp oisin$ gsi test-threads.scm 99 Lyrebird:sicp oisin$ gsi test-threads.scm 102 Lyrebird:sicp oisin$ gsi test-threads.scm 101 Lyrebird:sicp oisin$ gsi test-threads.scm 100
It behaves the same when compiled. So even in the same OS (unless you're on a different version of OS X?), it seems these scheduler settings can drastically alter thread performance characteristics.
I also wrote the C program below to test the resolution of select's timeout. You can try that too.
Lyrebird:sicp oisin$ time ./a.out
real 0m1.606s user 0m0.026s sys 0m0.088s
Oisín
On 27-Jan-09, at 10:33 PM, Oisín Mac Fhearaí wrote:
2009/1/28 Marc Feeley feeley@iro.umontreal.ca:
David St-Hilaire was experimenting with the following program: ..... (pp n) ;; expected value of n is approximately 10000
The value printed for n on his Linux computer is approximately 100. When I try the program on my Mac OS X computer I get a value much closer to the expected 10000.
After digging around it seems that the resolution of the "timeout" parameter to the "select" system call (which is used by the scheduler to wait for I/O and/or a timeout) can vary greatly from one OS to another.
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
Are you sure? I'm also on OS X (10.5 on a reasonably fast x86) and I get almost exactly 100 every time for the program you pasted:
Lyrebird:sicp oisin$ gsi test-threads.scm 99 Lyrebird:sicp oisin$ gsi test-threads.scm 99 Lyrebird:sicp oisin$ gsi test-threads.scm 102 Lyrebird:sicp oisin$ gsi test-threads.scm 101 Lyrebird:sicp oisin$ gsi test-threads.scm 100
It behaves the same when compiled. So even in the same OS (unless you're on a different version of OS X?), it seems these scheduler settings can drastically alter thread performance characteristics.
There was a recently repaired bug with thread-sleep! that can cause this behavior. Please rerun the tests after updating with the latest patches (i.e. run "make update" first).
Marc
2009/1/28 Marc Feeley feeley@iro.umontreal.ca:
Lyrebird:sicp oisin$ gsi test-threads.scm 101 Lyrebird:sicp oisin$ gsi test-threads.scm 100
There was a recently repaired bug with thread-sleep! that can cause this behavior. Please rerun the tests after updating with the latest patches (i.e. run "make update" first).
Marc
Hi,
I removed the OS X install version and bootstrapped to the latest Git version (for some reason, it installs into /usr/local/Gambit-C/bin, but the 'distro' version installs links into /usr/bin?) and the results are much better:
Lyrebird:sicp oisin$ gsi test-threads.scm 5841 Lyrebird:sicp oisin$ gsi test-threads.scm 5857 Lyrebird:sicp oisin$ gsi test-threads.scm 5896
Oisín
After digging around it seems that the resolution of the "timeout" parameter to the "select" system call (which is used by the scheduler to wait for I/O and/or a timeout) can vary greatly from one OS to another.
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
I do not consider FreeBSD unusual (as it runs on 100% of my computers :D), yet
Freebsd 7.2 on a 64bits arch and gambit 4.2.8 gives 503 on average.
/usr/bin/time -p ./a.out real 19.92 user 0.00 sys 0.02
P!
I consider linux RT kernel is somewhat unusual.
Here is result of select-test.c on my Linux machine:
$ time ./a.out
real 0m10.015s user 0m0.000s sys 0m0.002s
$ uname -a Linux cassiopea 2.6.22-16-rt #1 SMP PREEMPT RT Mon Nov 24 19:03:10 GMT 2008 x86_64 GNU/Linux
Linux distro is Ubuntu 7.10 with RT linux kernel on laptop with Core 2 Duo in AMD64 mode.
When I run scheme code, I've got a value of n 1001 or 1002.
Vasil
David St-Hilaire was experimenting with the following program:
(define n 0)
(thread-start! (make-thread (lambda () (let loop () (set! n (+ n 1)) (thread-sleep! .0001) (loop)))))
(thread-sleep! 1)
(pp n) ;; expected value of n is approximately 10000
The value printed for n on his Linux computer is approximately 100. When I try the program on my Mac OS X computer I get a value much closer to the expected 10000.
After digging around it seems that the resolution of the "timeout" parameter to the "select" system call (which is used by the scheduler to wait for I/O and/or a timeout) can vary greatly from one OS to another.
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
I also wrote the C program below to test the resolution of select's timeout. You can try that too.
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On 28-Jan-09, at 2:13 AM, vasil wrote:
I consider linux RT kernel is somewhat unusual.
Here is result of select-test.c on my Linux machine:
$ time ./a.out
real 0m10.015s user 0m0.000s sys 0m0.002s
$ uname -a Linux cassiopea 2.6.22-16-rt #1 SMP PREEMPT RT Mon Nov 24 19:03:10 GMT 2008 x86_64 GNU/Linux
Linux distro is Ubuntu 7.10 with RT linux kernel on laptop with Core 2 Duo in AMD64 mode.
When I run scheme code, I've got a value of n 1001 or 1002.
Vasil
Please try it again, this time after a "make update".
I have changed the implementation of the "select" logic so that if "select" is being called purely to sleep (i.e. there is no I/O to wait for), then the "nanosleep" function will be called. I would appear that nanosleep has a much better resolution. I also fixed a bug which gave a segfault when thread-sleep! was interrupted.
Marc
After update scheme code displays n from 9040 to 9192.
Vasil
On 28-Jan-09, at 2:13 AM, vasil wrote:
I consider linux RT kernel is somewhat unusual.
Here is result of select-test.c on my Linux machine:
$ time ./a.out
real 0m10.015s user 0m0.000s sys 0m0.002s
$ uname -a Linux cassiopea 2.6.22-16-rt #1 SMP PREEMPT RT Mon Nov 24 19:03:10 GMT 2008 x86_64 GNU/Linux
Linux distro is Ubuntu 7.10 with RT linux kernel on laptop with Core 2 Duo in AMD64 mode.
When I run scheme code, I've got a value of n 1001 or 1002.
Vasil
Please try it again, this time after a "make update".
I have changed the implementation of the "select" logic so that if "select" is being called purely to sleep (i.e. there is no I/O to wait for), then the "nanosleep" function will be called. I would appear that nanosleep has a much better resolution. I also fixed a bug which gave a segfault when thread-sleep! was interrupted.
Marc
On 28-Jan-09, at 2:03 PM, vasil wrote:
After update scheme code displays n from 9040 to 9192.
Great! The discrepancy with the ideal result of 10000 is due to the interpretation overhead for the code executed between successive calls to thread-sleep! (you will probably get slightly higher numbers if you compile the code). So the resolution is much improved.
Marc
Interpreted code shows average n about 9064 (peak value was 9193), compiled code - 9210 (peak value was 9226).
Code was compiled with "(declare (not safe))" to get more speed.
Without this declaration difference between interpreted and compiled code is much less, ~9064 and ~9143 in average, accordingly.
Vasil
On 28-Jan-09, at 2:03 PM, vasil wrote:
After update scheme code displays n from 9040 to 9192.
Great! The discrepancy with the ideal result of 10000 is due to the interpretation overhead for the code executed between successive calls to thread-sleep! (you will probably get slightly higher numbers if you compile the code). So the resolution is much improved.
Marc
Marc Feeley wrote:
I'm curious to know how well other operating systems handle the timeout. So, if you have access to some unusual operating system, could you try the above program and report back what value is printed?
I don't know how useful Windows numbers will be, since Windows timeouts are implemented differently, but Win64 is sort of unusual....
Windows Vista SP1, 64-bit, Intel Q9450, native 64-bit: 66. I also ran a 32-bit Gambit executable under WOW64 on the same system and got the same result.
In comparison, an extremely un-unusual Windows XP SP3 on a Intel T7250 yielded 65.
[lucier@descartes gambc-v4_4_0-devel]$ gsc select.scm [lucier@descartes gambc-v4_4_0-devel]$ time gsi select 8597 0.052u 0.082s 0:01.02 12.7% 0+0k 0+0io 0pf+0w [lucier@descartes gambc-v4_4_0-devel]$ time gsi select 8532 0.052u 0.082s 0:01.02 12.7% 0+0k 0+0io 0pf+0w [lucier@descartes gambc-v4_4_0-devel]$ gcc -O2 -Wall -W select-test.c -o select-test select-test.c: In function â: select-test.c:62: warning: unused parameter â select-test.c:62: warning: unused parameter â [lucier@descartes gambc-v4_4_0-devel]$ time ./select-test 0.005u 0.077s 0:10.01 0.6% 0+0k 0+0io 0pf+0w [lucier@descartes gambc-v4_4_0-devel]$ uname -a Linux descartes.math.purdue.edu 2.6.27.12-170.2.5.fc10.ppc64 #1 SMP Wed Jan 21 01:27:38 EST 2009 ppc64 ppc64 ppc64 GNU/Linux [lucier@descartes gambc-v4_4_0-devel]$ gcc -mcpu=970 -m64 -O2 -Wall - W select-test.c -o select-test select-test.c: In function â: select-test.c:62: warning: unused parameter â select-test.c:62: warning: unused parameter â [lucier@descartes gambc-v4_4_0-devel]$ time ./select-test 0.004u 0.077s 0:10.00 0.7% 0+0k 0+0io 0pf+0w