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