For The Love of Multi-Core Pain - Page 2

Page 2 of 2

Q: What specific challenges must developers overcome when dealing with multi-core programming?

McCool: When people try to program to multi-core processors today, they'll typically approach it from multi-threading. They might take your application and chop it up into different chunks, running a chunk on a different core and have them communicate. There are problems with this.

Michael McCool

If the number of chunks is a constant, if you get a new processor with more cores, you're not going to be able to take care of the additional cores. You have to have a structure that lets you grow performance with additional cores.

There are also problems with subtle bugs, synchronization, raised condition and deadlocks, which are very hard to find. This makes programming a real challenge.

Also, when you look at the Cell, the GPU, or even multi-core CPUs, to get good performance out of these machines, you have to dive down and understand the individual processors. You end up getting locked into a particular processor for a high-performance application. This is a real problem, because applications have a much longer lifespan than processors.

A given application is going to run on five or six processors over its lifetime. If you sacrifice portability to get performance, you then have to redo that work around your processor, and that results in huge overhead. Not only is it more complicated to go down to the level, but you have to do it again and again for each processor.

Q: How does your revised Rapid Mind Platform v2.0 help alleviate the multi-core programming pains?

DePaul: Our platform gets embedded in their software. A typical use would be, somebody has an application on their workstation. And it runs on their Windows and Intel CPU. But there is an aspect to that application that is a bottleneck.

That software company would come to us and say they'd like to accelerate that part of the application. They'll use our APIs to support those functions, and we will offload that work to a GNU or to a Cell. So that software vendor can tell their customers that if they install a $600 GNU video card in that workstation, that slow part of the application will get a 10x performance improvement.

McCool: Our benefits can be summarized in programmability, performance and portability. The conceptual model the programmer uses is platform-independent. They can write code and then run that on a number of processors. We can decouple the hardware it runs on from the logic of the application.

We spent a lot of time trying to make this as simple and as easy to use as possible and widely applicable. It is a single-source application -- you can use your existing compiler. The same model you use is for single-threaded development so it's very easy for users to adopt it.

It also avoids the problems of raised conditions and deadlocks that plague multithreading. You typically can't write an application that has these problems.

Q: What processors are you supporting with v2.0?

McCool: With Platform 2.0, we'll be shipping with Nvidia and ATI GPU support, and we also are going to have Cell/B.E. support with multiple form factors, including the IBM Cell blade and the PS3. And we also have a preliminary prototype for Intel and AMD multi-core CPUs.

Q: Any plans to support Sun's Niagara or Rock processors?

DePaul: We've been to a few shows, where there's been as many processor vendors coming to our booth as there were customers. So, there's tremendous interest in adding support for a lot of those processor companies.

We'll go where the market takes us and there's nothing, given the modularity of our architecture, to add support for new processors. In the end it doesn't impact the developers at all, so we'll do what the developers and ISVs tell us.