It could be the busy-waiting. Instead of looping and yielding a waiting
thread should park itself. The ReentrantLock and Condition classes from
http://home.comcast.net/~benhinkle/locks/locks.html should help - but I
don't know if user libraries are allowed in the shootout like that.

It could be the busy-waiting. Instead of looping and yielding a waiting
thread should park itself. The ReentrantLock and Condition classes from
http://home.comcast.net/~benhinkle/locks/locks.html should help - but I
don't know if user libraries are allowed in the shootout like that.

If the code was making 500 threads it could also be that they ran the
benchmark on linux and bumped into phobos's limitation on the number of
threads allowed at once:
static Thread[/*_POSIX_THREAD_THREADS_MAX*/ 100] allThreads;
"Sean Kelly" <sean f4.ca> wrote in message
news:dkr4ls$ljk$1 digitaldaemon.com...

It could be the busy-waiting. Instead of looping and yielding a waiting
thread should park itself. The ReentrantLock and Condition classes from
http://home.comcast.net/~benhinkle/locks/locks.html should help - but I
don't know if user libraries are allowed in the shootout like that.

If the code was making 500 threads it could also be that they ran the
benchmark on linux and bumped into phobos's limitation on the number of
threads allowed at once:
static Thread[/*_POSIX_THREAD_THREADS_MAX*/ 100] allThreads;

Ah, good point. Ares doesn't have this limitation as it used an AA for
storing thread references.
Sean

If the code was making 500 threads it could also be that they ran the
benchmark on linux and bumped into phobos's limitation on the number of
threads allowed at once:
static Thread[/*_POSIX_THREAD_THREADS_MAX*/ 100] allThreads;

Ah, good point. Ares doesn't have this limitation as it used an AA for
storing thread references.

Sean,
Out of curiosity, have you tried using Ares' Atomic lib for this task? I wonder
what the difference in time would be when compared to 'synchronized'?
- EricAnderton at yahoo

Out of curiosity, have you tried using Ares' Atomic lib for this task? I
wonder
what the difference in time would be when compared to 'synchronized'?

See my reply to the OP. I tried simply removing the 'synchronized'
properties entirely and only saw a small performance increase (less than
0.1 seconds average). I suspect this is because the real time consumer
in this case is thread creation. I also tried disabling the GC and the
test ran slower on average than with it enabled. It would probably be
difficult to optimize this test to perform noticeably better as the 500
threads need to be created no matter what.
Sean

I don't really like the way this test is structured, as what it is
really testing the efficiency of thread creation. For any language with
its roots in OS-level thread code, the performance should be pretty much
equivalent. I suspect the functional languages perform so well because
they do user-level concurrency rather than kernel-level concurrency (and
probably also because they don't allocate large chunks of memory for
stack space and such in the process). I'm quite surprised by the
abysmal performance of the Scheme and OCaml tests however. Is it simply
because their interpreters stink?
Sean

I suspect the functional languages perform
so well because they do user-level concurrency rather than
kernel-level concurrency

<snip>
I think we should have both in D.
I don't think it's too hard to imagine a situation where one would want
to use a few real OS threads, and _within_ some of them a bunch of
simple cooperating light weight threads. ("Fibers, if you like.")
Equally, preemtive threading is overkill for a lot of other things.

I suspect the functional languages perform
so well because they do user-level concurrency rather than
kernel-level concurrency

<snip>
I think we should have both in D.
I don't think it's too hard to imagine a situation where one would want
to use a few real OS threads, and _within_ some of them a bunch of
simple cooperating light weight threads. ("Fibers, if you like.")

I would like to see it too. I've to write my own "tasks" for TCP server I'm
working on. Real threads are just to heavy to be massive. And things like
this are often used IMO, so having them in standard lib would be great.