[IEEE Comput. Soc International Parallel and Distributed Processing Symposium (IPDPS 2003) - Nice,...

Automatic Resource Management using an Adaptive ParallelismEnvironment ∗

David Wangerin and Isaac D. Scherson{dwangeri, isaac}@ics.uci.edu

Department of Information and Computer ScienceUniversity of California, IrvineIrvine, CA 92697-3425, USA

Abstract

The Adaptive Parallelism Environment is introducedas a means of effectively utilizing MPP processing re-sources in a multi-programmed MIMD or distributedsystem. It achieves this by dynamically calculatingthe optimal number of threads for a given programat runtime. The optimality calculation considers boththe number of processing elements available to handleadditional workloads and the estimated computationalspeedup gained by using additional threads versus thecommunications overhead of using additional threads.The Adaptive Parallelism Environment is composed ofthree sections: a load balancer, which migrates threadsand provides information regarding the availability ofprocessing elements, a code analyzer, which estimatesthe number and composition of instructions in a po-tential thread as well as the number of communica-tions needed to synchronize the potential thread, and aruntime environment, which gathers information fromthe load balancer and code analyzer and performs theruntime calculations to estimate the optimal number ofthreads.

1. Introduction

Programmers face many difficulties when designingprograms for use in diverse MPP computing environ-ments. There are differing degrees of parallelism in al-gorithms with associated performance tradeoffs, designcomplexity tradeoffs, and testing and debugging differ-ences. If too much parallelism is used, then there willbe more threads than processors, and execution timeswill suffer. Alternately, if too few threads are used,

∗This work was supported in part by the UC MEXUS pro-gram and NASA-GSFC under grant number NAG5-9695

then the MPP machine may be underutilized. As a so-lution to these problems, programmers usually select atarget architecture with a set number of processing ele-ments and then use the appropriate algorithms for thatarchitecture. The result of this targeting and selectionprocess is the creation of programs that are specificallydesigned for systems with a rigid number of proces-sors. Compounding this problem is a lack of transpar-ent support for using differing numbers of processors inpopular programming languages and a lack of generalknowledge and expertise about portable parallel pro-gramming. To make matters worse, if the MPP systemis using a load balancer rather than a gang scheduler,then there may be multiple programs running concur-rently. Consequently, not all the processing elementsmay be available for use, and the system will effectivelyhave fewer processors than are physically in the system.

A second, and equally discouraging, problem is thatdifferent MPP architectures have vastly different com-munication performance characteristics. Parallel pro-grams are usually designed for use on a particular par-allel machine whose characteristics are well known sothat there is a good balance between communicationrequirements and computation requirements. For ex-ample, a program designed to run on a Cray T3E willtypically use a large number of threads with a high ra-tio of communications to computations, but this sameprogram would be disastrously slow on a Beowulf clus-ter of PCs using 10Mbit Ethernet. Conversely, a pro-gram written for a cluster of PCs would have a lowratio of communications to computations, but wouldgreatly underutilize the potential of a supercomputer.These examples are telling and reveal the importanceof communications in the performance of parallel pro-grams.

The Adaptive Parallelism Environment is a novelapproach to addressing both programming and archi-

0-7695-1926-1/03/$17.00 (C) 2003 IEEEProceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)

tectural issues simultaneously. It uses a combination ofruntime program analysis in conjunction with a load-balancer to dynamically determine the optimal numberof threads for a program. When a program has the op-tion of creating a new parallel thread, it consults theAdaptive Parallelism Environment to see if the threadshould be created. If the Adaptive Parallelism Envi-ronment determines that an additional thread could beprocessed and the overhead is less than the computa-tional speedup, it then instructs the program to createthe new thread. This decision is transparent to the pro-grammer, and dynamically adapts to the changing con-ditions found in multi-programmed parallel systems.The Adaptive Parallelism Environment consists of

three major components: a load-balancing scheduler,a code analyzer, and a runtime environment. The loadbalancing scheduler is responsible for not only the dis-tribution and scheduling of threads, but also for pro-viding heuristics about the number of available proces-sors and network status. The code analyzer provides acombination of compile-time and runtime heuristics re-garding the computation and communication require-ments of a thread or section of code. The runtime envi-ronment combines the heuristic information from thescheduler and code analyzer and decides the optimalcutoff point for creating new parallel threads.The Adaptive Parallelism Environment determines

the optimal number of threads based upon two under-lying principles. In order for a parallel program toachieve a computational speedup, two conditions mustbe satisfied:

