Question

I’m doing some research on multicore processors; specifically I’m looking at writing code for multicore processors and also compiling code for multicore processors.

I’m curious about the major problems in this field that would currently prevent a widespread adoption of programming techniques and practices to fully leverage the power of multicore architectures.

I am aware of the following efforts (some of these don’t seem directly related to multicore architectures, but seem to have more to do with parallel-programming models, multi-threading, and concurrency):

• Erlang (I know that Erlang includes constructs to facilitate concurrency, but I am not sure how exactly it is being leveraged for multicore architectures)
• OpenMP (seems mostly related to multiprocessing and leveraging the power of clusters)
• Unified Parallel C
• Cilk
• Intel Threading Blocks (this seems to be directly related to multicore systems; makes sense as it comes from Intel. In addition to defining certain programming-constructs, it also seems have features that tell the compiler to optimize the code for multicore architectures)

In general, from what little experience I have with multithreaded programming, I know that programming with concurrency and parallelism in mind is definitely a difficult concept. I am also aware that multithreaded programming and multicore programming are two different things. in multithreaded programming you are ensuring that the CPU does not remain idle (on a single-CPU system. As James pointed out the OS can schedule different threads to run on different cores — but I’m more interested in describing the parallel operations from the language itself, or via the compiler). As far as I know you cannot truly do parallel operations. In multicore systems, you should be able to perform truly-parallel operations.

So it seems to me that currently the problems facing multicore programming are:

• Multicore programming is a difficult concept that requires significant skill
• There are no native constructs in today’s programming languages that provide a good abstraction to program for a multicore environment
• Other than Intel’s TBB library I haven’t found efforts in other programming-languages to leverage the power of multicore architectures for compilation (for example, I don’t know if the Java or C# compiler optimizes the bytecode for multicore systems or even if the JIT compiler does that)

I’m interested in knowing what other problems there might be, and if there are any solutions in the works to address these problems. Links to research papers (and things of that nature) would be helpful. Thanks!

EDIT

If I had to condense my question down to one sentence, it would be this: What are the problems that face multicore programming today and what research is going on in the field to solve these problems?

UPDATE

It also seems to me that there are three levels where multicore needs to be concerned:

1. Language level: Constructs/concepts/frameworks that abstract parallelization and concurrency and make it easy for programmers to express the same
2. Compiler level: If the compiler is aware of what architecture it is compiling for, it can optimize the compiled code for that architecture.
3. OS level: The OS optimizes the running process and perhaps schedules different threads/processes to run on different cores.

I’ve searched on ACM and IEEE and have found a few papers. Most of them talk about how difficult it is to think concurrently and also how current languages don’t have a proper way to express concurrency. Some have gone so far as to claim that the current model of concurrency that we have (threads) is not a good way to handle concurrency (even on multiple cores). I’m interested in hearing other views.

Answer 1

The major problems with multicore programming is the same as writing any other concurrent applications, but whereas before it was uncommon to have multiple cpus in a computer, now it is hard to find any modern computer with only one core in it, so, to take advantage of multicore, multiple cpu architectures there are new challenges.

But, this problem is an old problem, whenever computer architectures go beyond compilers then it seems the fallback solution is to move back toward functional programming, as that programming paradigm, if strictly followed, can make very parallelizable programs, as you don’t have any global mutable variables, for example.

But, not all problems can be done easily using FP, so the goal then is how to easily get other programming paradigms to be easy to use on multicores.

The first thing is that many programmers have avoided writing good mulithreaded applications, so there isn’t a strongly prepared number of developers, as they learned habits that will make their coding harder to do.

But, as with most changes to the cpu, you can look at how to change the compiler, and for that you can look at Scala, Haskell, Erlang and F#.

For libraries you can look at the parallel framework extension, by MS as a way to make it easier to do concurrent programming.

It is at work, but I recently either IEEE Spectrum or IEEE Computer had articles on multicore programming issues, so look at what IEEE and ACM articles have been written on these issues, to get more ideas as to what is being looked at.

I think the biggest impediment will be the difficulty to get programmers to change their language as FP is very different than OOP.

One place for research besides developing languages that will work well this way, is how to handle multiple threads accessing memory, but, as with much in this area, Haskell seems to be at the forefront in testing ideas for this, so you can look at what is going on with Haskell.

Ultimately there will be new languages, and it may be that we have DSLs to help abstract the developer more, but how to educate programmers on this will be a challenge.

UPDATE:

You may find Chapter 24. Concurrent and multicore programming of interest, http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html