An Object-Passing Model for Parallel Programming

An Object-Passing Model for Parallel Programming Jameela Al-Jaroodi and Nader Mohamed

Computer Science and Engineering, University of Nebraska – Lincoln Lincoln, NE 68588-0115, {jaljaroo, nmohamed}@cse.unl.edu

Abstract This paper introduces an object-passing model for parallel and distributed application development. Object passing provides the object-oriented application developer with powerful yet simple methods to distribute and exchange data and logic (objects) among processes. The model extends message passing, while exploiting the advantages of the object-oriented paradigm. In addition, the model provides a portable framework for executing applications across multiple platforms, thus effectively exploiting available resources to gain more processing power. A number of advantageous aspects of adopting object passing are discussed, in addition to highlighting the differences between message passing, represented by MPI, and object passing. Another advantage is the model’s suitability for heterogeneous systems. When implemented with a portable language like Java, it can support parallel and distributed applications spanning a collection of heterogeneous platforms. This form of execution will eventually allow for full utilization of available resources for any given application written using this model.

Key Words: heterogeneous systems, object-passing parallel/distributed programming, clusters, object-oriented languages, message-passing 1.

Introduction

We propose an object-passing model for parallel and distributed programming in object-oriented languages. Our main objectives are to provide methods to exchange complex data structures, facilitate the exchange of logic along with data, and build a robust object-oriented parallel/distributed programming model that fully exploits the unique advantages of the object-oriented paradigm while supporting heterogeneous platforms. Object-oriented development is well established and proven useful and efficient in terms of development time, ease of debugging and maintenance, and object reuse. Consequently, we need a matching model for parallel and distributed programming in object-oriented languages.

The message-passing model has been available for some time, providing an excellent tool for developing parallel and distributed applications for distributed memory systems. However, this model is complex, compared to the shared memory model, and requires the programmer to exert explicit control over all parallelization aspects. In addition, message-passing implementations such as the message-passing interface (MPI) provide simple exchange mechanisms for homogeneous data structures (mainly arrays of simple data types). The exchange of heterogeneous data structures with multiple, different components such as structures and records require a more complex approach. Moreover, message passing limits the exchange to data only, making the exchange of logic (i.e. methods) to be desired for. Recently there is an increasing interest in developing new parallel programming capabilities to harness the vast resources available in clusters and heterogeneous systems (e.g., computational grids). In addition, the diversity of the available systems and their varying characteristics generated a need for more efficient and elaborate ways to distribute and execute application components in the most suitable architecture in the distributed environment. To achieve such a goal, the parallel/distributed programming model introduced should be architecture independent, portable, and provides mechanisms for dynamic code exchange, along with data. This model is an extension to, rather than a replacement for, the message-passing model. A prototype implementation using Java is briefly discussed to illustrate its advantages and performance. In the rest of this paper, we introduce, in Section 2, some relevant concepts and technologies. Section 3 describes the proposed object-passing model for parallel programming with a discussion of its salient features, advantages, and disadvantages. We introduce the prototype implementation, JOPI, and its performance evaluation compare it to MPI in Section 4. Finally, Section 5 concludes the paper.

2.

Related Concepts and Background

Object-oriented programming has proven to be extremely effective and robust for application development. In addition, distributed and heterogeneous environments have created the need for efficient and

Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE

practical techniques to facilitate the proper development and deployment of parallel and distributed applications. Current features and classes of Java, the prototype language, enable methods such as socket programming, remote method invocation (RMI), and object serialization to facilitate distributed application development. However, using these methods for parallel applications development is complex. On the other hand, the message-passing interface (MPI) provides a standard interface to writing parallel programs. Recently, some effort has been made to provide parallel programming capabilities for Java (see [2] for more details).

2.1.

Object-Oriented Technology

Object-oriented technology is based on the simulation of real world objects by representing an object with a set of attributes and methods that are used to change them. In an object, only the methods defined are allowed to change its attributes. This model of programming is very effective in the application development process and provides simple mechanisms for data abstraction, object encapsulation, and inheritance. Thus, giving rise to many benefits such as ease of software development, debugging and maintenance, object reuse, and better scalability. A number of languages support object-oriented programming such as smalltalk, C++ and Java. However, it has not been employed effectively in parallel and distributed development tools.