• For each parallel thread, there must be a process-ing element available to handle the workload in atimely fashion

• The computational speedup of using an additionalthread must be greater than the communicationsoverhead of using the thread

If both of the above conditions can be satisfied, then itcan be surmised that that a parallel program is oper-ating with less than the optimal number of threads. Ifone of these conditions fails, the program has the opti-mal number of threads, and creating additional threadswill not lower the execution time.

2. Related Work

A related area of research is automatic manage-ment of parallel resources. Two projects have beenworking on creating distributed Java Virtual Machines(JVM) that automatically manage parallel resources.IBM’s cJVM[1] focuses on creating a Single System

Image (SSI) for a JVM and allowing all threads to ex-ecute in a distributed environment while synchroniz-ing threads and resources through the SSI. IBM’s tar-get platforms use very fast communications (microsec-ond latency messaging) and do not contain any faulttolerance capabilities. The University of Hong Konghas been working on a similar project but without theassumption of fast communications. Their project istitled JESSICA: Java Enabled Single System ImageComputing Architecture[11]. The software is middle-ware for a JVM that supplies a SSI and transparentthread management. JESSICA does not provide anyservices for fault tolerance or dynamic addition andremoval of processing nodes.Nicholas Carriero and others at Yale University have

been working on a system called Piranha that uses aform of Adaptive Parallelism[4][3]. Piranha maintainsa list of available processing resources and creates par-allel treads to utilize the resources. The list of pro-cessing elements is updated at regular intervals, andthus Piranha can dynamically adapt to changing envi-ronments. Programs must be specifically written to usePiranha through a set of library calls, and programmersare responsible for finding and exploiting parallelism ina program.Perhaps the work most similar to the Adaptive Par-

allelism Environment is Cilk[15]. Cilk is an extensionto C that allows programmers to easily create parallelprograms with a minimal amount of effort and knowl-edge of parallel programming. Cilk automatically cre-ates parallel threads at runtime and only creates newthreads if it believes that the computational speedupwill be greater than the overhead of spawning a newthread and transferring it to a new processing element.The decision algorithm for creating new threads uses anestimate of the number of instructions in the proposedthread and weighs this against a cutoff point. Cilk usesa work stealing load balancer to facilitate thread migra-tion. Cilk has been used in several successful programs,such as StarTech, *Socrates, and Cilkchess.

3. Load Balancer

Load Balancers attempt to improve an applicationsperformance by redistributing its workload among pro-cessing elements. However, the load balancing activ-ity comes at the expense of useful computation, incurscommunication overhead and requires memory space tomaintain load balancing information. To justify the useof load balancing strategies, the accuracy of each bal-ancing decision must be weighed against the amount ofadded processing and communication incurred by thebalancing process.


The Rate-of-Change Load Balancer (RoC-LB) is themost efficient load balancing algorithm for distributedand MIMD systems [2]. It is a fully distributed algo-rithm that maximizes processor utilization while main-taining good responsiveness. It works on the principlethat workload units (e.g. threads, tasks, jobs, etc.)should only be moved from one processing element toanother if the source PE is overloaded with workloadunits and the destination PE can handle more work-load units. Under this scheme, the system spends theleast possible time moving workload units and doingother balancing functions that do not contribute to theproductivity of the system.In order for the Rate-of-Change Load Balancer to

determine when to move workload units, each process-ing element records the number of tasks and averageexecution time of the tasks it has run and uses this in-formation to estimate its future workload. If the taskshave a high rate of change and it appears that the pro-cessor will face starvation, it will begin searching formore workload units. Conversely, if the tasks have alow rate of change and it appears that the processorwill have a more than adequate workload in the future,the processor will allow some of its workload units tobe migrated to other processing elements. It is im-portant to note that the responsibility of searching forexcess workload units and obtaining additional work-load units falls on the underutilized processors. Thismethod, commonly known as workload stealing [15],minimizes the work performed by processors that areheavily utilized. By having starving processors activelylooking for workload units and overloaded processorsshedding their workload units, the overall system at-tempts to reach a balanced state where all processorsare utilized to the greatest possible degree.Processing elements broadcast their workload status

by sharing a simple flag with neighboring processingelements. These flags are propagated throughout thesystem by having neighbors periodically update andexchange their status information. The flags can in-dicate one of three states for each processing element:underloaded, loaded, or overloaded. Although techni-cally the underloaded flag is not needed for the properexecution of the algorithm, it will become an impor-tant part of the Adaptive Parallelism Environment, aswill be seen in section 5. While the processing elementis sharing its status flag, the communication latencytimes to each of its neighbors can be calculated. Thisinformation becomes another important metric to theAdaptive Parallelism Environment.Beyond the desire to use Rate-of-Change Load Bal-

