On Friday 25 September 2009 08:32:26 Hugo Ferreira wrote: > Put it another way; if parallel/concurrent programming could be > easily used with a minimum of effort then I believe "most people" > would use it simply because it is available.
Once your run-time supports it, you just need a library that farms tasks out to threads via queues and a lot of parallelism really is easy. > >... > > If I tell you that you just have to modify a bit your program to get a > > near linear speedup, then it looks great. But in practice it is rather > > having to rethink completely your algorithm, to eventually get a > > speedup bounded by bandwidth, and starting from a point lower than the > > original single thread program. > >... > > Rethinking our application/algorithmic structure may not be a real > deterrent. An application does not require parallel/concurrent > processing everywhere. It is really a question of identifying where > and when this is useful. Much like selecting the most "appropriate" > data-structure for any application. It's not an all or nothing > proposition. Right. Parallelizing programs generally consists of identifying a performance bottleneck via measurement and performing the outermost parallelizable loops in parallel. You can do many more clever things but they are far less common. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
