Build it and they will come. Not!

Recently, I attended the TVS-organized conference “The Multicore Challenge II: Programming Multicore Systems” at the University of the West of England in Bristol, the second in a series of multicore-focused events. The program is online, and the presentations have been made available as well. I recommend Marco Cornero’s talk highlighting ST Ericsson’s adoption of multicore for mobile devices, as well as the OpenCL-focused presentation by the University of Bristol’s Simon McIntosh- Smith.

It was great to see well over one hundred people attend, all interested in the latest in multicore programming. It was not so great that most of the talks didn’t really reflect the title of the conference, except for perhaps the “challenge” part. Several companies are still approaching parallel programming from the ground up. They follow an “if you build it, they will come” approach, developing multicore silicon but not really addressing the software development problem of mapping applications onto such a complex architecture. As a result, software developers who need to parallelize their code for these platforms have a tough time, and they’re making lots of mistakes in the form of hard-to-detect bugs, spawning a new industry of multi- threaded verification software and multi- threaded debuggers.

There is a lot of activity in developing new programming languages and APIs that abstract away much of the parallel hardware complexity. Introducing new programming languages doesn’t address the problem we’re facing, however. The great majority of software development projects these days consist of integrating, porting and optimizing software that has already been written. Code re-use is almost a mantra: look at Android's 30 million+ lines of code, for example. Even this novel operating system took large chunks of its code from existing projects, such as Linux.

Considering parallel APIs, OpenCL and CUDA are thriving. These frameworks have the potential to unlock the major application speed-ups and energy consumption reductions that GPGPU and heterogeneous architectures can deliver. However, code that takes advantage of the APIs is significantly expanded and complicated. The performance improvements that will result from changes to the code are hard for programmers to predict and understand.

This is why I believe Vector Fabrics is following the right strategy. We bridge the gap between sequential software and parallel hardware, taking the unique approach of starting from a sequential point, where you re-use already developed code, and guiding you toward an efficient and correctly executing parallel implementation. Vector Fabrics’ tools are online, visual tools that do all the code and performance analysis for you, while keeping you in control of your parallel implementation at the same time.

The engine is the heart of a car and it provides the horsepower, but without the tools to unleash it, such as pedals and a steering wheel, it’s not of much use. Vector Fabrics gives you the tools to steer your system right where you want it to go.