ancing for its proven efficiency, it also has three charac-teristics that are key to the Adaptive Parallelism En-

vironment. First, it is a fully distributed algorithm.Each processing element maintains its own load bal-ancing information and thus the system can scale towork on any number of processing elements. Second,it is inherently fault tolerant. Processing elements canbe added and removed from the overall system duringruntime, and RoC-LB will dynamically adjust to thechanges. Last, the algorithm maintains a list of theworkload status of each processor and the communica-tion latency times to each processor. This informationwill help guide the Adaptive Parallelism Environmentin the creation of new threads.

4. Code Analyzer

In order for the Adaptive Parallelism Environmentto estimate the runtime of a potential thread, it mustknow an estimate of the number of instructions in thenew thread and approximately how long each instruc-tion will take to execute. The second issue has beenaddressed in a graceful fashion using Performance Vec-tors, which will be reviewed in the following section.The first issue is still an open-ended problem, althoughcurrent research may provide a possible solution[13].

4.1. Performance Vectors

Performance Vectors[10][9] are a powerful and rel-atively simple way of measuring the performance of agiven system. Performance Vectors work by dividinginstructions into classes and then profiling the execu-tion times of instruction classes. Given a sufficientlylarge set of profiling data, a geometric model can becreated and analyzed to yield a mean execution timefor each instruction. These mean execution times canthen be applied to other programs to quickly and ac-curately estimate their runtime.Performance Vectors are useful because they are

flexible and they reflect the actual performance of realprograms. The instruction classes are not fixed at aspecific level of granularity; rather, the user can definewhat composes each instruction class. Thus, instruc-tion classes can be very course-grain (e.g. arithmeticinstructions, memory instructions, and branch instruc-tions), or they can be fine-grain (e.g. integer addition,floating point multiplication, etc.). These classes of in-structions are measured using low-overhead and non-intrusive techniques, such as timers and profilers. Theperformance information is gathered by running stan-dard benchmarks and other programs, not syntheticworkload tools. The mean execution times of instruc-tion classes therefore reflect delivered performance andnot peak performance.


Performance Vectors also include a quality measure-ment to gauge the accuracy and confidence of a perfor-mance vector. For example if a performance vector iscomprised of mostly integer arithmetic measurements,then the analysis of a program that is floating pointintensive will give a low quality measurement.The creation and use of Performance Vectors is crit-

ical to systems in an Adaptive Parallelism Environ-ment. Performance Vectors form the basis for estimat-ing the execution time of potential new threads, so thePerformance Vectors must be both accurate and suf-ficiently course-grain to keep execution time estimatessimple. Luckily, Performance Vectors can be generatedfor a given platform at the initialization of the Adap-tive Parallelism Environment and do not need to beregenerated unless the system is changed.

4.2. Code Analysis

In order for the Adaptive Parallelism Environmentto properly gauge the execution time of a thread, itmust know an estimate of the number and composi-tion of instructions in a thread, as well as an estimateof the number of communications to be performed bythe thread. The code analyzer is a component of acompiler that can generate equations to describe thisinformation.Static analysis is straightforward for code without

conditionals. The instructions are separated into theirrespective instruction classes and then tallied. Loopsrepresent multipliers to the contents of the loop. Ifloops are based upon a simple metric, such as data setsize, then describing the instruction count and compo-sition at runtime is a simple linear equation. To assessthe effects of conditionals, the conditional code can beviewed as irregularity in the program. To address pro-gram irregularity, it becomes is necessary to develop amodel of the program. A novel approach is to treatthe program as a set of events. It then follows that theprogram may be described using a series set of distri-butions, which can in turn be analyzed to reveal thetypical instruction count and composition. A frame-work for handling this irregularity is addressed in [12].Inter-thread communications can be treated as a

separate instruction class and thus analyzed in thesame fashion as other instructions. Equations to de-scribe communications may need additional informa-tion regarding the number of threads for the program,but this is a simple parameter when handled at run-time.Static code analysis results in a set of linear equa-

tions and probability distributions to describe the re-source requirements of a program. These sets of equa-

tions are passed to the Adaptive Parallelism Environ-ment whenever a potential thread is under considera-tion. The Adaptive Parallelism Environment evaluatesthe equations by applying the appropriate parametersand then factoring in the execution times provided bythe Performance Vectors.