2.2.

The Message-Passing Model

The message-passing model is an explicit parallel programming model based on exchanging data among processes in the MPMD model. It is used to facilitate distributed applications development and has a number of distinguishing characteristics [9]: Multithreading, asynchronous Parallelism, separate address space for each process, explicit interaction, and explicit allocation. The Message Passing Interface (MPI) [16] is a defacto standard for this model and it provides a library of routines for parallel and distributed programming. Using MPI requires full awareness of the parallelization process, and details of the messages to be exchanged. On the other hand, this provides the programmer with high flexibility. MPI-1 is used to exchange messages containing one data type, such as integers, float or char. In addition, it allows packing and unpacking of data of different lengths or types, and passing structures, but requires considerable coding. MPI-2 added more functions such as one-sided communications and language bindings. Object-Oriented MPI was introduced recently to provide C++ programmers with abstract methods. Many extensions, such as OOMPI [15], Charm++ [12] and ABC++ [4], have been developed for this purpose.

3.

The Object-Passing Model

The success of the object-oriented technology and the message-passing model has had profound impact on

parallel programming tools and languages. Recently a number of research groups have been working on providing MPI bindings for Java, including mpiJava [5], JMPI [7], JavaMPI [10], and CCJ [14]. Many of them follow the MPI for Java (MPJ) draft specifications [6], while others utilize MPI-like interfaces that do not exactly follow MPJ. Although these projects are targeted for Java, none have fully utilized its inherent features such as the use of object-orientated methodologies and machine independence. In this paper, we discuss a framework for an objectpassing model that will supplement the message-passing model, thus providing more innovative features to exchange data and code among processes. The model will provide a number of well-defined functions and requirements that will allow an implementation to successfully support the exchange and deployment of objects. Some essential Primitives needed are: 1. Point-to-Point Synchronous Communication Primitives. Methods to exchange objects, allowing the developer to send and receive objects by specifying the object name and class, and the sender/receiver process ID. In addition, more information can be incorporated, such as an identifying tag that can be used to insure proper matching of the sender and receiver of the object. 2. Point-to-Point Asynchronous Communication Primitives. Methods to asynchronously send and receive objects are also necessary to provide a means of overlapping communication with computation. The methods provide a request number for the operation that is used to check the status of the operation later. Such operations initiate communication requests (send or receive) and return before they complete. 3. Test and Wait Primitives. These methods provide simple testing mechanisms to verify the completion of the send or receive operations invoked earlier. The test method is asynchronous, thus it returns a Boolean flag indicating whether the operation has completed or not. However, the wait method should block on invocation until the specified operation completes. Both the test and wait use the request number returned by the asynchronous send or receive to be checked. 4. Group Communication Primitives. Methods to allow for exchanging objects among groups of processes (such as broadcast and multicast of objects) are essential. The model provides a broadcast method that uses a group ID to send/receive objects among multiple processes. The group ID identifies the processes involved in the operation. If all processes invoke the method with the same group ID, they all will receive the broadcast object; however, selectively using the group ID among some of the processes will result in a multicast among these processes. 5. Synchronization Primitives. Methods to synchronize processes, such as a barrier that blocks all participating processes until all of them reach that barrier. The

Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE

barrier method needs a parameter to indicate the number of processes to synchronize and a barrier ID to distinguish different barriers issued in the application. 6. Process Identification and Counting Primitives. In any object-passing application, it is essential to identify each process and the number of processes in the application. Process ID and counting methods will supply this information. 7. I/O Control Primitives. Mechanisms to direct the output of processes to a single machine, usually the local machine where the job started, such that all output is displayed in one place. The model may be implemented in different objectoriented languages such as C++ and Java and can utilize different enabling technologies to accommodate for parallel deployment of application processes and object exchange. However, a Java implementation will be advantageous in terms of facilitating heterogeneous application development and execution. On the other hand, an implementation in an efficient compiled language such as C++ will result in an efficient system for homogeneous environments. As discussed earlier, the message-passing model has some defining characteristics, which also extend to define the object-passing model. However, the objectpassing model adds more characteristics that clearly distinguish it from the message-passing model: 1. Allowing the exchange of logic among distributed processes. This feature provides a flexible and easy way to use the parallel environment. In addition, it facilitates moving code to the most suitable processor and adapting execution to the current setting of the system at run time. 2. Facilitating the separation of the problem solution from the parallelization details, thus simplifying the development process of parallel application. Moreover, this makes modifying and changing the objects of the solution easier and facilitates the reuse of the available objects. This is an important advantage of object passing over message passing, which will be made clearer next by an example. However, the model also has some disadvantages that need to be addressed to enhance its performance compared to a message-passing implementation: 1. Objects are not suitable for simple data type or small size data exchanges due to the high overhead of encapsulating these data types in objects. 2. The overhead of object serialization can be high, thus the model is suitable for computation-intensive or data-intensive applications. Some research is underway to optimize object serialization and provide more efficient means for transporting objects. An example application that can be efficiently implemented using the object-passing model is the traveling salesman problem (TSP). The problem is

