On Sunday 21 June 2009 02:44:02 Kyle Schaffrick wrote: > On Sat, 20 Jun 2009 11:29:44 +0100 > Jon Harrop <j...@ffconsultancy.com> wrote: > > The Task Parallel Library. It uses concurrent wait-free work-stealing > > queues to provide an efficient implementation of "work items" than > > can spawn other work items with automatic load balancing on shared > > memory machines. Cilk uses the same technology (well worth a look if > > you haven't already seen it!). That makes it easy to write efficient > > parallel algorithms in any .NET language. In particular, it can > > sustain billions of work items (as opposed to thousands of threads or > > processes) and the time taken to spawn is ~30,000x faster than > > forking a process. Extremely useful stuff! > > Interesting. It strikes me that it's called "task" parallel library, > while it sounds a lot like Intel Threading Building Blocks, which is a > sort of STL-style quasi-functional template library for *data*-parallel > algorithms; the stuff people like to write with Fortran, OpenMP and > friends.
I had not looked at Intel's offering because it does not (AFAIK) support accurate garbage collection. Also, it is worth noting that there is no difference between data and task parallelism in a genuine functional language. > It uses a work-stealing thread-pool scheduler as well, atop which stuff > like parallel maps and reductions are implemented as templates. You can > create your own work items and stick them in the scheduler by hand, but > the useful bits are actually the prefab algorithms, IMO. Right. If you hand-roll your C++ very carefully then you can get decent performance but I was disappointed with the performance of the template libraries and quality of g++ back in 2004 and have never used C++ since. I've heard good things about D but, IMHO, it fails to cash in on lots of language features. Most notably FP. > The tunable/pluggable "slicing" strategies, built on the standard > iterator concepts, are particularly interesting way to give you full > control of work unit granularity, without having to know too much about > the innards of the algorithms themselves. Yes. The nice thing about using a functional language is that you can easily pass two functions, one to solve the problem and the other describing the complexity of the first as a function of its inputs. If necessary, you can augment your data structures with extra information to make it efficient to compute complexities. Then you can use the new "complexity" function to intelligently parallelize your algorithms into tasks such that the (roughly-constant) overhead of spawning tasks is guaranteed to be small compared to the work done by the task and, hence, you can greatly increase the probability of getting a speedup compared to ordinary chunking. Moreover, there is great benefit in sharing the same load balancing system. For example, if you write a parallel .NET program where tasks invoke the Intel MKL then the MKL uses independent parallelization and that renders your performance unpredictable at best and awful at worst. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
