Explicit Implications of Cluster Computing
A hard to swallow conclusion from the table of cluster.
Thursday, June 15th, 2006
A confession is in order. The last two installments of “Cluster Rant” have been a sales pitch of sorts. If you believe some of the things I talked about — large clusters will break, applications must both tolerate failure and be easy to write — then you may agree that dynamic programming algorithms are one workable solution.
The next question is, how do implement these ideas?
The answer is the part many may find distasteful. If you are one of the brave few who take pause to think about how we are going achieve pervasive cluster computing, then take a bite of this column. The rest of you weenies should at least nibble at the edges.
SUBHEAD Think About It
Figure One summarizes the current state of parallel programming. It describes what programmers tend to think about at various stages of writing, compiling, and running programs. Certainly, other things can be added, but you get the idea.
Additionally, compilers for sequential applications do a fair amount of optimization, scheduling, and communication for a single processor. In a parallel environment, these issues are often too difficult for the compiler to handle, and the work is instead shifted to the developer. Indeed, parallel programming is hard because the programmer must manage many more interconnected parameters.