implemented as a class containing the problem information and the search mechanisms. Additional classes for the search range, minimum tour found and tour cost are implemented. The classes are then used to solve the problem sequentially or in parallel. A parallel algorithm based on branch-and-bound search [11], for example, requires using many of the object passing primitives to implement an efficient load-balanced solution. Broadcast is used to distribute the original problem object to processes and used by processes to broadcast the minimum tour value found. This allows other processes to update their minimum value to speedup their search. In addition, asynchronous communication is used by slave processes to report the results to the master process, while continuing to process other parts. However, using the same TSP classes different implementations are possible such as a distributed version, where processes only communicate when their allocated range is searched completely.

4.

Comparing an object-passing model implementation with MPI

To illustrate the concepts introduced in the objectpassing model, Java was selected to implement a prototype called the Java Object-Passing Interface (JOPI) [13]. Java was used due to its popularity among developers and the increasing interest in exploring the possibilities of using Java for multi-processor systems. Another reason is Java’s machine independence, which allows programs to execute on any platform with a Java virtual machine (JVM). JOPI was implemented for parallel and distributed Java application development on a distributed memory system. It provides an object-passing interface based on the characteristics discussed and is very similar to MPI. JOPI extends the object serialization to be used for parallel environments thus facilitating exchanging objects.

4.1.

JOPI’s Components

The prototype implementation includes three main components: JOPI’s class library [13], which implements the methods and attributes discussed above, the run-time support and the client services [1]. Using JOPI’s class library, users can initiate point-to-point and group communications, and synchronization, in addition to a few other functions and attributes. The JOPI class is used to write parallel Java programs and compile them using standard Java compiler. Then a parallel execution file is written to identify the classes used and the execution schedule. Finally, this parallel execution file is invoked in the JOPI run-time environment. Client services are the visible part of the JOPI environment to the user and provide commands to interact with the parallel environment. The JOPI run-time environment handles the deployment of the user classes in the required remote machines [1]. The communication mechanism between agents/clients is built directly on TCP/IP to make them more efficient.

Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE

4.2.

A JOPI Example Compared to MPI

