Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>There are three parts to parallel programming IMO: identify the parallelism and specify the parallelism. Identify=Breaking down the algorithm into concurrent chunks of work, specify=doing the actual coding/debugging. Identify is independent of which framework you will use to specify the parallelism and I don't think a framework can help there much. It comes with good understanding of your app, target platform, common parallel programming trade-offs (hardware latencies etc), and MOST importantly experience. Specify however can be discussed and this is what I try to answer below: </p> <p>I have tried many frameworks (at school and work). Since you asked about multicores, which are all shared memory, I will stick with three shared memory frameworks I have used. </p> <p>Pthreads (Its no really a framework, but definitely applicable):</p> <p>Pro: -Pthreads is extremely general. To me, pthreads are like the assembly of parallel programming. You can code any paradigm in pthreads. -Its flexible so you can make it as high performance as you want. There are no inherent limitations to slow you down. You can write your own constructs and primitives and get as much speed as possible.</p> <p>Con: -Requires you to do all the plumbing like managing work-queues, task distribution, yourself. -The actual syntax is ugly and your app often has a lot of extra code which makes code hard to write and then hard to read. </p> <p>OpenMP:</p> <p>Pros: -The code looks clean, plumbing and task-splitting is mostly down under the hood -Semi-flexible. It gives you several interesting options for work-scheduling </p> <p>Cons: -Meant for simple for-loop like parallelism. (The newer Intel verion does support tasks too but the tasks are the same as Cilk). -Underlying structures may or may not be well-written for performance. GNUs implementation is just ok. Intel's ICC worked better for me but I would rather write some stuff myself for higher performance. </p> <p>Cilk, Intel TBB, Apple GCD:</p> <p>Pros: -Provably optimal underlying algorithms for task-level parallelism -Decent control of serial/parallel tasks -TBB also has a pipeline parallelism framework which I used (it isn't the best to be frank) -Eliminates the task of writing a lot of code for task-based systems which can be a big plus if you are short-handed </p> <p>Cons: -Less control of underlying structures' performance. I know the Intel TBB has very poorly-performing underlying data structures, e.g., the work queue was bad (in 2008 when I saw it). -The code looks awful sometimes with all the keywords and buzzwords they want you to use -Requires reading a lot of references to understand their "flexible" APIs</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload