Threadpools, difference between DMD and LDC

[Russel Winder via Digitalmars-d-learn]

On Mon, 2014-08-04 at 18:34 +0000, Dicebot via Digitalmars-d-learn
wrote:
[…]
> Well it is a territory not completely alien to me either ;) I am 
> less aware of academia research on topic though, just happen to 
> work in industry where it matters.

I have been out of academia now for 14 years, but tracking the various
lists and blogs, not to mention SuperComputing conferences, there is
very little new stuff, the last 10 has been about improving. The one new
thing is though GPGPU, which started out as an interesting side show but
has now come front and centre for data parallelism.

> I think initial spread of multi-threading approach has happened 
> because it was so temptingly easy - no need to worry about 
> actually modelling the concurrency execution flow, blocking I/O 
> or scheduling; just write the code as usual and OS will take care 
> of it. But there is no place for magic in programming world in it 
> has fallen hard once network services started to scale.

Threads are infrastructure just like stack and heap, very, very, very
few people actually worry about and manage these resources explicitly,
most just leave the run time system to handle it. OK so the usual GC
argument can be plopped in here, let's not bother though as we've been
through it three times this quarter :-)

> Right now is the glorious moment when engineers are finally 
> starting to appreciate how previous academia research can help 
> them solve practical issues and all this good stuff goes 
> mainstream :)

Actors are mid 1960s, dataflow early 1970s, CSP mid 1970s, it has taken
the explicit shared-memory multithreading in applications fiasco a long
time to pass. I can think of some applications which are effectively
operating systems and so need all the best shared-memory multithreading
techniques (I was involved in one 1999–2004), but most applications
people should be using actors, dataflow, CSP or data parallelism as
their applications model supported by library frameworks/infrastructure.

[…]
> Doubt programming / engineering community will ever accept 
> research that states that choosing architecture can be done on 
> pure theoretical basis :) It simply contradicts too much all 
> daily experience which says that every concurrent application has 
> some unique traits to consider and only profiling can rule them 
> all.

Most solutions to problems or subproblems can be slotted into one of
actors, dataflow, pipeline, MVC, data parallelism, event loop for the
main picture. If tweaking is needed, profiling and small localized
tinkerings can do the trick. I have yet to find many cases in my
(computation oriented) world where that is needed. Maybe in an I/O world
there are different constraints.

-- 
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/20140805/985d76c7/attachment.sig>