Parallel programming patterns
Today we discussed three pattens from the pattern language that I'm working on with people from Berkeley. I think all three were written by Berkeley grad students. However, they are based on patterns from the book "Patterns for Parallel Programming". They all from the parallel programming strategies section, Task Parallelism, Recursive Splitting, and Discrete Event. I started off writing this before class, and am finishing it afterwards.
I thought they were all badly written. They are too abstract. There are not enough examples. There are a lot of unnecessary words. It was hard to see the pattern.
Patterns should start with a good example. None of these did.
I thought Recursive Splitting was the best of the group. I knew the pattern beforehand, of course, but I knew all of them. It suffered from using a programming language that nobody understood for the first example, but it had lots of examples. The problem was well-stated, and it covered the important topics. From our class discussion, it was obvious that a lot of the points were not as clear as they should be, but that is typical.
Patterns should start with simple and obvious examples, and move on to more complex ones. The first example of a recursive data structure in this paper was "array". Only to a mathematician! Most programmers do not think of array as recursive, and the paper should have started with an obviously recursive data structure like trees. Even graphs are not naturally recursive.
Part of the problem with Task Parallelism is that the pattern in the book isn't very clear, either. This is a broad and fuzzy pattern. When most programmers say "Task Parallelism", they mean something different from this pattern. I'm starting to think it is just a bad pattern, and should be replaced. I'm sure that the grad students who worked on this tried valiantly to pull it off, but it just doesn't work. I liked the example of Monte Carlo Method, but the students didn't resonate with it. Several said they wanted code. But I know that even if they understood the example, they would not have understood the pattern.
I think the pattern should be replaced with "Embarrasingly Parallel". This is a well-known term with a well-defined meaning. The pattern could talk about how even the easy cases of parallelism are not easy. You have to choose grain size and figure out how to start processes. Usually the rsults have to be combined in some way. Currently, Task Parallelism is more than just embarassingly parallel, it slides off into systems with enough dependencies between tasks to put them in a different category, but that is why the pattern is so fuzzy. Make it crisp! Narrow the pattern! Patterns should not be all things to all people, they need to be specific and identifiable.
Discrete Event is schizophrenic. When I was reading the first part, I thought "actors / asynchronous message passing" but then when I read the example, they said "discrete event simulation". Discrete event simulation is not the most obvious application for an actor system. Usually discrete event simulation has a global clock, and replacing it with a distributed clock is highly non-trivial. The other people in the discussion thought that the pattern WAS about message passing, so I have decided that the problem with this pattern is that they chose a bad example.
There is hope for these patterns. Everyone in my class this semester is going to write a pattern (or a dozen patterns, in some cases) and the first drafts of many of them will be just as bad. It is important to keep at it, and to not stop until the pattern is done. These aren't done yet.
