Development tools are vital to multicore threading efficiency

The trend toward multicore processors spans a wide variety of applications, from PCs to audio-video gear, to cellular network infrastructure and automotive electronics. It's not hard to see why: As applications require more processing power, simply increasing a DSP's megahertz no longer is a viable solution because of the power required and the heat produced. Multicore DSPs avoid that problem by spreading the workload over multiple cores.

For example, if the system requires 3 GHz worth of performance from a DSP, a multicore architecture could have three cores running at 1 GHz each, all in a single DSP package. But at the same time, the multicore DSP has lower power requirements and produces less heat than a single-core DSP. Those benefits are among the reasons why Texas Instruments alone has shipped more than 1 billion multicore DSPs.

Although no one is arguing about whether multicore processors are here to stay, there is some debate about threading, which is the process of dividing a program into multiple tasks—or threads—that run in parallel.

Here we offer what the debate is all about:

Alan Gatherer, CTO of TI's Communications Infrastructure Group on:
New ways of thinking about threading
As a child my mother would knit while watching television. Though I never learned to do it myself I did appreciate the importance of careful counting. If one stitch too many was added due to a lack of concentration during a particularly exciting episode of Dr. Who, then the pattern would not line up. Even worse, the mistake might not be found until much later in the process and finding exactly where the extra stitch occurred involved carefully unraveling until you found it.

So my mother, who only recently started using a computer, taught me at an early age that just one thread out of place can ruin a whole sweater, and when you have a lot of threads, debug is a nightmare.

In the early days of circuit design a similar problem, where systems developed using many, many circuit components often failed, was called the "tyranny of numbers." If you have enough little things put together, something is bound to go wrong.

It was this problem that led TI's Jack Kilby to the development of the first integrated circuit. It seems that with the advent of serious multicore we are facing a similar situation and we may need a new Jack Kilby to solve this problem for us again.

Until a new Jack comes along it looks like we are stuck carefully knitting threads together. Like my mother, we need to count carefully and keep a close eye on the pattern we are trying to create. Breaking a problem into more threads than it really needs is asking for trouble and some authors have even suggested that threading is the root of the problem in multiprocessing today.

But assuming threads are here to stay, and that the number of threads a system supports will increase significantly, a multiprocessing system is going to look less and less like a collection of threads and more like a piece of material. If we do not learn to create, visualize, and debug at the sweater level, but instead continue to deal with the individual threads we will not be able to knit ourselves anything worth wearing.

The good news is that companies such as TI are developing tools that help designers accommodate the growing number of threads. Many baby steps have been taken, both in the tooling that is used to create the system and in the runtime software and hardware support that manages and allows visibility and virtualization of the threads as they run.

Message passing abstractions, standard thread communication APIs, semaphores and memory locking mechanisms are all examples of ideas that make multithreaded programs more robust and manageable. OpenMP is a great example of a programming paradigm where the user describes the parallelism that is possible rather than making explicit decisions on the threading model that will be used.

By stepping back from managing the details of the threading model the user is free to create more complex and more parallelizable systems. The optimal parallelism strategy may not be the "natural" or obvious one and researchers have proposed compilers that search the space of possible parallel strategies to find the best one (see this University of California at Berkeley paper). This obviously requires the user to let go of managing the threads. However, as the level of abstraction increases, debug of the system becomes more of a challenge, especially in the kinds of real time systems that TI and its partners often deal with.

So it is an exciting time to be in the world of multicore and multithreading. The challenges and opportunities are many, and little by little we are making progress while we wait for the paradigm shift that will change the industry. Who knows, now she is using a computer, maybe my mother has a good idea or two!

Bill Mills , CTO for Open Linux Solutions in TI's Software Development Organization on: Development tools
I think the solution to Alan's situation is simple: He should get his mother a sonic screwdriver. As the good doctor has proven over and over this tool can solve just about any problem. However as we wait for this fantastic tool to be invented, I find the tools I have today to be very useful. I still use a pair of pliers that were handed down to me from my grandfather. Sure the yellow paint is half off but they still aptly perform the function they did for my Dad's Pop.

When it comes to programming tomorrow's massively multicore processors the question is what programming model will we use? Do we need an evolution or a revolution? Will we continue to use our trusty existing tools or do we need something completely new?

View a full-size image