next up previous
Next: Summary and Conclusion Up: An Adaptive, Fault-tolerant Implementation Previous: Programming interface improvements.

Related Work

  In recent years, an increasingly growing number of Java-based parallel computing systems have emerged [8,1,2]. Among these are systems with interfaces based on PVM, such as JPVM [9], and MPI, such as DOGMA [7]. Some of these, such as DOGMA and JavaParty [16], have already been successfully used in realistic parallel applications. Unfortunately, however, most of these systems use command-line Java applications, and thus still require some time and user expertise to set up. Making them use Java applets that can be run in a browser would be difficult or impossible not only because they require peer-to-peer communication not normally available to applets, but also because the semantics of the conventional message-passing models they use make it difficult to implement the adaptive load-balancing and fault-tolerance mechanisms required in the dynamic environment of applet-based volunteer systems.

A number of applet-based systems have also emerged, including Charlotte [3], Javelin [6], DAMPP [24], some RC5 cracking applications [11], and the original Bayanihan [17]. These are much easier to use than application-based systems since they allow a volunteer to join a computation by simply visiting a web page. Unfortunately, however, applet security restrictions and the need for adaptive parallelism and crash-tolerance seem to have so far limited applet-based systems to using ad hoc master-worker-based programming models that drastically limit the types of programs that one can write. Among applet-based systems, the most general and programmable one so far seems to be Charlotte [3]. Charlotte has a clean programming interface that provides transparent cache-coherent distributed shared memory between browser-based worker applets, while supporting adaptive parallelism in the form of eager scheduling. Its execution model is very similar to BSP in that computation is also divided by barrier synchronizations into superstep-like parallel blocks, and changes to distributed memory are not felt by other processors until after the next barrier. In addition, Charlotte has a fully-developed distributed caching mechanism that is still lacking in Bayanihan. Charlotte, however, requires defining a separate class for each superstep, and does not have message-passing functions.

The Bayanihan BSP interface bridges the two worlds of application- and applet-based parallel Java systems by allowing programmers to write programs using the flexible and easy-to-use remote memory and message-passing style found in peer-to-peer systems, while at the same time allowing these programs to be run in much more volunteer-friendly applet-based environments.


next up previous
Next: Summary and Conclusion Up: An Adaptive, Fault-tolerant Implementation Previous: Programming interface improvements.
Luis Sarmenta
1/19/1999