The multicore future, and how to survive it

I don't understand

what everyone's problem is. You just follow best practices, never access your data from two threads at once, and away you go.

Between a Rock and a Hard Place

Interesting article. As much as the powers that be at Intel know that multithreading is not the answer to the parallel programming crisis, they also know that they have wedged themselves between a rock and a hard place. They have way too much invested in last century's legacy technologies to change strategy at this late stage of the game. It makes sense for them to acquire outfits like Rapidmind and Cilk. The former specializes in domain specific application development tools for multicore processors while the latter makes clever programs that discover concurrent tasks in legacy sequential programs. Intel's intelligentsia figure that this should give them enough breathing room while they contemplate their next move. Question is, is this a good strategy? I really don't think so.

In my opinion, Intel, AMD and the others are leading their customers astray by making them believe that multithreading is the future of parallel computing. Billions of dollars will be spent on making the painful transition by converting legacy code for the new thread-based multicore processors. The problem is that multithreading is not just a bad way to program parallel code (do a search on Dr. Edward Lee of Berkeley), it is the cause of the crisis. Neither Rapidmind nor Cilk are going to change that simple fact. These acquisitions are just a way of trying to force a round peg into a square hole as much as it can go. Sooner or later, a real maverick will show up and do the right thing and there shall be much weeping and gnashing of teeth . Being a behemoth is no guarantee of long-term survival in the computer business. Sorry, Intel.

Google or Bing "How to Solve the Parallel Programming Crisis" if you're interested in finding about the real solution to the crisis.

sure...

it's as simple as that.

@BlueGreen

Yo, BlueGreen. Identify yourself if you got any gonads.

Intestesting, but..

A proprietary extension to C when I have to write cross-platform code? Go away. If it was a C/C++ API then it might be usable.

QtConcurrent

I recently used the Qt Concurrent framework to speed up a statistical calculation. Lots of floating point but not much memory access. Basically you break up the problem, put each part's data into an object that also has a method to process the data and turn a list of these objects over to the framework. It was rather fun to see my quad core hit 100% CPU and solve the proble in 1/4 the time. It is loosely based on the Google Map Reduce process. Breaking up the data into objects also makes it easy to keep the multi-thread access running without locks.

As I see it, the main problems yet to be solved are (1) the ability to run fast on all cores when doing memory intensive operations such as image processing and (2) the ability to run multiple short operations where the thread scheduling time becomes a problem. The first is basically due to hardware limitations and won't be solved in software. The second may be solved by better thread scheduling or programming language extensions.

@Louis Savain

At the instruction level, your "solution" sounds very like "pipelining" (Google or Bing it), and is already done in many modern processors. The problem with determining parallelism at this level is that a significant amount of high-level problem-specific information has been lost (i.e. the information that certain instructions can be run on different CPUs/cores which is implicit in threading).

At the software level, your "solution" to the parallel programming problem is just a description of a "task farm" (Google or Bing it) with a "Message Passing Interface" (Google or Bing it), except that the tasks are kept in a queue and must be carried out in order. That kind of parallelism is only good when you have many independent sub-problems, and is not suited to multiple worker threads operating on the same data (although it can be done).

However, for many problems, the overhead required for locking (including the idling of other threads which need to access the locked memory) is the killer, and in these cases it takes a lot of effort to code a solution that minimises the amount of locking required (i.e. a generic solution won't be as efficient).

Basically, concurrent memory updates are the problem, not concurrent execution of threads. The more concurrent memory updates your problem requires, the less of a benefit you will get from using a parallel algorithm.

Grand Central Dispatch (and other similar technologies) are only designed to make it easier to write code which can run in parallel, should you be able to identify suitable sub-problems.

Easy Really

All this talk about how hard parallel processing or multi-tasking software development is just a load of balderdash. I've never had any problem writing it and my code has stood the test of time in many client environments. If you can't take the heat, stay out of the kitchen.

The vendors want a paradigm that can be used by the outsourced, low-pay half-wits that the software houses favour. That's what this is all about but the reality is that with these sort of problems you require a specialised solution for every problem, that is you need to actually be reasonably smart and those horrid smart people demand a living wage for their efforts damn them.