Did You Just Call me a 'Programmer'?

You can get five programmers in a room to give you six different definitions of parallelism. I've been in situations where a bunch of programmers were throwing the terms "parallel programming" and "multithreading" around assuming that they were all on the same page. I have to be careful because these days even the term "programmer" carries a certain amount of controversy, depending on the company one keeps.

I guess we would still get the multi-definition result for parallelism if we were talking about five "software developers" as well. I reckon I really mean those folks who actually write the code whether we call them developers or programmers.

There is a tendency to forget that not every one does the same kind of software development that you do. So when we talk about the problems of parallel programming and the impending paradigm shift required to take advantage of massive multicore, we have to discriminate between the levels and layers of parallel programming. If I'm writing a device driver for a multicore graphics chip, that's a very different kind of parallel programming than if trying to deal with a multi-user ATM banking application. The real-time concurrency requirements of the multi-user banking application is a far cry from what the developers are facing when dealing with multi-user, multi-transaction, web containers. Depending on where you're at in the software development jungle you may see the parallel programming/multicore dilemma very differently than someone else located in a different jungle space. Tracey and I are guilty of trying to characterize our intersection with parallel programming as the domain level problem solving variety. It can seem murky if you're not quite clear what we mean.

Figure 1 is one (we have others) rough overview of the layers of parallel programming that we've encountered on our trek toward the ultimate concurrency. The person doing work at Level 5 in Figure 1 sees the multicore issue very differently than the person doing work at Level 3. When we talk about a dramatic paradigm shift being necessary in order to truly navigate massive multicore, we have to be context specific. Do we mean a paradigm shift at the hardware level, instruction level, operating system level, etc.? If you follow this multithreading stuff closely there has been advancements at various levels. But at which level in Figure 1 are we all referring to when we suggest a dramatic change in thinking is needed?

Our goal of getting the computer to truly answer the question:

Which tastes better coke or pepsi?

requires massive parallelism at Level 1. Without massive parallelism at Level 1, the computer doesn't stand a chance of answering our question, if indeed it can answer the question at all. The problem is that at Level 1 most programmers (whoops, I mean "developers") have been indoctrinated to think and solve problems in a linear and sequential fashion. Our notions of space and time are based on the story-telling-model where everything has a beginning, middle, and end. Especially our computer algorithms. And herein lies the rub.

Tracey and I are applying lessons learned from the ghosts of ICOT to what we believe is a paradigm shift for Level 1. A story that prefers a recursive spiral to the notion of beginning and inductive rings to the notion of ending and complete abandonment to the once-upon-a-time-model. Complexity, problem solving, search, path finding, reasoning, and massive multicore all have a rendevous with destiny at Level 1. Level 1 is where Tracey and I plan to catch the notorious and evasive snipe.