This section has emphasized the differences between ndb and
sequential debuggers since those are the interesting features from the
implementation standpoint. On the other hand, from the user's view, the most
striking success of the tool is that it has made the debugging process so
little different from that used on sequential codes. This can be
traced to the loosely synchronous structure of most (C
P) parallel
codes. Debugging fully asynchronous parallel codes can be much more
challenging than the sequential case.
In practice, users have to be shown only once how to start up the debugging process, and be given a short list of the new commands that they might want to use. For users who are unfamiliar with the command syntax, the simplest route is to have them play with dbx on a workstation for a few minutes.
After this, the process tends to be very straightforward, mostly because of the programming styles that we tend to use. As mentioned in an earlier section, debugging totally asynchronous programs that generate multiple threads synchronizing with semaphores in a time-dependent manner is not ndb's forte. On the other hand, debugging loosely synchronous message-passing programs has been reduced to something of a triviality.
In some sense, we can hardly be said to have introduced anything new. The basis on which ndb operates is very conventional, although some of the implications for the implementation are non-trivial. On the other hand, it provides an important and often critical service to the user. The next section will describe some of the more revolutionary steps that were taken to simplify the development process in the areas of performance analysis and visualization.