RsdEditor: A Graphical User Interface for Specifying Metacomputer Components R. Baraglia, D. Laforenza CNUCE - Instituto del Consiglio Nazionale delle Ricerche Via S. Maria, 36 - I-56100 Pisa, Italy e-mail: (Ranieri.Baraglia, Domenico.Laforenza)@cnuce.cnr.it A. Keller Paderborn Center for Parallel Computing F¨urstenallee 11, 33102 Paderborn, Germany e-mail:
[email protected] A. Reinefeld Konrad-Zuse-Zentrum f¨ur Informationstechnik Berlin Takustr. 7, D-14195 Berlin-Dahlem, Germany e-mail:
[email protected]
Abstract
of the Metacomputer On-Line (MOL) project [1]. MOL exploits the Computing Center Software (CCS) [2, 3] to manage the resources of a computing center. Within CCS, the resource and service description language RSD [4] is used to describe the metacomputer resources managed by CCS. RsdEditor provides a user-friendly visual support to automatically generate ASCII files structured according to the RSD language describing the resources specified by using the graphical features of the interface. RsdEditor was designed to be used by the administrator and users of a metacomputer. As shown in Figure 1, system administrators use the RsdEditor to specify the characteristics of the metacomputer’s resources (computational nodes, networks, software services, etc.). In particular, the administrator can assign attributes such as type and number of processors, memory size, software environments, architectural classes, latency, or bandwidth to the available computational resources. Likewise, users can specify the characteristics of the computational resources needed to execute their metaapplication. This phase is not intended to select specific resources but to indicate the general attributes belonging to a class of resources. The specifications made by the administrator and the user can be used to generate two graphs representing the metacomputer’s configuration and the user’s requirements, respectively. The allocation of the resources needed to execute the meta-application on the metacomputer is a problem
RsdEditor is a graphical user interface to produce specifications of computational resources. It is used in the RSD (Resource and Service Description) environment for specifying, registering, requesting and accessing resources and services in a metacomputer. RsdEditor was designed to be used by the administrators and users of metacomputing environments. At the administrator level the GUI is used to describe the available computing and networking components of a metacomputer. At the user level RsdEditor is used to specify the characteristics of the computational resources needed to execute a meta-application. This paper is organized as follows: Section 1 introduces the RsdEditor. Section 2 shortly presents the RSD environment, and Section 3 describes some features and implementation issues of the RsdEditor.
Keywords: Metacomputing, Resource Management, Resource and Service Description.
1. Introduction RsdEditor is a graphical user interface for specifying metacomputer resources. It was developed by CNUCECNR in cooperation with PC2 Paderborn in the framework 1
U s e r
A d m in is tr a to r
R s d E d ito r
A S C II - E d ito r
G r a p h ic a l r e p r e s e n ta tio n
T e x tu a l r e p r e s e n ta tio n
R s d P a rs e r
In te r n a l r e p r e s e n ta tio n A D T
Figure 1. Schema showing the use of the specifications generated by RsdEditor
W A N
R e s o u rc e M a n a g e m e n t S y s te m
of mapping the user graph onto the metacomputer graph. Several mapping algorithms [5, 6, 7, 8] have been proposed to solve this problem. The RSD resource specification file, automatically generated by RsdEditor, is analyzed by a parser to obtain Abstract Data Type (ADT) objects [4]. ADT objects can only be accessed through the RsdAPI which provides an abstract interface to the RSD data structures. As shown in Figure 1, the mapping of the task graph to the available resources as generated by the mapping algorithm is used by CCS to start and to control the execution of a meta-application.
The output of the graphical RsdEditor is sent through the RsdParser which generates abstract data objects that can be stored or submitted for further processing by (remote) resource management systems. In addition, ASCII RSD files can be also translated by the parser into abstract objects. By bundling objects with the corresponding methods the data can be interpreted and manipulated on other machines. Internal RSD objects can only be accessed through the RsdAPI which provides an abstract interface to the data structures. For later modification, the data structures are re-translated into their original form with the graphical and textual components. This is possible, because the internal data representation also contains a description of the component’s graphical layout.
RsdEditor is part of the RSD environment [4] that provides services and tools for specifying, registering, requesting and accessing computer resources in heterogeneous computing environments. RSD comprises three major components:
A p p lic a tio n
Figure 2. RSD environment
2. RSD Environment
R s d A P I
2.1 Textual versus Graphical Interface
a compiler system that transforms resource descriptions into ADTs (described in [4]),
RsdEditor has been designed to provide a user-friendly alternative to the textual RSD representation [4]. From a theoretical point of view, both representations are equivalent. In fact, the RsdEditor output is parsed and compiled by the same RSD compiler system used for the language representation. Hence, RsdEditor is no more expressive than the language. On the other hand, it is easy to prove that the language is no more expressive than RsdEditor by looking at the more advanced features of the language, like dynamic attributes and macros.
an ADT object library with API (outlined in [4]), a graphical user interface and editor RsdEditor (described in this paper).
In RSD, resources and services are represented by hierarchical graphs with attributed nodes and edges describing static and dynamic properties such as communication bandwidth, message latency, or CPU load. There exist tools for end-users as well as for system administrators (Figure 2). 2
Dynamic attributes [4] provide a means for handling dynamic data that is obtained at runtime. As an example, when running a WAN distributed application, the optimal (re-)mapping of the processes may depend on the current network performance. For this purpose, dynamic attributes provide up-to-date information on the current network status. When a dynamic attribute (keyword DYNAMIC) is parsed, the compiler system generates a corresponding object with appropriate access methods that are used by the dynamical data manager at runtime to provide up-to-date data in a synchronous or asynchronous way. Dynamic attributes can be specified in the same way in the RsdEditor and in the textual representation. A feature not included in the RsdEditor are macros. In the textual representation, they provide a shortcut for tedious repetitive declarations. In RsdEditor, this is done by copying the corresponding edges or (hyper-)nodes.
U I
. . .
R e so u r c e R e q u e st ( = R S D O b je c t)
A M
U I
A d m in is tr a to r
R e s o u r c e S p e c ific a tio n ( = R S D O b je c t)
A c c e ss M g r.
Q M Q u e u e M g r.
R S D D a ta b a se
M M
M a c h in e M g r.
H P C
2.2 RSD Tools in CCS Figure 3. RSD flow in the CCS system.
Maximizing the system utilization, and maintaining a high degree of system independence for improved portability and easier adaptation to new systems have been the two main goals of the CCS [3] project. CCS copes with these two conflicting goals by splitting the scheduling process into two parts. Figure 3 depicts the RSD flow in CCS. The hardware independent part is located in the Queue Manager (QM). It has no information on the mapping constraints such as the minimum cluster size, or the location of I/O-nodes. The hardware dependent task is performed by the Machine Manager (MM). It verifies whether a schedule computed by the QM can be mapped onto the hardware at the specified time. The RSD tools are used in the CCS management system for describing system resources and user requests. At boot time, all CCS components read the RSD specification created by the administrator and extract the relevant information (by use of the RsdAPI ). For example, the MM reads the machine topology and attributes, whereas the QM extracts only information like the number of PEs or the available operating system(s). The UI (User Interface) generates an RSD description from the user’s parameters (or from a given RSD description) and it sends the description to the Access Manager (AM). The AM, responsible for authentication, authorization, and accounting, checks whether the request matches the administrator given limits and forwards it to the QM. The QM extracts the information, it computes a schedule and sends it to the MM. MM verifies this schedule by mapping the user given RSD description against the static (e.g.
topology) and dynamic (e.g. PE availability) information on the system resources. If there is no mapping possible, the MM returns an alternative schedule. QM accepts this schedule or uses it to compute a new one. Although all CCS components are based on RSD, we hided the complexity of the RSD language by an easy-touse command line interface in the past. There was no need for a versatile resource description facility because most of the systems were homogeneous, their topologies simple and regular, and nearly all applications ran on only one system. With the trend to metacomputing (now often called grid based computing), resource description becomes more and more important, because now the system (instead of the user) decides which of the available resources are used. Hence, the users need a convenient tool to specify their requests, and the applications need an API to negotiate their requirements with the resource management system. The RSD systems fulfills both requirements by providing the RsdEditor and the RsdAPI , respectively.
2.3 Related Work Like RSD, the Globus [9] resource specification language RSL [10], its corresponding metacomputer directory service MDS [10] and the underlying LDAP services have also been devised for specifying distributed resources. However, the Globus approach is somewhat asymmet3
part of the window, called the workspace, is the working area for the graphical resource specification.
ric: It uses RSL for specifying resource requests and LDAP (based on X.500) for specifying resource offers. RSD in contrast, uses the same representation for both purposes, thereby allowing us to use common graph matching mechanisms for brokerage. The brokerage aspect is emphasized in the ClassAds approach used in the Condor [11] framework for matching resource offers with requests. Compared to RSD, the ClassAds project focuses on protocols for advertising resources and on the matchmaking process, rather than on the specification aspect. As a result, the expressions used in the ClassAds seem to be less powerful than our hierarchical, graph-based RSD expressions. The Resource Cataloging and Distribution System RCDS [12] developed at the University of Tennessee is another interesting approach. RCDS supports flexible, scalable, and secure access to various information (e.g. files) on WAN connected computers. Resources are named by URNs (Uniform Resource Names) that provide stable names for resources which may change in content or location over the time. This is achieved by putting resolution servers between the location dependent URLs and the end user. A middle software layer guarantees integrity and persistence of resources in an environment of dynamically changing information.
Figure 5. Example of a work session The menu bar contains the following items: File, Options, Node, Edge, Preferences, Tree, Topologies, and Help. File enables the creation/editing of a resource specification file. Options displays the current RSD file, refreshs the workspace, etc.. Node allows the creation, editing, or deletion of a node or a hypernode (a node containing other nodes in a recursive way). In the RSD syntax a node represents a computational resource characterized by graphical and RSD attributes. Figures 6 and 7 show the definition of the graphical characteristics and the assignment of RSD attributes to a node, respectively. The RSD syntax imposes that each node has at least one port (a node’s interface toward other nodes) in order to link it to another node by using an edge. RSD attributes can be assigned to a port (see Figure 8). RSD allows nodes to be defined recursively and to create hypernodes. A hypernode contains the specifications of other resources such as nodes, physical and virtual edges. In left hand side of Figure 5 the hypernodes and nodes are indicated by the letters H and N, respectively. Edge enables the creation, editing, or deletion of a physical or virtual edge. A physical edge represents a link between two nodes. The RSD syntax permits uni- or bidirectional physical edges. By using the windows shown in Figures 9 and 10 it is possible to select the port to be connected by an edge (binding). The edge binding is an RSD syntax constraint. Therefore, the ports must be defined before the binding. The no-
3. RsdEditor: Features and Implementation Figure 4 shows the RsdEditor starting window. Currently, it is possible to choose between two different languages, English and Italian. Moreover, it can operate in Administrator or User mode.
Figure 4. RsdEditor Start Window Figure 5 depicts an example of a working session. A status bar is shown at the bottom of this window in which error and information messages are displayed. The central 4
Figure 6. Specification of the graphical properties of a node
Figure 7. Specification of the RSD attributes of a node
tion of a virtual or vertical edge is used to provide a link between different levels of a hierarchy in the specification graph. A virtual edge is defined using the windows shown in Figures 11 and 12, and it is represented by an arrow (see Figure 5). Preferences permits the definition of some editor’s graphic features, such as size, shape, color, etc. Tree enables the managing of the resource tree. This tree is shown in a synoptical way; therefore, it is useful for the user who can see and navigate each level of the resource specification tree. On the left hand side of Figure 5 an example of a resource specification tree is shown. Topologies allows the creation, editing, or deletion of nodes representing some of the most common homogeneous interconnection topologies (Ring, Grid, Star, Torus). Figure 13 shows an example specifying a Grid composed by 4 8 nodes. This avoids the user having to manually specify 32 nodes and 52 edges. Help makes available the on-line manual.
14 RsdEditor allows the RSD code, produced during a specification phases, to be displayed. For portability reasons RsdEditor was implemented in Java [13, 14] and it has been tested successfully on Microsoft Windows (98, NT), RedHat Linux and Sun Solaris. The modular structure adopted to implement RsdEditor facilitates its maintenance and extension. A more detailed description of the RsdEditor functions can be found in [15, 16].
4. Example of RsdEditor Utilization As example of usage of RsdEditor we show in which manner it is possible to describe the computing resources of a computing center. Figure 15 shows the structure of the Paderborn Center for Parallel Computing. There are four parallel computers (CC 48, GCel System, SCI 64 and GCPP 64) connected by Ethernet; there is a computer (Uranus) acting as gateway towards the outside world. As sketched in Figure 16 each parallel computer (represented by a torus icon) and the gateway are connected to a central node representing the Ethernet hub. Those nodes are included into a hypernode denoted as Paderborn Park. In order to specify the attributes of each computer the windows shown in Figures 13 have to be used. The complete resource description automatically produced by RsdEditor is shown in the following. It is worthwhile to note the usefulness of RsdEditor looking at the pages containing the RSD code. In fact, the resource speci-
RsdEditor allows to save the current resource specifications to be saved by creating two files: filename.rsd and filename.gui containing the resource specifications in RSD syntax and the formal descriptions of graphical objects, respectively. filename is the name specified by the user at the creation time of the resource specification. The graphical interface offers the possibility to import and export resource specifications or part of them previously recorded in order to reuse them. As shown in Figure 5
Figure 8. Specification of port attributes Figure 9. Specification of the RSD attributes of a physical edge
fications made by the RSD language is a relative long and, potentially error prone, task. ========================================================== = Resource Description Produced by \R = ========================================================== ROOTNODE Paderborn_Park { NODE Ethernet { PORT Eth1 { Type = Ethernet; }; PORT Eth2 { Type = Ethernet; }; PORT Eth3 { Type = Ethernet; }; PORT Eth4 { Type = Ethernet; }; PORT Eth5 { Type = Ethernet; }; PORT Eth6 { Type = Ethernet; };
OD OD FOR i=1 TO n-1 DO FOR j=1 TO m DO EDGE Edge_$i_$j_to_$i_$((j+1) MOD m) { NODE Torus_$i_$j PORT cc48 NODE Torus_$i_$((j+1) MOD m) PORT cc48; }; OD OD FOR j=1 TO m-1 DO FOR i=1 TO n DO EDGE Edge_$i_$j_to_$((i+1) MOD n)_$j { NODE Torus_$i_$j PORT cc48 NODE Torus_$((i+1) MOD n)_$j PORT cc48;
Bandwidth = 100; }; NODE Uranus { PORT Ethernet; PORT ATM; }; NODE CC_48 { CONST n = 2; CONST m = 24;
}; OD OD ASSIGN Torus_1_1 PORT CC_48-Esterna; }; NODE GCel_System { CONST n = 32; CONST m = 32;
FOR i=1 TO n DO FOR i=1 TO n DO NODE Torus_$i_$j { PORT cc48; IF ((i=1) && (j=1)) THEN PORT CC_48-Esterna; FI
FOR i=1 TO n DO FOR i=1 TO n DO NODE Torus_$i_$j { PORT TransputerLink; IF ((i=1) && (j=1)) THEN PORT GCel-Esterna; FI
CPU = PowerPC; Memory = 64MByte; PeakPerformance = 12,76GFlops; SysOp = AIX4.1; };
6
Figure 11. Specification of the RSD attributes of a virtual edge Figure 10. Specification of the RSD attributes of a physical edge FOR i=1 TO n DO FOR i=1 TO n DO NODE Torus_$i_$j { PORT gcpp; IF ((i=1) && (j=1)) THEN PORT GCPP-Esterna; FI
CPU = T805; Memory = 4MByte; PeakPerformance = 4.4GFlops; };
CPU = PowerPC601; CPUNumber = 2; Memory = 32MByte; PeakPerformance = 5.12GFlops;
OD OD FOR i=1 TO n-1 DO FOR j=1 TO m DO EDGE Edge_$i_$j_to_$i_$((j+1) MOD m) { NODE Torus_$i_$j PORT TransputerLink NODE Torus_$i_$((j+1) MOD m) PORT TransputerLink;
}; OD OD FOR i=1 TO n-1 DO FOR j=1 TO m DO EDGE Edge_$i_$j_to_$i_$((j+1) MOD m) { NODE Torus_$i_$j PORT gcpp NODE Torus_$i_$((j+1) MOD m) PORT gcpp;
}; OD OD
}; FOR j=1 TO m-1 DO FOR i=1 TO n DO EDGE Edge_$i_$j_to_$((i+1) MOD n)_$j { NODE Torus_$i_$j PORT TransputerLink NODE Torus_$((i+1) MOD n)_$j PORT TransputerLink;
OD OD FOR j=1 TO m-1 DO FOR i=1 TO n DO EDGE Edge_$i_$j_to_$((i+1) MOD n)_$j { NODE Torus_$i_$j PORT gcpp NODE Torus_$((i+1) MOD n)_$j PORT gcpp;
}; OD OD
}; OD
ASSIGN Torus_1_1 PORT GCel-Esterna; }; NODE GCPP_64 { CONST n = 4; CONST m = 8;
OD ASSIGN Torus_1_1 PORT GCPP-Esterna; }; NODE SCI_64 { CONST n = 4;
7
Figure 13. Supported topologies
Figure 12. Specification of the RSD attributes of a virtual edge
CONST m = 8; FOR i=1 TO n DO FOR i=1 TO n DO NODE Torus_$i_$j { PORT sci64; IF ((i=1) && (j=1)) THEN PORT SCI_64-Esterna; FI
}; EDGE Edge0 { NODE Uranus PORT Ethernet NODE Ethernet PORT Eth1; Type = Ethernet; };
CPU = PentiumII; CPUNumber = 2; Memory = 256MByte; PeakPerformance = 19.2GFlops;
OD
EDGE Edge1 { NODE Ethernet PORT Eth2 NODE GCel_System PORT GCel-Esterna; Type = Ethernet; };
FOR i=1 TO n-1 DO FOR j=1 TO m DO EDGE Edge_$i_$j_to_$i_$((j+1) MOD m) { NODE Torus_$i_$j PORT sci64 NODE Torus_$i_$((j+1) MOD m) PORT sci64;
EDGE Edge2 { NODE Ethernet PORT Eth3 NODE SCI_64 PORT SCI_64Esterna; Type = Ethernet; };
}; OD
Bandwidth = 500MByte/s; }; OD OD FOR j=1 TO m-1 DO FOR i=1 TO n DO EDGE Edge_$i_$j_to_$((i+1) MOD n)_$j { NODE Torus_$i_$j PORT sci64 NODE Torus_$((i+1) MOD n)_$j PORT sci64; Bandwidth = 500MByte/s;
EDGE Edge3 { NODE Ethernet PORT Eth4 NODE GCPP_64 PORT GCPPEsterna; Type = Ethernet; }; EDGE Edge4 { NODE Ethernet PORT Eth5 NODE CC_48 PORT CC_48Esterna; Type = Ethernet; };
}; ASSIGN NODE Uranus PORT ATM;
OD OD
} ASSIGN Torus_1_1 PORT SCI_64-Esterna;
8
Figure 14. RSD code generation Figure 15. Example: structure of a computing center (Paderborn Park).
5. Summary In this paper, we have presented RsdEditor, a graphical editor for specifying computational resources and services in distributed environments. Computing components (computers, processors) are represented by nodes and their interconnects (WAN, LAN, or internal computer links) by edges. Both of the them may be attributed. Compared to other approaches RSD is used by both, users and administrators, thereby allowing to use simple graph matching algorithms for mapping resource requests onto resource offers. RsdEditor currently generates (via the RSD language) C++ objects. For improved portability, we plan to adapt RsdEditor to generate XML code. Also, work is under way to implement resource brokers with different strategies on top of the RSD framework.
MOL Project: An Open Extensible Metacomputer. Proc. Heterogenous Computing Workshop HCW’97, IEEE Computer Society Press, pp. 17-31. [2] CCS: Computing Center Software. http://www.uni-paderborn.de/pc2/projects/ccs. [3] A. Keller, A. Reinefeld. CCS Resource Management in Networked HPC Systems. Proc. Heterogeneous Computing Workshop HCW’98 at IPPS, Orlando, pp. 44-56. [4] M. Brune, A. Reinefeld, J. Varnholt. A Resource Description Environment for Distributed Computing Systems. Proc. 8th Intern. Sympos. HighPerformance Distributed Computing HPDC’99, Redondo Beach, 1999, 279–286.
6. Acknowledgements The authors would like to thank the Master Thesis students who worked with us during the design and the development phases of RsdEditor. In particular, thanks are due to Simone Nannetti and Mauro Micheletti. Moreover, we would like to thank Giancarlo Bartoli, technical manager at the CNUCE Parallel Computing Laboratory.
[5] R.R. Freund. Optimal selection theory for superconcurrency. In Proceedings of Supercomputing 89, p.699-703, 1989. [6] T.D. Braun, H.J. Siegel, N. Beck, L.L. Boloni, M. Maheswaran, A.I. Reuther, J.P. Robertso, M.D. Theys, B. Yao, D. Hensgen, R.F. Freund. A Compasrison Study of Static Mapping Heuristics for a Class of Meta-task on Heterogeneous Computing Systems 8th IEEE Heterogeneous Computing Workshop, IEEE Computer Society Press, April 1999.
References [1] A. Reinefeld, R. Baraglia, T. Decker, J. Gehring, D. Laforenza, F. Ramme, T. R¨omke, J. Simon. The 9
[14] Jason J. Manger. Essential Java*. McGraw-Hill, 1998. [15] R. Baraglia, D. Laforenza, M. Michelotti, S. Nannetti. RsdEditor: un’interfaccia grafica per la specifica delle risorse in un metacomputer. Descrizione e guida per l’utilizzo. CNUCE-CNR Technical Report CNUCE-B4-1999-013 (in Italian. Translation in English is in progress), 1999. [16] M. Michelotti, S. Nannetti. Un’interfaccia grafica per la definizione e descrizione delle risorse e servizi di un metacomputer. Tesi di Laurea (in Italian), Universit`a degli Studi di Pisa, Facolt`a di Scienze MM. FF. NN., Febbraio 1999.
7. Biographies Figure 16. Resources description of the Paderborn Park Hypernode.
Ranieri Baraglia graduated in Computer Sciences in 1982 at the University of Pisa, Italy. He is currently a researcher at CNUCE, an Institute of the Italian National Research Council (CNR) in Pisa, where he is a member of the Parallel Processing Group. Furthermore, he was a contract professor at the Department of Mathematics at Perugia University from 1991 to 1996 where he taught operating systems and parallel architectures. Ranieri Baraglia has been involved in several Italian and European projects. His main research interests are in the fields of heterogeneous computing and parallel algorithms and applications. He is a member of IEEE and ACM
[7] M.M. Eshaghian, Y.C. Wu. Heterogeneous Task Graphs onto Heterogeneous System Graphs Proceedings of Sixth Heterogeneous Computing Workshop, IEEE Computer Society Press, 1:147-160, April 1997. [8] R. Baraglia, D. Laforenza, A. Panciatici, F. Ravaglia A Suboptimal Mapping of Parallel Applications on Metacomputers. Proceedings of IASTED International Conference, Parallel and Distributed Computing and Systems, Cambridge Massachusetts, USA, November 3-6, 1999.
[10] K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith, S. Tuecke. A Resource Management Architecture for Metacomputing Systems . Proc. IPPS/SPDP ’98, Workshop on Job Scheduling Strategies for Parallel Processing, Orlando, 1998.
Domenico Laforenza is currently researcher at CNUCE, Institute of the Italian National Research Council (CNR) in Pisa where he is responsible of the Advanced Computing Department. Currently he has a joint appointment at the Department of Computer Science of University of Pisa as professor of Parallel Applications. Dr. Laforenza has written numerous technical and scientific papers and he served as program committee member and organiser of many national and international workshops and conferences related to High Performance Computing. He is a member of AICA and IEEE.
[11] M. Livny, R. Raman. High-Throughput Resource Management. In The Grid: Blueprint for a new computing infrastructure, ed. I. Foster and C. Kesselman, San Francisco, Morgan Kaufmann, 1998.
Axel Keller received his diploma in computer science from the University of Paderborn in 1993. He is working as a technical associate for the Paderborn Center for Parallel Computing.
[9] I. Foster, C. Kesselman. The Globus Project: A Status Report. Proc. IPPS/SPDP ’98, Heterogeneous Computing Workshop, Orlando, pp. 4-18, 1998.
[12] K. Moore, S. Browne, J. Cox, and J. Gettler. Resource Cataloging and Distributed Systems. Univ. of Tennessee, Techn. Report, January 1997.
Alexander Reinefeld is the head of the Computer Science department at Konrad-Zuse Supercomputing Center (ZIB) in Berlin, Germany, and a professor for Parallel and Distributed Systems at the Humboldt University Berlin. From 1992 to 1998, he was managing director of the Paderborn
TM Development Kit ( [13] The http://java.sun.com/products/jdk/.
Java
JDK TM ).
10
Center for Parallel Computing, Germany. His research interests focus on parallel and distibuted high-performance computing, parallel programming models, performance benchmarking, and applications in discrete optimization. He is a member of IEEE, ACM and GI.
11
