Cameron and Tracey Hughes

Dr. Dobb's Bloggers

Blackbox Parallelism a Hoax?

August 13, 2009

Once a software paradigm has reached a certain level of saturation and it is understood enough, some vendor is going to produce a template or a commercial framework that captures some of the key basics of that paradigm in a box or in a easy-to-use set of tools. At that point that entire software paradigm is considered solved.

Once a software paradigm has reached a certain level of saturation and it is understood enough, some vendor is going to produce a template or a commercial framework that captures some of the key basics of that paradigm in a box or in a easy-to-use set of tools. At that point that entire software paradigm is considered solved.

Graphical user interfaces, database applications, web applications, and many server applications all have their in-a-box versions. It helps speed application development if I can use a tool that produces a fully functional graphical user interface for me (with very little effort). If I can pick a database application template that can be quickly and easily filled in by my business rules, so much the better. These days don't even think about going into business until you've grabbed one of those website in-a-box deals. Fortunately, this all works to some extent. If you can force fit your software needs into one of the saturated software paradigms you're in luck. Chances are there are software tools, canned software frameworks, and in-a-box versions that you can use to realize your application in no time.

Some vendors (won't mention any names) even argue that regardless to what your application needs are they have a framework, tool set, or in-a-box version for you. Although we're not there yet, we're trying to get there with multicore and parallel programming. But what happens if your software needs don't fit the flavor-of-the-month? For some reason, Tracey and I are rarely that lucky. In fact we haven't been that lucky in a long time. The problem solutions that we have to put to software typically defy the pop norm. We get stuck a lot doing bare knuckle computer programming. This is especially the case with all of this multicore programming. We wish that we could take advantage of some sort of blackbox parallelism that would make our parallel software solutions a no-brainer. The idea that we could develop a single-threaded application that could be converted to multicore by some convenient level of software between our application and the operating system is very seductive. But our situation requires parallelism, and sometimes even massive parallelism at the problems solving and design level. Ahem...? Yep, we need to know whether the concurrency requirements are being met at the design level long before we hit any blackbox parallelism. What does one do when the solution model doesn't fit into the flavor-of-the-month vendor solutions?

Some argue that programming multicores is an implementation detail and that designers, and in most cases software developers, shouldn't be worrying about the details of parallel programming, synchronizations, deadlocks, etc. All that is required is that we pick the right toolset and parallelism will take care of itself. Unfortunately this greatest common divisor approach works for mass produced software. It's convenient for vendors who market to the low hanging fruit. It doesn't address those of us who have to develop multicore tools, device driver writing business, or who have to vectorize graphics applications or who have solve the parallel problem at the design level. Figure 1 shows where blackbox parallelism might fit in two separate scenarios.

The developers who have problem/solution 1 are in luck they are able to develop a single-threaded application and be comforted by the fact that blackbox parallelism will do the work converting there application level into multiple threads. But what about the second scenario? Will the solution model that requires model specific parallelism be well served by blackbox parallelism? Will the blackbox parallelism conflict with the solution model parallelism? Should developers even care? At the end of the day, the operating system decides when and how many cores or processors an application gets right? Isn't the operating system supposed to make hardware details and specifics transparent? If the solution model requires parallelism and therefore requiring the software design to include parallelism, how does the group that is doing the actual coding get away from implementation details? At this very moment we are up to our necks in a project that has significant parallelism/concurrency requirements. As we see it right now, there is no way to hide the complexity of coding for the parallelism. We see no way that we could even approach this without having the solid background in software engineering and computer science that we have. We see absolutely no short cuts. Beyond a few commonly used bread-n-butter application models, we're starting to wonder is blackbox parallelism a hoax. We do know that we cannot apply the blackbox approach to our AI-complete problems. Maybe it's working for you.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!