Here we illustrate the usage and features of JOPI using the example in Figure 1 and compare it to a similar code in C - MPI (see Figure 2). First, we will explain the Java segment (line numbers are for illustration purpose only). 1. This code defines and exchanges an object st, instantiated from the class MyStruct (A4, A17- A29). The MyStruct class is declared as serializable to enable objects communication. 2. The st object contains a method sum that is invoked by the receiving process (A12). 3. The send requires the receiving process ID, the object to be passed and a tag. The receive needs the sending process ID and the tag, and returns the received object. JOPI.ANY_TAG, JOPI.ANY_SOURCE and JOPI.ANY_CLASS are used to receive objects with any tag, from any source, or of any class, respectively. 4. Adding attributes or methods to st is trivial and does not affect the operation of JOPI methods. A1 public static void main(String[] args) A2 { ... A3 JOPI mp = new JOPI(args); A4 MyStruct st = MyStruct(); A5 int myrank; A6 ... A7 myrank = mp.myPID; A8 if (myrank == 0) A9 mp.send(1, st, 0); A10 else A11 { MyStruct ss = (MyStruct) mp.receice (0, JOPI.ANY_CLASS, 0); A12 mp.print(“ Sum = “+ss.sum()); A13 } A14 mp.close(); A15 } A16 ... A17 class MyStruct implements Serializable A18 { A19 public int i; A20 public float[] a; A21 public MyStruct() A22 { ... } A23 /* Example of a method a receiving process can invoke A24 public float sum() A25 { float s = 0; A26 for (int j = 0; j < i; j++) A27 s += a[j]; A28 return(s) A29 } }

Figure 1 The Java+JOPI code for example 2

and B28 – B30 are needed to unpack it. Using JOPI, lines A17 - A21 are used to define the structure and A4 is needed to instantiate the object. To add attributes to the structure, it will require four extra lines of code in MPI in addition to changing the array sizes of len, disp and type. In JOPI, only one line is added for the attribute in class MyStruct. 3. When a process receives a packed message in MPI, it has to unpack it before use. Then if that process needs to send it to another process it packs it again before sending. This coding overhead is avoided in JOPI. 4. Lines A24 to A29 have no equivalent in C and MPI. These lines define a method in Java that can travel with the structure to the receiving process and be invoked there (as in line A12). B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 B16 B17 B18 B19 B20 B21 B22 B23 B24 B25 B26 B27 B28 B29 B30 B31 B32

int position, i; float a[1000]; char buff[1000] ... MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_Comm_world,&myrank); if (myrank == 0) { ... int len[2]; MPI_Aint disp[2]; MPI_Datatype type[2], newtype; len[0] = 1; len[1] = i; MPI_Address( &i, disp); MPI_Address( a, disp+1); type[0] = MPI_INT; type[1] = MPI_FLOAT; MPI_Type_struct( 2, len, disp, type, &newtype); MPI_Type_commit( &newtype); position = 0; MPI_Pack( MPI_BOTTOM, 1, newtype, buff,1000, &position,MPI_COMM_WORLD); MPI_Send( buff, position, MPI_PACKED, 1, 0, MPI_COMM_WORLD) } else { ... MPI_Status status; MPI_Recv(buff, 1000, MPI_PACKED, 0, 0, &status); position = 0; MPI_Unpack(buff, 1000,&position, &i, 1, MPI_INT, MPI_COMM_WORLD); MPI_Unpack(buff, 1000,&position, a, i, MPI_FLOAT, MPI_COMM_WORLD); } MPI_Finalize();

Figure 2 The C+MPI code for example 2 Comparing the programming effort to exchange the same structure using C and MPI, we observe: 1. Lines A3, A7-A9, A11, and A14 in Java are functionally equivalent to B5-B7, B22, B26 and B27, and B32 in C, respectively. They initialize object(message-) passing, get process id, check id, send structure, receive structure and close (finalize) the interface. 2. The major difference lies in defining and preparing the structure for exchange. In MPI the lines B1-B3, B9 – B21 are needed to pack the structure into one message

4.3.

Performance Measurements

Benchmark programs were used to evaluate the performance of JOPI, against that of MPI. xperiments were conducted on Sandhills, a cluster of 24 Dual-AMD AthelonMP 1.2 GHz nodes, with 256 KB cache per processor and 1 GB RAM per node. The cluster is connected via a 100 Mbps Ethernet network. Standard JVM version sdk 1.3.1 and gcc compiler were used. For the communication performance, the results show that, for small messages, MPI performs better than JOPI,

Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE

5. Using objects in JOPI simplified the development process by separating the parallelization details, thus facilitating the reuse of the objects created for different implementations.

S p e e d u p m e a su re m e n t f o r 7 2 0 x 7 2 0 m a trix 4 .0 3 .5

Speedup

3 .0 2 .5 2 .0 1 .5 1 .0

JO P I JO P I: L U

0 .5

M PI 0 .0 1

2

3

4

5

N o . o f P ro c es s o rs

6

7

8

Figure 3 Speedup of C and Java programs

while, with larger messages, the overhead starts to become less evident and JOPI’s performance matches that of MPI. Object serialization/deserialization delay in JOPI is independent of the application; therefore, it becomes less significant as the application becomes larger and more computation intensive. We used parallel matrix multiplication [8] to compare the performance of JOPI and MPI. The C program was optimized using the -O3 option and two Java implementations were used: “JOPI” indicates the regular implementation like C while “JOPI: LU” signifies an implementation with loop unrolling. From the measurements (see Figures 3), we observe: 1. The object-passing model performs generally well compared to MPI. The execution time, however, is higher in Java due to the interpretive nature of Java (instead of being a compiled language). 2. When Loop unrolling is used, JOPI performs better in the sequential version, but the speedup gained is smaller. This is mainly because the processing is divided among more processors and the overall computation load per processor is less. 3. Although JOPI is slower than MPI, it was possible to achieve higher speedups using JOPI. This enables JOPI to get closer to MPI in speed as the number of processors increases. 4. Although optimized C was used, it is not a fair comparison because Java does not optimize code.

In general, we may conclude that JOPI can yield reasonably good time and speedup performances compared to MPI, in light of the fact that C is still faster than Java. Java is being improved continuously for performance and has the added advantage of portability that enables parallel programs to exploit the power of heterogeneous platforms. In addition, the results indicate that a different implementation of the model for compiled languages such as C++ should result in good performance too. For more detailed JOPI implementation and evaluation information refer to [13].

4.4.

Discussion

The object-passing model prototype implementation, JOPI, provides a simple interface for developing parallel and distributed applications. JOPI’s performance compares reasonably well with that of MPI. In our implementation of JOPI, socket programming was used for communication due to its efficiency compared to RMI. Although JOPI and MPI have similar functionalities for parallel and distributed application development, they also have their unique features that distinguish each of them. Table 1 contrasts the main features of JOPI and MPI in the context of parallel and distributed programming support. Additional experiments to show JOPI’ssupport for heterogeneity were also conducted, for more details see [3] and [13].

5.

Conclusion

The object-passing model provides an extension to the message-passing model for object-oriented languages. It provides mechanisms to exchange objects rather than just data. This model fully exploits the object-oriented capabilities of object-oriented languages such as Java and C++, thus achieving a number of advantages: (1) Allowing the encapsulation of data and logic in a single unit that can be exchanged and used among different processes,

Table 1 Summarized comparisons of JOPIand MPI. Criteria Ease of coding

Object-Passing (JOPI) Easy

Size of code for sending complex Small structures/objects Communication efficiency Efficient for medium and large objects. Primitive type Point-to-point & group communication Providing Scatter & Gather No. Can be provided Dynamically Scheduling on clusters Provided by JOPI run-time system Heterogeneity support Yes Compiled code portability Yes, Java bytecode Code reusability Easy, objects-oriented Code maintainability Easy, objects-oriented

Message-Passing (MPI) Easy for simple data types & arrays, difficult for complex structures Large – need a lot of codes Efficient for medium and large messages Point-to-Point and group communication Yes Needs a third party tool. Yes, but difficult No, system dependant binary code Difficult, structural language Difficult, structural language

Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE

(2) Simplifying the development process by facilitating the separation of the problem solution from the parallelization process, (3) Facilitating object reuse, (4) Simplifying the exchange of complex data structures, and (5) Supporting execution over heterogeneous systems.The model defines the essential methods required to provide these functionalities such as point-to-point synchronous and asynchronous communication methods, group communication and synchronization methods, and other supporting methods and attributes. A prototype implementation, JOPI, was used to illustrate the general characteristics defined for the objectpassing model. JOPI fully supports application deployment on heterogeneous systems. The experimental evaluation demonstrates reasonably good performance of JOPI, and thus of the object-passing model, particularly with large object sizes. In general, the model is most suitable for applications with high computation to communication ratios and for distributed applications. In addition, a portable implementation of the model, like JOPI, can be used across multiple platforms without any additional effort. The proposed object-passing model has uncovered several areas of research and open issues that require more thorough investigations. Some such issues include, but not limited to: reducing the overhead and making it more suitable for fine grain parallelization, and providing efficient methods to deal with arrays and simple data types. In addition, different implementations are also possible for other object-oriented languages such as C++. Another possibility is utilizing this model to support peer-to-peer applications, which are distributed by nature and require exchanging data and code to facilitate their functionality.

6.

Acknowledgements

We would like to thank Professor Hong Jiang for his support and comments. We would also like to thank the secure distributed information (SDI) group and the research computing facility (RCF) at the University of Nebraska-Lincoln for their continuous help and support.

References [1] Al-Jaroodi, J., Mohamed, N., Jiang, H. and Swanson, D., "An Agent-Based Infrastructure for Parallel Java on Heterogeneous Clusters," Proc. of 4th IEEE International Conference on Cluster Computing, Chicago, Illinois, Sep. 2002, pp19-27. [2] Al-Jaroodi, J., Mohamed, N., Jiang, H. and Swanson, D., “A Comparative Study of Parallel and Distributed Java Projects for Heterogeneous Systems”, Proc. IPDPS, Workshop on Java for Parallel and Distributed Computing, Ft Lauderdale, FL, 2002. [3] Al-Jaroodi, J., Mohamed, N., Jiang, H. and Swanson, D., “Modeling Parallel Applications Performance On Heterogeneous Systems”, Proc. IPDPS, Workshop on Advances in Parallel and Distributed Computational Models, Nice France, April 2003.

[4] Arjomandi, E., O'Farrell, W., Kalas, I., Koblents, G., Eigler, F.C., and Gao, G.R., “ABC++ - concurrency by inheritance in C++,” IBM Systems Journal, vol. 34, pp. 120-137, IBM Corp. Riverton, NJ, 1995. [5] Baker, M, Carpenter, B., Fox, G., Hoon Ko, S., and Lim, S., “mpiJava: An Object-Oriented Java interface to MPI,” School of Computer Science, University of Portsmouth and Syracuse University, January, 1999, http://www.npac.syr.edu/projects/pcrc/papers/ipps99/paper/paper.h tml and http://www.npac.syr.edu/projects/ pcrc/mpijava/mpijava.html

[6] Carpenter, B., Getov, V., Judd, G., Skjellum, T. and Fox, G. “MPI for Java, Position Document and Draft Specification”, Technical report TGF-TR-03, http://www.javagrande.org/jgpapers.html [7] Crawford III, G., Dandass, Y. and Skjellum, A., “The JMPI Commercial Message Passing Environment and Specification: Requirements, Design, Motivations, Strategies, and Target Users,” Web Technology Group, MPI Software Technology, Inc. (MSTI), http://www.mpi-softtech.com/publications/JMPI_121797.html

[8] Gunnels, J., Lin, C., Morrow, G. and Geijn, R., “Analysis of a Class of Parallel Matrix Multiplication Algorithms“, Technical paper, 1998, http://www.cs. utexas.edu/users/plapack/ papers/ipps98/ipps98.html [9] Hwang, K. and Xu, Z., “Scalable Parallel Computing – Technology, Architecture and Programming”, WCB/McGraw-Hill, 1998 [10] JavaMPI page, http://perun.hscs.wmin.ac.uk/DHPC_files/projects.html

[11] Karp, R. and Zhang, Y., “Randomized Parallel Algorithms for Backtrack Search and Branch-andBound Computation”, Journal of the ACM, Vol 40, 3, July 1993. [12] Laxmikant, V. and Krishman, S., “Charm++: A Portable Concurrent Object Oriented Systems Based on C++,” Proc. OOPSLA, SIGPLAN Notices, vol. 28, no.10, pp. 91-108, October 1993. [13] Mohamed, N., Al-Jaroodi, J., Jiang, H. and Swanson, D., "JOPI: A Java Object-Passing Interface", in proceedings of the Joint ACM Java Grande-ISCOPE (International Symposium on Computing in ObjectOriented Parallel Environments) Conference (JGI2002), Seattle, Washington, November 2002. [14] Nelisse, A., Maassen, J., Kielmann, T. and Bal. H., “CCJ: Object-based Message Passing and Collective Communication in Java”, in Proc. Joint ACM Java Grande - ISCOPE 2001, Stanford University, CA, 2001. http://www.cs.vu.nl/manta/ [15] Squyres, J., Willock, J., McCandless, B., and Rijks, P., “Object Oriented MPI (OOMPI): A C++ Class Library for MPI,” in ’96 POOMA Conference. [16] Walker D. and Dongarra, J., “MPI: A Standard Message Passing Interface,” Supercomputer, vol. 12, no. 1, pp. 56-68, January 1996.

6 Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE