Threadpools, difference between DMD and LDC

[Russel Winder via Digitalmars-d-learn]

Sorry, I missed this thread (!) till now.

On Mon, 2014-08-04 at 13:36 +0000, Dicebot via Digitalmars-d-learn
wrote:
> On Monday, 4 August 2014 at 05:14:22 UTC, Philippe Sigaud via 
> Digitalmars-d-learn wrote:
> > I have another question: it seems I can spawn hundreds of 
> > threads
> > (Heck, even 10_000 is accepted), even when I have 4-8 cores. Is 
> > there:
> > is there a limit to the number of threads? I tried a threadpool
> > because in my application I feared having to spawn ~100-200 
> > threads
> > but if that's not the case, I can drastically simplify my code.
> > Is spawning a thread a slow operation in general?

Are these std.concurrent threads or std.parallelism tasks?

A std.parallelism task is not a thread. Like Erlang or Java Fork/Join
framework, the program specifies units of work and then there is a
thread pool underneath that works on tasks as required. So you can have
zillions of tasks but there will only be a few actual threads working on
them.

> Most likely those threads either do nothing or are short living 
> so you don't get actually 10 000 threads running simultaneously. 

I suspect it is actually impossible to start this number of kernel
threads on any current kernel.

> In general you should expect your operating system to start 
> stalling at few thousands of concurrent threads competing for 
> context switches and system resources. Creating new thread is 
> rather costly operation though you may not spot it in synthetic 
> snippets, only under actual load.

> Modern default approach is to have amount of "worker" threads 
> identical or close to amount of CPU cores and handle internal 
> scheduling manually via fibers or some similar solution.

I have no current data, but it used to be that for a single system it
was best to have one or two more threads than the number of cores.
Processor architectures and caching changes so new data is required. I
am sure someone somewhere has it though.

> If you are totally new to the topic of concurrent services, 
> getting familiar with http://en.wikipedia.org/wiki/C10k_problem 
> may be useful :)

I thought they'd moved on the the 100k problem.

There is an issue here that I/O bound concurrency and CPU bound
concurrency/parallelism are very different beasties. Clearly tools and
techniques can apply to either or both.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20140804/76394989/attachment.sig>