In Second Life the other day there was a session put on by Intel and Dr. Dobb’s Journal on parallel computing. I was a bit surprised how text language focused everyone was in their thinking on how to capitalize on multi-core development. I asked a few questions about Model Drive Development, but first had to explain what it was before the speaker could answer.
“The session featured Herb Sutter (Architect, Microsoft, and chair of the ISO C++ Standards committee) and James Reinders (Chief Evangelist and Threading Guru for Intel Software Products) on key issues and requirements for achieving the promise of parallelization. Preceding the Town Hall, Tim Mattson (Intel Principal Engineer, Designer of the 80 Core test chip parallel application and one of the creators of Open MP) will give a brief introduction on how Intel is managing the transition to a multi-core world.”
I’ve done some work in the past with some languages that supported parallel processing to some degree by their very nature (APL, LISP), and used some threaded environments (Java, .Net) but no experience with the newer languages (Fortress, Erlang). The text based approach really makes me wonder who can handle the complexity and for how long in a production environment. In the Coding Horror blog there was an entry about types of programmers. I agree with the foundational statement that 80% are viewing development as a job and 20% are viewing it as a passion. Most people cannot handle the level of complexity that these languages require – not during development, and definitely not during production support. Now that parallel processing is no longer the exclusive domain of High Performance Computing (HPC), other more accessible techniques will be required.
The only way I see out of this quagmire of complexity is via a model based approach, either using domain specific modeling that is more visual in nature, or other modeling techniques that are in the works. I’ve blogged before that I view most coding as moving to an assembly approach. Having parallel aware components that are assembled together visual seems to be a way of taking advantage of parallel while limiting complexity. Some of the components will need to be written by highly skilled personnel (much like drivers are today), but it should be a small portion of the effort required.
After I wrote this entry, I came across some similar concerns, from a slightly different perspective by Larry O’Brien in a column titled Blowing Bubbles.
I’ve been in a few meetings in Second Life before, but this was the first one I actively participated in, asking questions… Unfortunately, it was disrupted by storms on both coasts, so the speakers had to do most of their interaction via the cell phone.