4.3. Candidate Programming Languages andMethodologies

Three programming languages are excellent candi-dates for effectively programming in an Adaptive Par-allelism Environment. Each candidate language em-phasizes a different programming methodology and ex-poses a different level of parallelism to the program-mer. However, all of the languages abstract the de-tails of parallel programming, and thus can be used inthe dynamically changing environment created by theAdaptive Parallelism Environment. Below is a briefoverview of each language and the qualities of interest.

4.3.1. Explicit Parallelism

Traditionally, the programmer has been responsiblefor declaring the serial and parallel sections of code.This approach will be referred to as explicit parallelism.Explicit parallelism can be used in an Adaptive ParallelEnvironment with some constraints. Certain program-ming constraints need to be enforced with this methodto ensure that the code will work under the dynamicnature of the Adaptive Parallelism Environment. First,the program must be written in a language that clearlyspecifies where communications should occur. If com-munications are made in a fashion that is difficult todetect, then code analysis may fail. Second, the pro-grammer must ensure that all parallel code can func-tion properly with a variable number of active threads.Since the adaptive parallelism environment is designedto run with a varying number of threads, algorithmsthat require a specific number of threads (often callednon-malleable) will not function properly. Last, everytime the program has the possibility to create a newthread, the program should call a decision subroutinefrom the dynamic parallelism environment. If the pro-gram creates parallel threads without consulting theadaptive parallelism environment, then it defeats thepurpose of the adaptive parallelism environment.Explicit parallelism is advantageous since it requires

little runtime overhead (the parallelism has alreadybeen discovered), it compliments current parallel pro-gramming paradigms, and it does not require manychanges to the compiler. However, it places some diffi-cult constraints on the programmer to find and exploitthe parallelism in a program.


aCe (the adaptive C extension)[5] is an excellent ex-ample of a programming language that uses explicitparallelism. In aCe, threads are treated as arrays ofrecords. The details of parallel programming (e.g.inter-thread communications, synchronization, dead-lock prevention, etc.) are hidden from the programmerand handled automatically by the compiler. aCe wasdeveloped by Dr. John Dorband at the NASA God-dard Space Flight Center for use on Beowulf clusters,Crays, and other MPP supercomputers. It emphasizesa data-parallel programming paradigm by essentiallysimulating a SIMD environment on top of any parallelarchitecture.Modification of aCe for use in an Adaptive Paral-

lelism Environment would be a small matter of addinga code analyzer, including calls to the Adaptive Paral-lelism Environment for creating threads, and removingprogramming conventions for users to fix the numberof threads.

4.3.2. Automated Parallelism

Another approach to parallel programming is tohave the programmer write sequential code and let thecompiler do the work of attempting to discover par-allel sections of code. The compiler then handles thecreation and analysis of threads. This exact approachhas proven to be successful at vector computing butfaces some difficulties with pointer analysis and otherambiguous conditions. The underlying problem is thatthe compiler does not know anything about the runtimedata set of the program, so it must take a conservativeapproach to creating new parallel threads. In otherwords, automated parallelism compilers will only cre-ate a parallel thread if it can prove that it is safe to doso, so much of the potential parallelism of a programis overlooked.Automated parallelism has good potential for use in

an adaptive parallelism environment, as it relieves theburden of enforcing the constraints found in explicitparallelism. In addition, since automated parallelismdoes not require the programmer to specify parallelsections of code, the front-end of the compiler wouldnot have to be changed. This is significant since theexisting code would not need to be modified in orderto work with the Adaptive Parallelism Environment.ZPL[14] is a prime candidate for including an Adap-

tive Parallelism Environment into an automated par-allelism compiler. ZPL performs analysis on arraysand other data structures containing potential paral-lelism and automatically creates parallel threads. ZPLis in use at supercomputer centers including the ArcticRegion Supercomputing Center, Los Alamos National

Lab, and the Maui High-Performance Computing Cen-ter.

4.3.3. Dynamic Parallelism

Another new and promising form of parallel pro-gramming, called Dynamic Parallelism, performs on-line analysis of a program during runtime to search forparallel threads. One of the limits of the effectivenessof automated parallelism is that the data set is un-known at compile time, and thus no assumptions canbe made about the status of a program during run-time. Dynamic parallelism removes this barrier by us-ing runtime information about the data set to performaggressive but safe searches for potential parallelism.The first flavor of dynamic parallelism is Lambda

