On Sat, 2015-03-28 at 18:55 +0000, Dicebot via Digitalmars-d-announce wrote:
> I don't think it is that simple. From the purist academical 
> parallelism POV - most likely. In practice it often can be quite 
> the contrary, TLS is your best friend (depending on how efficient 
> platfrom implementation is).

I suggest it really is that simple even for non-academic applications…

> To get best high-load performance best strategy is to actually 
> design applications with specific hardware traits in mind, 
> including pre-defined amount of CPU cores and their task 
> affinity. Computation parallelism is relatively easy, it is 
> memory parallelism that remains a challenging task as long as you 
> try to get rid of locking overhead, costly synchronizations and 
> optimize cache loads. Something like moving fibers between 
> threads is absolute disaster in this sense even if it looks like 
> a tempting abstraction on paper. But if you prohibit that by 
> design and maintain strict affinity between fibers and threads, 
> using TLS allows for very nice optimizations (as it is 
> effectively limited sharing without locking / atomics). It can be 
> complicated to design (which is why Go choice makes sense for 
> their target audience) but benefits are also very good.

If you write your software to fit a particular platform, including 
hardware features, then you are writing an operating system dedicated 
to that one specific platform and no other. If the idea is to write 
portable applications then:

a. you must abstract away from a specific platform;
b. you must accept some overhead.

The very fact that people are writing in D (or C++, Java, C#,…) means 
you have accepted some abstraction – otherwise you would be writing in 
assembly language. Having made the jump to high-level languages why 
baulk at a small overhead to abstract concurrency and parallelism? 
Making tasks lightweight processes rather than maintaining shared 
memory, and using channels to move data around rather than using 
shared memory and locks, makes applications' concurrency and 
parallelism easier to construct and manage (*). If we are prepared to 
accept overhead for stack and heap management, we must accept the 
overhead of processor management via thread pooling with work stealing.

(*) Andrei, this is something of a claim really just now, since 
although there is anecdotal evidence, I haven't managed to get the 
psychology of programming people to do statistically significant 
experiments. I will be trying again at PPIG 2015 to motivate the 

Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to