Path: utzoo!attcan!utgpu!watmath!iuvax!cica!gatech!hubcap!reiher From: reiher@amethyst.Jpl.Nasa.Gov (Peter Reiher) Newsgroups: comp.parallel Subject: Re: Determinacy Issues in Parallel Programs Keywords: determinacy parallel programming Message-ID: <6288@hubcap.clemson.edu> Date: 18 Aug 89 15:53:46 GMT Lines: 57 Approved: parallel@hubcap.clemson.edu In article <6280@hubcap.clemson.edu> dinucci@cse.ogc.edu (David C. DiNucci) writes: >In article <6243@hubcap.clemson.edu> boulder!boulder!adamb@ncar.UCAR.EDU (Adam 'Velvis' Beguelin) writes: > >>If the program was determinate you would know that errors produced by >>the program were not an artifacts of race conditions in your program. . . . >He/She needs nondeterminism if maximum performance is desired from a parallel >computer, and most people would agree that this is kind of important. Our work on the Time Warp Operating System (TWOS) has demonstrated two levels of determinism. TWOS runs event-driven simulations on parallel processors, using an optimistic model with rollback and message cancellation for synchronization. We demand deterministic results from the execution of the simulation itself. TWOS permits the use of no language constructs that would knowingly lead to non-determinism, such as reading the system clock. But we do not demand that TWOS proceed deterministically in getting there - in fact, our methods practically guarantee that it won't. A non-deterministic answer is only useful if you can guarantee how far off it is, so that you can determine if it is in the reasonable range of correct values. If proper care is taken with round-off errors, etc., one can say something about how far off the answer could be. Being incautious with synchronization of events is much harder to quantify. The implications for debugging should be that the user can count on determinism from his program, and can debug accordingly. Of course, TWOS is an experimental system, so it's still got its own bugs, some of which cause non-determinism. Also, lacking the necessary hardware support, TWOS currently has no memory protection, so a suitably incautious user can tromp on anything; one result can be non-determinism. Still, when we get non-deterministic results, we usually find the problem in the system. Determinism makes debugging much easier for the users. I don't think that determinism is costly for our system's performance. We're getting pretty good performance, given the fundamentally difficult nature of the problems. Of course, the determinism is limited to the committed results of the users' programs, so we do not pay the performance cost for making the actions of TWOS itself deterministic. That cost would be immense. >The goal is to >compute the one that can be computed the soonest, subject to the availability >of the input data, the temperature of the machine room, the activity on >the disk drive, etc. Unless you wish to build all these parameters into >a function, you are going to need the ability to write non-deterministic >programs. Or the operating system can mask these effects, as TWOS attempts to. You may pay some performance cost, but our experience suggests that, for at least one important class of programs, the performance is still quite good. Given that deterministic programs are easier to deal with than non-deterministic programs, you've got to balance what you pay against what you get. Peter Reiher reiher@amethyst.jpl.nasa.gov (DO NOT send to reiher@amethyst.uucp) . . . cit-vax!elroy!jato!jade!reiher