|
The first problems addressed in large scale parallel environments
were "unconnected problems". Imagine taking a large object and decomposing
it into smaller pieces, then doing something individual with all of the
pieces. In fact, just for example, imagine the task of
taking a large boulder and turning it into sand.
You could tackle this job in a serial fashion, just whacking the boulder
and all of its broken off chunks into smaller and smaller pieces.
You could even decide on a "breadth first" approach -- whack all of the
chunks of the same size, then all of the next size, and so on;
or you could pursue a "depth first" approach --
whack smaller and smaller pieces, never moving to a larger piece until
you've reduced something to sand.
Once you've considered the serial approach and the amount of time it
would probably take you, you then consider the parallel approach (i.e.
the grid method). First you partition the problem (you whack the original
boulder into some number of semi-large chunks), then you distribute the
"sub-tasks" to a set of workers (your friends, to whom you've promised
a reward for participating in your experiment). Your friends start
whacking away (and possibly further divide their tasks by passing out
pieces of their original chunk to their friends -- Tom Sawyer would be
proud). Notice that each boulder reducing operation
is completely separate from the others. And, if one worker stops or slows
down, that does not affect the rest of the group (any one of the workers
could continue the work if someone stopped on their own piece).
SETI@Home
is very much like this (if you can imagine that your first whack of the
problem was a large pile of pea-size gravel).
There's a pile of work to do -- a large
collection of individual jobs. As computers become available, they
take a piece of work off the pile, compute it, then put back the answer.
If they can, they take more work. It's a simple and powerful model.
There are lots of projects like this, but some that we're more
familiar with are these:
| 
