One of the main goals for people who use computer systems, particularly computational scientists, is speed. In the quest for ways to make applications run faster, engineers have developed parallel computers, which use more than one CPU to solve a task. However, many institutions already posses significant computational power in networks of workstations. Through software, it is possible to glue together clusters of machines to simulate a parallel environment. SPEDE is one such system, designed to place the potential of local machines at the fingertips of the programmer. Through a simple interface, users design computational objects that can be linked and run in parallel. The goal of the project is to have a small portable environment that allows various types of computer systems to interact. SPEDE requires no altering of the kernel and does not require system privileges to use. Using SPEDE, programmers can get significant speedup for computationally intensive problems. As an example, a Mandelbrot image generator was implemented, that attained a five-fold speedup with eight processors

Gochee, James

English

Dartmouth Digital Commons (Dartmouth College)

Dartmouth College Dartmouth Digital Commons Dartmouth College Undergraduate Theses Theses and Dissertations 1-1-1992 SPEDE: Simple Programming Environment for Distributed Execution James Gochee Dartmouth College Follow this and additional works at: https://digitalcommons.dartmouth.edu/senior_theses  Part of the Computer Sciences Commons Recommended Citation Gochee, James, "SPEDE: Simple Programming Environment for Distributed Execution" (1992). Dartmouth College Undergraduate Theses. 168. https://digitalcommons.dartmouth.edu/senior_theses/168 This Thesis (Undergraduate) is brought to you for free and open access by the Theses and Dissertations at Dartmouth Digital Commons. It has been accepted for inclusion in Dartmouth College Undergraduate Theses by an authorized administrator of Dartmouth Digital Commons. For more information, please contact dartmouthdigitalcommons@groups.dartmouth.edu. - 1 -SPEDE – A Simple Programming Environment forDistributed ExecutionJAMES GOCHEESenior ThesisDepartment of Math and Computer ScienceDartmouth College, 1992One of the main goals for people who use computer systems, particularly computationalscientists, is speed. In the quest for ways to make applications run faster, engineers havedeveloped parallel computers, which use more than one CPU to solve a task. However,many institutions already posses significant computational power in networks ofworkstations. Through software, it is possible to glue together clusters of machines tosimulate a parallel environment. SPEDE is one such system, designed to place thepotential of local machines at the fingertips of the programmer. Through a simpleinterface, users design computational objects that can be linked and run in parallel. Thegoal of the project is to have a small portable environment that allows various types ofcomputer systems to interact. SPEDE requires no altering of the kernel and does notrequire system privileges to use. Using SPEDE, programmers can get significant speedupfor computationally intensive problems. As an example, a Mandelbrot image generatorwas implemented, that attained a five-fold speedup with eight processors.IntroductionWith the advent of parallel computing, users have been able to achieve significant speedupof computationally intensive applications. Parallel machines can be quite expensive, soresearchers have looked to clusters of workstations as an alternative. Through software, machineson a network can be linked together, forming a virtual parallel computer. SPEDE (SimpleProgramming Environment for Distributed Execution) is a tool for UNIX programmers whowant to write parallel applications that run on clusters of workstations. Because of the diversityof machines found at many sites, including Dartmouth College, SPEDE is designed to allow aheterogeneous group of machines to work together. SPEDE is a user level system, meaning nosystem privileges are needed for installation or use. This is admittedly redundant, requiring eachuser to run the entire system separately, but has many advantages. SPEDE uses only UNIXfacilities that are universally available to the average user. For instance, SPEDE requires everyparticipating machine to run a special daemon. This daemon is executed via the UNIX remote- 2 -execution facility (rsh). This allows the daemon to be quickly started and stopped withoutmodifying the kernel or using privileged facilities. In this paper, the term session is used todescribe an interaction with SPEDE that lasts as long as any remote entity is running. When allprocesses associated with SPEDE have been terminated, the session is finished.OverviewThe main data type in SPEDE is the object. Objects can be thought of as black boxes thatcommunicate with each other by passing messages. No global variables are shared betweenobjects. During a session, objects can be run in a heterogeneous environment, as long as eachobject was pre-compiled on each type of machine. To UNIX, an object is a fully executableprogram that runs as a normal process. Programmers connect their objects together through well-defined callback routines that interface to a SPEDE library. Objects can pass simple messages, orthey can pass messages that wait for a return message, either synchronously or asynchronously.Return messages are the result of a remote invocation. Messages are delivered in the order theyare sent, which is guaranteed by the underlying data transport mechanism (UNIX streamsockets).What SPEDE is not is an interactive environment. It only runs when a user's application isrunning. This avoids leaving processes associated with SPEDE running in the background,consuming resources on other users' workstations. SPEDE is a user level environment and shouldhave as little impact on other people's machines as possible.Related WorkThere are several varieties of distributed systems, ranging from process-orienteddistribution [3], to object-oriented distribution with a custom operating system [1], [2]. Mostsystems are somewhere between the two. These "mixed systems" offer finer-grained distributionthan a user's process, but they do not usually work with the kernel itself. Instead, they sit on topof the kernel and use a run time model other than a UNIX process, such as an object. Systems of- 3 -this type include Mentat[4], Linda[5], and SPEDE. Remote procedure calls [6] can also beconsidered in this category, although they are only part of an integrated environment (forexample, they do not support remote process execution).Linda [5] is a unique distributed environment because it uses a much different paradigmthan the object model. Instead of one machine telling another what to do, remote machines thatare idle join a pool of free processors. The system can then assign a machine any work that needsto be done. Work is defined as a tuple, composed of a name and data. These tuples are managedin a tuple space. Machines can take tuples out and put tuples in. The idea is that a tuple is takenout to be processed, and put back in when a result is found. This is clearly different from SPEDE,which is based on objects sending messages to other objects. While the tuple-space model ispowerful because of its simplicity and abstractness, performance may be limited due to thecomplexities of managing the tuple space.Mentat [4], on the other hand, uses an object-oriented paradigm based on the C++programming language. Language extensions to C++ allow the system to handle remotecommunication and synchronization. For instance, after a remote invocation, the caller does notblock until the return value from the invocation is needed for some computation. Mentatmanages this by creating a dependency graph at compile time that is used at run time todetermine when variables are referenced. This is convenient, freeing programmers fromworrying about synchronization and message passing. Mentat was the original inspiration forSPEDE because of its object-based model. While SPEDE is not as complete as Mentat, it doesallows programmers to have more control over message asynchronicity. Also, SPEDE does notrequire C++, does not require read privileges on the kernel, and does not require a new compiler.Remote procedure calls, while not in the same class as Linda, Mentat, or SPEDE, allowdistributed processing and therefore should be mentioned. Normally, the RPC mechanism allowsa function to be executed on a remote machine with the same syntax of a local procedure call.The local machine blocks until the remote function is finished executing. While it is sometimespossible to perform asynchronous RPC calls, the interface is difficult to work with. As a result,- 4 -many systems use RPC as an underlying mechanism, providing other paradigms, such as objects,as the programmer's interface. Mentat in fact uses RPC to accomplish message passing betweenprocessors.SPEDE's method of communication between remote entities is message passing. Messagepassing is conceptually simple and allows asynchronous activity. One drawback with messages isthat the C interface for programmers can be awkward. To help with this, SPEDE supports bothsynchronous (RPC-like) message passing and asynchronous message passing (by sending amessage and specifying a callback function to be used when a return message comes back).The SPEDE ArchitectureSPEDE has three major components. The first is a name service (REG), which keeps trackof resources (processors, objects) being used by SPEDE. The second is a remote daemon(DEAN) that must run on every participating machine. The third is the set of objects which theuser creates and runs on clusters of machines. The entire system can be started and stoppedrelatively quickly, and it is designed to be running only when the user's objects are running. Thisis different from many systems which must be installed at system boot time and remain in thebackground for the life of the machine.The backbone of a SPEDE session is the name service called REG. REG is responsible forkeeping track of the set of remote machines that are able to participate in a SPEDE session, andthe DEANs and objects that are currently running. Ideally, REG would run on a well-knownUNIX port number, on a stable machine. This is so that REG would be easy to locate. However,due to the user-level nature of this project, I decided not to require that REG have a fixed portnumber (which requires a system administrator to install). As a result, objects need another wayto find where REG is running. DEANs that are started by REG are given this information as acommand-line argument. The difficulty is an object started by the user, at the command line. Ifthe object is on the same file system as the REG, it can read a special file in the user's home- 5 -directory, written by REG when it starts. Otherwise, the object has to be specifically told thename of the machine and the port where REG can be found.Machines that participate in a session must run a daemon process called the DEAN. TheDEAN sits on a UNIX stream socket waiting for objects to connect. Objects that connect can askthe DEAN to create or delete objects on that machine. All messages which go to objects on amachine pass through the DEAN, which allows DEANs to trace all message traffic. In the future,this indirection could be used to migrate objects and to support fault tolerance. DEANs arestarted automatically by the name service (REG) in response to a request from an object thatneeds to communicate with remote machine. Also, DEANs terminate after 10 minutes of beingidle. This prevents them from lingering in the background after a user has finished running anapplication.Objects in SPEDE are programs constructed by a programmer and linked into a SPEDElibrary. The library handles tasks such as inter-object communication and the creation anddeletion of objects. The object's program must be compiled on every type of machine that isgoing to participate in a SPEDE session. Compiled objects are placed in a well-known directoryso that they can found by the DEAN, which performs a fork and exec to run the object. Once anobject is started, it connects with the local DEAN to inquire about why it is running (The DEANis found by asking REG). Objects are started either when other objects create them or when theuser runs an object from the command line.SPEDE relies on UNIX stream sockets for all communication. The decision to use streamsockets rather than datagram sockets was primarily made in light of the time constraints placedon the project. Stream sockets are easy to use and are excellent for transporting large amounts ofdata from one point to another, but they have problems when used in an environment likeSPEDE. The biggest problem is that stream sockets are implemented as file descriptors and everyobject that connects must have a separate socket. Most machines only allow a process to have 50or 60 sockets open at a time, which limits the number of objects that can be use. Anotherdrawback with stream sockets is the high overhead cost for sending small amounts of- 6 -information. Datagram sockets may be better for SPEDE, supporting an unlimited number of"connections" and better handling small messages. Then again, datagram sockets do notguarantee packet delivery, so an error checking mechanism would have to be added.One interesting implementation aspect of SPEDE is the way DEANs and objects deciphermessages. Every message has a sender reference number and a receiver reference number. Thisreference number is used to distinguish the objects that are communicating, much like a uniqueID number. However, these reference numbers are actually pointers into the DEAN's memorywhere an object structure is stored. When a message is received, the reference number of thereceiver is used as a pointer to directly find the information for the object being addressed. If thereference number is not a valid pointer, then a segmentation fault occurs when the false addressis referenced. The alternatives, a hash table or list to map valid ID numbers into objectinformation, is more secure but incurs overhead to perform the look-up. Given that SPEDE canonly handle 50-60 objects at most (due to the limits of stream sockets), a simple indexed arraywould have sufficed. However, SPEDE was originally designed to handle many more objectsthan the UNIX limitation imposes..ResultsTo test the system, I wrote a program which generates Mandelbrot images. I then recordedaverage run times for a sequential version and a parallel version of the program. The parallelversion has a single master process and P worker processes running on other machines. Theparallel version was run using the same hardware type (DECstation 5000) at a time of day whenthe machines were under light load. Nevertheless, all data that is presented is an average time andis under the influence of slight variations in the load of machines and the congestion of thenetwork.Shown in Figure 1 is a graph of execution times for a Mandelbrot image generator. Theimage generator was implemented both as a stand-alone sequential version, and a parallelSPEDE version. Actually, the SPEDE version was not completely parallel because the collector- 7 -object that displayed the final image segments, collected from computational objects, wassequential. The lines on the graph show the run times of the two versions of the program with thetime for the parallel version shown with and without startup time included. The horizontal linerepresents the sequential execution time, where the image was generated without using theSPEDE system. The "Startup Included" line shows the parallel execution time including all start-up costs. The "Steady State" line shows the parallel execution time if start-up costs were ignored.Execution Time of Mandelbrot       Number of Nodes, PSeconds051 01 52 02 51 3 5 7 9Steady StateSequentialVersionStartup IncludedFigure 1There are a couple of things that are apparent from Figure 1. The first is that executiontimes decrease with P, if the initial start-up costs are ignored (i.e., timing the system in the steadystate). On the other hand, if start-up costs are included the run time bottoms out at 6 nodes andbegins to increase, although it is better than sequential. This is clearly a problem with the SPEDEsystem that could be improved by creating objects in parallel instead of sequentially, as in thecurrent implementation.- 8 -Figure 2 shows the speedup achieved using the same data as in Figure 1. Linear (perfect)speedup is represented by the straight line, while the other two lines show speedup of the SPEDEversion with and without startup costs. Once again, it is clear that the start-up costs areexpensive, since speedup starts to decrease after 6 nodes. On a positive note, speedup in thesteady state is reasonable.Speedup of Mandelbrot     Number of Nodes, PSpeedup Factor0123456781 3 5 7 9Steady StateLinear SpeedupStartup IncludedFigure 2Future WorkThere were two possibilities that did not get implemented. One is fault tolerance and theother is process migration, which, incidentally, go hand in hand. Although these were notincluded in SPEDE, the structure of SPEDE was set up with both in mind. SPEDE contains afacility for an object to link to any other object and send it messages to be recorded. Themessages could be stored and used to restart an object at a later time. The DEANs would alsoplay a role by forwarding all incoming messages to be recorded. This would make the object- 9 -oblivious to whether it was being check-pointed. The other necessity for fault tolerance to workis that the object must be able to save and restore its state. Since SPEDE does not have its owncompiler, this burden would have to be placed on the programmer of the object.An area for improvement in the current version of SPEDE is the time for remote objectcreation. From my results, I found that the start-up costs for a session were expensive. Security isanother area that needs work. Currently, no user authentication is performed by DEANs or REG.They simply accept remote commands and process them. This hole would allow a mal-intentioned user to connect to another user's DEAN and starting running their objects.Finally, if there were more time, I would have wrote several more test programs. TheMandelbrot demo tests the system using a simple master/slave object model, however objectscan communicate among themselves. One program that would have been usefull in testing this isan n-body simulator.ConclusionAlthough SPEDE does not have the bells and whistles found in many distributedenvironments, it can be used to attain significant speedup. An increase in speed by a factor offive (on eight processors) was gained with the Mandelbrot demo while running in a steady state.One of the interesting aspects of this project was to see how much of a system could be built in asuch short time period. After only 8 weeks of programming, the bulk of SPEDE was completed.Although there are things to work out in SPEDE, such as reducing start-up costs, the system hasproven itself to be worth while. It is clear that distributed applications can work, especially forprogrammers who do not have access to parallel machines. Distributed computing is a low cost(or no cost) solution to high performance computing and should be considered by anyoneneeding more CPU power.- 10 -REFERENCES1. E. Jul, H. Levy, N. Hutchinson, and A. Black. Fine-grained Mobility in the EmeraldSystem. ACM Transactions on Computer Systems, 6(1):109-133, February 1988.2. S. Mullender, G. Rossum, A. Tanenbaum, R. Renesse, and H. van Staveren. Amoeba: ADistributed Operating System for the 1990s. IEEE Computer, 23(5):44-53, May 1990.3. H. Clark and B. McMillin. DAWGS: A Distributed Compute Server Utilizing IdleWorkstations. Journal of Parallel and Distributed Computing, 14:175-186, February 1992.4. A. Grimshaw. An Introduction to Parallel Object-Oriented Programming with Mentat.UVA Computer Science Report No. TR-91-07. April 4, 1991.5. M. Arango, D. Berndt, N. Carriero, D. Gelernter, and D. Gilmore. Adventures withNetwork Linda. Supercomputing Review, October 1990.6. A. Birrell and B. Nelson. Implementing Remote Procedure Calls. ACM Transactions onComputer Systems. 2(1):39-59. February 1984.

SPEDE: Simple Programming Environment for Distributed Execution

https://digitalcommons.dartmouth.edu/cgi/viewcontent.cgi?article=1167&amp;context=senior_theses

SPEDE: Simple Programming Environment for Distributed Execution

Abstract

Similar works

Full text

Available Versions

Dartmouth Digital Commons (Dartmouth College)