DELAGI@SUMEX-AIM.Stanford.EDU (Bruce A. Delagi) (06/06/88)
The Knowledge Systems Lab at Stanford has developed a simulation system built on the idea of putting together pieces of a kit to produce a well instrumented simulation of a multiprocessor design with a given applications language interface. We've run a range of mid size programs [not toy but not production "expert systems", partial differential equation solvers, and circuit simulators] on it to understand their performance on multiprocessor designs including up to a few hundred processors. The applications language interfaces include support for concurrent object oriented programming, shared variables, and functional programming. The first of these approaches is our favorite and has received the most attention. The others are there for comparison purposes -- so the performance consequences of choosing one of these styles can be studied. Other language interfaces can be constructed out of a set of operational primitives provided. The multiprocessor "components" represent detailed models with respect to communication facilities and quite course models with respect to any purely uniprocessor operations. In fact, the latter are executed directly on the machine performing the simulation, timed [excluding page faults and the like], and the time factored to represent the performance of the simulated design relative to the performance of the machine running the simulation. The computed time is used to determine the time between communication events. Passing messages or manipulating shared variables result in communication events. With this approach, we have been able to study the performance of applications doing a reasonable approximation to real work within acceptable wall clock times. Since the simulation system itself is written in an object oriented language [with good performance], all component models in the library we provide can be specialized to do something "almost the same but different" as desired by the model designer. Components can be composed into higher level designs and those designs placed in the library as components --- and specialized as desired. Manual component composition is based on a graphics editor and is completely flexible. Additionally, automatic composition operators are provided for grids, toruses, busses, and hierarchial busses. We went for *really* flexible instrumentation since, as became clear to us, our ideas about what to measure evolved rapidly as we looked at what was reported to us based on our previous ideas of what to measure and how to present it. We have stock presentations [panels] for bar charts, strip charts, histograms, point plots, line plots, scrolling bar charts, and text panels. These are specialized for additional vertical axes and the like. Then the specialized panels are connected to ``probes'' which report current activity for the [type of] components they are hooked to. Arbitary functions may be used to transform the information reported by probes so as to be usefully presented by panels. These probe-panel-tranformation compositions are also specializable entities. All the specialization and composition is done when a simulated design is loaded rather than when it is run so as to not impact run time performance. Well, this has gone on too long -- reports are available for more detail................/bruce -------