Tagging[6]. Lambda tagging inserts information tagsinto code at compile time and then uses lambda calcu-lus to rearrange statements at runtime. The resultingrearranged code often contains large sections of codewithout dependencies, and thus can be run in parallel.Since lambda tagging is based upon lambda calculus,it only works on code produced from functional lan-guages. Initial tests of lambda tagging have shownspeedups from 30% to 100% in sorting and 50% to200% in matrix multiplication.The second flavor of dynamic parallelism is called

Dynamic Resolution [7][8][6]. Under dynamic resolu-tion, the compiler inserts tags to detect conflicts inshared data, and these tags are examined and up-dated during runtime. By examining conflicts at run-time, a huge amount of transient parallelism can beextracted and exploited. Testing of dynamic resolutionhas shown speedups from 10% to 200% over optimizedsequential code, and it has even proven comparable inperformance to explicitly parallel code.One of the largest problems with dynamic resolu-

tion is that the algorithm creates too many threads andthe computational speedups are overshadowed by thecommunication overhead. This problem is perfectly ad-dressed by an Adaptive Parallelism Environment. Theonly potential drawback is that all code analysis mustbe performed at runtime, so there will be relativelylarge overhead costs from running dynamic resolutionalong with the code analyzer.

5. Adaptive Parallelism Environment

The Adaptive Parallelism Environment is responsi-ble for calculating the optimal number of threads fora given program. It performs this calculation basedupon heuristic information provided by the load bal-ancer and the code analyzer. The basic algorithm for


Figure 1. Overview of the Adaptive Paral-lelism Environment

deciding whether or not to generate a new thread issimple and operates in two phases.

• Consult the RoC-LB to determine if any process-ing elements are underloaded

• Compare the estimated computational speedupfrom generating an additional parallel thread tothe estimated communication overhead

If there are available processing elements and thespeedup is greater than the overhead, then a new par-allel thread is created. The load balancer then auto-matically handles the migration of the thread.The Adaptive Parallelism Environment is a simple

service provided by a runtime environment. The Adap-tive Parallelism Environment is invoked through sys-tem calls from programs. The system call contains twoparameters, which are provided by the code analyzer.The first parameter is the set of equations describingthe execution time of the current (single) thread. Thesecond parameter is the set of equations describing theexecution time of each of the potential new threads.The call returns a Boolean value indicating true if theprogram should fork the new thread or false if it wouldbe unwise to use the additional thread.To reach its decision, the Adaptive Runtime Envi-

ronment first checks with the load balancer to deter-mine if any processing elements are available to handlean additional workload. If no processors are available,then the call returns false. Otherwise, the AdaptiveParallelism Environment selects an available processingelement, finds its communications latency, and solvesthe set of equations describing the execution times ofthe threads. If the execution time for using the singlecurrent thread is less than the execution time for usingmultiple threads, then the call returns false. Other-wise, the two conditions for achieving a computationalspeedup are satisfied and the call returns true.To demonstrate how the Adaptive Parallelism En-

vironment operates, consider the following examples.In Figure 2, the target architecture has four processing

elements that are fully interconnected with a commu-nication latency of 10 time units. The programmingrunning on this architecture will take 800 time unitsto execute and has the potential to be broken into asmany as 8 parallel threads. Assume that each threadwill only need to make one communication to begin itsexecution and one communication at its termination.

Figure 2. Initial state of a 4-processor system.Job 1 requires 800 time units of execution,and can potentially be divided into 8 threads.

Since there are four processors and the communica-tion times are very small compared to the computa-tion times for each potential thread, the Adaptive Par-allelism Environment would fork each thread in halftwice, resulting in four threads with 200 work timeunits each. Note that even though the remaining fourthreads could be forked in half, it is not advantageousto do so, since there are no additional processing ele-ments to handle the increased number of threads. Theresults of the Adaptive Parallelism Environment canbe seen in Figure 3

Figure 3. The Adaptive Parallelism Environ-ment divides Job 1 into 4 threads.

Now consider that two jobs are running on the sys-tem. Each job has identical properties to the job de-scribed in the first example. Assuming that each jobwill be divided at the same time, the Adaptive Par-allelism Environment will only divide each job once,resulting in two threads per job. Figure 4 shows theinitial state of the system, and Figure 5 shows the re-sulting state.In the final example, the workload is much smaller,

needing only 80 time units for execution. Since eachthread will need one communication to begin and one


Figure 4. Two Jobs, each of which can poten-tially be divided into 8 threads.

Figure 5. The Adaptive Parallelism Environ-ment divides each Job into 2 threads.

