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 experiments. -- Russel. ============================================================================= 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
signature.asc
Description: This is a digitally signed message part
