Channels ▼

Community Voices

Dr. Dobb's Bloggers

Multicore - Who is affected?

May 22, 2008

Multi-Core: Will It Affect Us?

Who's affected? Obviously; Oil and Gas, the Military, the financial institutions, games/simulation developers and anybody interested in climate or alien visitation prediction; but perhaps the other 99% of us need to at least consider multi-core as a relevant technology.

How will it affect me?

Before considering the most important question of all "What's the Solution?" it's worth considering what type of problem (if any) does your application belong to? This will determine how easy/hard your problem is likely to be. Broadly speaking (and it’s a pretty rough guide) multi-core problems could be considered to fall into the five categories below (or in some cases combinations of). The simplest cases are the data-parallel ones (all the CPUs do the same thing) and the hardest by far, are the irregular cases where there is a wide range of different tasks that may be required to execute in parallel. Ironically GUI-centric applications, which are amongst the most typical; are also going to be amongst the hardest to deal with (always assuming they require the benefits afforded by multi-core).

  1. The simplest multi-core devices may have the restriction that each core must execute the same instruction at the same time. So if the calculation needs to branch on a particular data value and each core potentially has a different value, then it could be that the CPUs are unable to sustain fully parallel execution. Amongst others this approach may be sufficient for pixel rendering (GPU devices), some signal processing, and a wide range of matrix operations. See SIMD devices. There are solutions to these types of problems and these would include RapidMind and Peakstream’s technologies.
  2. If your problem is data parallel (all the CPUs execute the same program) but the calculation is not restricted to executing actual instructions in parallel, then you are unlikely to benefit from SIMD programming techniques and could consider an SPMD approach. This could introduce some new issues like load balancing (if the execution time is data dependant), but this approach would enable you to consider a wider range of problems. OpenMP and also Intel’s recent Threading Building Blocks (TBB) solutions would be applicable.
  3. If your problem is data parallel but needs to recruit multiple CPUs (distributed) then it could be suitable for MPI, but some cases will be more difficult than others. If you are fortunate enough to have a cluster of identical machines then load balancing could be as simple as implementing a scatter/gather mechanism, but if you want to capitalize on all available resources (general heterogeneous clusters) then load-balancing even something as routine as Finite Difference Time Domain (FDTD), becomes an issue. Not only that, but whilst single machine multi-core is typically addressed by OpenMP, the distributed case is usually addressed by MPI. So what do you do with a cluster of multi-core machines (these problems need a higher level of abstraction)?
  4. Real-time applications add another layer of difficulty to the multi-core problem because none of the solutions referenced in the three cases above support the notion of network level pre-emption.
  5. If your problem is irregular (cannot typically benefit from expandable for-loops) then your options are considerably more limited and in the worst case may lead you to consider raw threads/locks/semaphores which most commentators agree are the concurrent programming world’s equivalent of assembly language – just a lot harder.

It is important to remember that the application components that consume the most machine cycles are not necessarily the ones that require the most programming effort (and vice-versa). Acoustic and/or Seismic exploration system’s such as those used by the Military and/or Oil and Gas are highly complex, and as well as convenient data-parallel signal processing sub-systems, also tend to have irregular components (tracking and classification) that are far more difficult to parallelize, add in logging/replaying, control, display, data distribution policies and many other highly irregular features, not to mention the fact that all of this often needs to be hard/soft real-time and you can see why multi-core is likely to be viewed as both an opportunity and challenge for these and similar sectors.



Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