communication to end, the communication overheadwill be much greater than in the previous examples.Assume that the job can potentially be divided into 8threads. The Adaptive Parallelism Environment woulddecide that the first division would be advantageous,since the execution time would drop to 60 units total(40 for the computation, 10 for the initial communica-tion, and 10 for the termination communication). Fur-ther divisions would not be advantageous, and wouldin fact raise the overall execution time, since the com-munications overhead would overwhelm the computa-tional speedup. For example, dividing each thread inhalf again would result in an execution time of 80 timeunits (20 for the computation, 3x10 for the initial com-munications, and 3x10 for the termination communica-tions. Figures 6 and 7 show the system in its initial andresulting states.

Figure 6. Communications have a larger rela-tive overhead for smaller jobs.

Figure 7. The Adaptive Parallelism Environ-ment only divides the Job into 2 threads,since communications become too signifi-cant with more threads.

6. Conclusions

The Adaptive Parallelism Environment has beenshown to be an effective method for dynamically de-termining the optimal number of parallel threads touse for each program in a multi-programmed MIMDor distributed system. It is compatible with a numberof different parallel programming methodologies, andsince it operates in an environment that does not in-terfere with other programs, it can be used in conjunc-tion with other sequential and parallel programs thatdo not utilize the Adaptive Parallelism Environment.Future work includes rigorous proofs of the optimal-

ity of thread utilization, a detailed report of the codeanalyzer, and simulation results of using the AdaptiveParallelism Environment versus other parallel process-ing paradigms.

References

[1] Yariv Aridor, Michael Factor, and Avi Teperman.cJVM: a Single System Image of a JVM on a Clus-ter. In International Conference on Parallel Pro-cessing, September 1999.

[2] Luis Miguel Campos. Resource Management Tech-niques for Multiprogrammed Distributed Systems.PhD thesis, Dept. of Information and ComputerScience, University of California, Irvine, 1999.

[3] Nicholas Carriero, Eric Freeman, David Gelernter,and David Kaminsky. Adaptive Parallelism andPiranha. IEEE Computer, 28(1):40–49, 1995.

[4] Nicholas Carriero, David Gelernter, David Kamin-sky, and Jeffery Westbrook. Adaptive Parallelismwith Piranha. Technical report, Yale University,1991.

[5] John Dorband. aCe Manual.


[6] Lorenz Heulesbergen. Dynamic Language Paral-lelization. PhD thesis, University of Wisconsin-Madison, 1993.

[7] Lorenz Huelsbergen. Dynamic Parallelization ofModifications to Directed Acyclic Graphs. In Par-allel Architectures and Compilation Techniques,1996.

[8] Lorenz Huelsbergen and James R. Laurus. Dy-namic Program Parallelization. In ACM Confer-ence on Lisp and Functional Programming, pages311–323, June 1992.

[9] Umesh Krishnaswamy. Computer Evaluation Us-ing Performance Vectors. PhD thesis, Dept. ofInformation and Computer Science, University ofCalifornia, Irvine, 1995.

[10] Umesh Krishnaswamy and Isaac D. Scherson.Micro-architecture Evaluation Using PerformanceVectors. In SIGMETRICS’96, 1996.

[11] M.J.M. Ma, C.L. Wang, F.C.M. Lau, andZ. Xu. JESSICA: Java-Enabled Single-System-Image Computing Architecture. In InternationalConference on Parallel and Distributed ProcessingTechniques and Applications (PDPTA’99), pages2781–2787, 1999.

[12] Shean T. McMahon and Isaac D. Scherson. AStatistical Mechanical Approach to a Frameworkfor Modeling Irregular Programs on Distributedor Cluster Computers. In 35th Annual SimulationSymposium, San Diego, April 2002. IEEE Press.

[13] Shean T. McMahon and Isaac D. Scherson. A Gen-eral Case Performance Analysis Methodology forParallel and Distributed Architectures and Appli-cations. In International Parallel and DistributedProcessing Symposium, 2003. Forthcoming work.

[14] Lawrence Snyder. A ZPL Programming Guide.Technical report, University of Washington, Jan-uary 1999.

[15] Supercomputing Technologies Group, MIT Labo-ratory for Computer Science. Cilk 5.3.2 ReferenceManual, November 2001.


[IEEE Comput. Soc International Parallel and Distributed Processing Symposium (IPDPS 2003) - Nice,...

Documents

Transcript of [IEEE Comput. Soc International Parallel and Distributed Processing Symposium (IPDPS 2003) - Nice,...