Jylab: A System for Portable Scientific Computing over Distributed Platforms

Jylab: A System for Portable Scientific Computing over Distributed Platforms Giorgos Kollias, Efstratios Gallopoulos Computer Engineering and Informatics Department University of Patras 26500 Patras, Greece [email protected], [email protected]

Abstract

This paper describes a new system built for enabling distributed scientific computations, however keeping attractive features of ‘single-machine’ systems:

Jylab is a portable and flexible scientific computing system favoring extensibility. It provides a user with a scripting language and a core set of libraries implementing numerical linear algebra (NLA) routines, communication models, interactive visualization and computer algebra system (CAS) capabilities. It thus enables the development of scientific applications involving numerics, graphics and symbolics over distributed computing platforms. A collection of extension packages can optionally support Grid computing and implement Web search engine and Web graph analysis frameworks.

1

• Interactive environment and a language for composing scripts (all above systems have this feature). Such a language, rising in popularity and supporting objectoriented, procedural and even functional programming features is Python [15], which comes also with an interactive shell. • Maximum portability which made Java attractive; Jython [29, 7], i.e. Python implemented in Java has these features. • Support for interprocess communication across machine boundaries, numerical computations (especially matrix based), visualization and symbolics; we integrated corresponding open-source class libraries from the Web.

Introduction

Systems like Matlab [11], Scilab [16] and Mathematica [9] (to name only a few) are most valuable tools for people doing science on computers. Matlab is a first choice for matrix computations and supports numerous toolboxes, Scilab is Matlab’s open source clone also including support for PVM and Mathematica proposes an interesting rule-based evaluation model and packages sophisticated symbolic, numerical and graphics capabilities. But what if we want to do science on a distributed computing platform? Open-source wrappers of message passing libraries (e.g. MPI) surely exist but they tend to be nonportable solutions (e.g. only working under Linux). Even if setting them up to work in a homogeneous LAN, what about a system of heterogeneous machines (e.g. in terms of operating system) connected over WAN links? It seems that systems mentioned, are not designed to transparently escape the ’single-machine’ scenario. Only recently, the commercial ones (Mathematica and Matlab), started offering support for distributed computing but this comes at extra license costs for the respective toolboxes [4, 2, 10, 5].

It is important to note that it is always possible to speedup a computation by coding it in Java (recent versions of JVM rival even C++ performance [6]). This new system packaging functionality of ready made components is Jylab. Jylab is actually an implementation of a portable Problem Solving Environment (PSE) [27] targeting a broad and extensible group of disciplines; PSEs can dramatically reduce the time-to-solution-by-computer for problems in science, by exposing computing capabilities in a most comprehensive, flexible and application-domain-friendly way. It is often the case that a PSE orchestrates distributed resources in order to achieve its role [30].

2

Motivation

Scientific applications are built on software components (typically routines or classes) traditionally written in statically typed languages, compiled by optimizing compilers and packaged into libraries. 1

However these components assume the availability of a certain runtime environment when used (e.g. a set of dynamically linked libraries -typically with their own dependency tree- or facilities at the operating system (OS) level). Failing to provide this environment, these components fail to provide their functionality, yielding non functioning (or even worse: malfunctioning) dependent applications. Note that not all dependencies can be satisfied by normal user since some of them are beyond his administrative rights (e.g. dependable system level libraries or OS itself). Adding a virtualization layer is a solution to this problem: Components are compiled to portable bytecode format to be executed by an interpreter supported by a broad set of core libraries providing a standard runtime environment. These components are written against the API of this runtime environment (or third party libraries which are in turn built upon it) ensuring portability at the cost of extra interpretation time (to be amortized by sophisticated runtime generators of native code - JIT compilers) and a reduced set of API selections -compared to ‘native’ ones. This last restriction is however alleviated by a growing set of third party libraries providing access to ‘missing’ functionality, through a -proposed- portable reimplementation of it, eventually, on top of core API. Note, we advocate statically typed languages for writing such components; this means that compilers-to-bytecode share the sophistication of traditional compilers: type information trigger the full set of compilation-stage code transformations generating optimized, high-performant bytecode. Having a set of portable components is not the end of software development; an application means composing, extending and glueing together such components using a programming language. Typically this is the same to the one the components were implemented. But in recent years this language is chosen from a set of dynamically typed languages (sometimes refered to as scripting languages [31]). From a user’s perspective such languages are built around an interpreter -a compiler to some bytecode format is rudimentary and implicit- and provide a very handy interactive environment; they support very high-level data structures and do not require explicit data type declarations. This leads to portable, flexible and very compact, ‘executable pseudocode’ programs at reduced development time. However since global type information are not readily available, no relevant compiler optimizations are applied. This coupled with dynamic interpretation costs (usually through expensive introspection mechanisms) degrades execution time performance while interpreter state management (exposed to the user via metaprogramming primitives (i.e. programming with language structures themselves)) also increases memory footprint. This brings up a pattern for scientific code development bridging the fast-execution world of statically-typed lan-

guages with the fast-development world of dynamicallytyped languages: applications as scripts composing a set of components. Components should include all hotspots -as verified e.g. by a profiler. In turn hotspots could drive decisions on the granularity of components (with granularity inversely proportional to flexiblity but directly proportional to performance) while first building a script-based prototype. Jylab supports exactly this pattern using Java as the language for developing components and Python for scripting them. To ensure portability, as an important factor for multiplatform deployment, everything is eventually implemented in Java including Python itself. Note that a less portable approach - C/C++/Fortan for developing components and Python (implemented in C, i.e. CPython) for scripting - has already been used for scientific code development [22]. On the downside, these native components (native extension modules) should be separately built for each of the supported platforms as well as packaged and distributed along with any non-standard, dependable, user-level libraries. In many cases, large e.g. C code bodies are already available in source form and special wrapper code (typically automatically generated e.g. using SWIG [18]) simply make them accesible from within Python. Jylab can access such a CPython installation, typical through standard network protocols. Fig. 1 shows such a typical architecture for a distributed Jylab application.

Figure 1. Typical architecture for a distributed Jylab application also accessing a CPython installation In what follows we present all those packages used in assembling Jylab. Core packages support scripting, numerical linear algebra, communications, visualization and symbolic calculations. Extension packages enable Grid computing and implement search engine and Web graph analysis frameworks. Core packages are broader in applicability while extension ones emphasize our focus on processing Web data structures. Some compact examples accompany these presentations with an emphasis on succinctness and 2

functionality; we conclude with a section also commenting on a possible practical path for interfacing Jylab to native code and finally we get some glimpse into our future plans.

3

import urllib import re from java . lang import ∗ def crawl( site , depth ): try : global hashtable if depth < MAX DEPTH: key = String ( site ). hashCode() if hashtable . has key (key ): print ’[%s] already crawled.’ % site return value = [ site , []] hashtable [key] = value print ’crawling [%s ]... ’ % site , url = urllib . urlopen( site ) content = url . read () hits = pattern . findall ( content ) print ’done.’ value[1] = hits for hit in hits : crawl( hit , depth + 1) except : pass

Core Packages

3.1

Scripting

Jython Jylab uses Jython for scripting. This is an implementation of Python programming language in Java bundling the full library (of an earlier version) of standard Python implementation (in C). It is implemented as a set of pure Python modules covering a large spectrum of programming needs (string and regular expressions, file and text operations, serialization and databases, threads and processes, debugging, client- and server-side network protocols, xml and network encodings, etc). Alternatively we can immediately start using the full set of standard Java libraries (GUI construction with Swing or AWT, I/O, lowlevel networking, concurrency support, multimedia, compression, security, CORBA and RMI support, applets, etc). It is possible to extend existing Java classes in Jython and there is extensive support for automatic conversion of Javaside to Python-side objects and vice versa. 3.1.1

MAX DEPTH = 3 pattern = re .compile(r’ href =”(http ://.∗?)” ’ ) base = r’ http :// www.ceid.upatras. gr’ hashtable = {}

Crawler example

crawl(base, 0)

In Fig. 2 a simple crawler is implemented. Starting from a base url it fetches its content, and collects links in it, matching a suitable regular expression. These links are put in a hashtable and recursively visited during next iteration (depth) in the crawling process. Duplicate entries are removed. This crawler is easily extensible into a multithreaded version; we can simply assign crawl() functions with different base urls to different threads and also expand our hashtable into a thread-safe one, e.g. by a mutual exclusion mechanism. Note the exception mechanism contributing to runtime robustness.

3.2

Figure 2. crawler.py ports 1D, 2D, and 3D matrices storing doubles and Objects, holding them in either dense or sparse arrays. Colt NLA implementation clearly emphasizes high performance and some of its neat characteristics include numerous matrix views (column, row, part, selection, sorted, strides), matrix partitioning, sorting and permuting, function objects applied to elements during matrix traversal (STL style) and stencil operations.

Numerical linear algebra

Numerical linear algebra (NLA) computations are supported in Jylab through two matrix toolkits: Colt and MTJ.

MTJ Matrix Tookits for Java (MTJ) [12] focuses on matrix computations. It supports storage schemes for general and structured dense matrices and for both structured and unstructured sparse matrices (namely dense-column major, packed, banded, tridiagonal and symmetric tridiagonal, standard and flexible compressed row/column (CRS/CCS) and compressed diagonal storage (CDS) formats). Dense and structured sparse computations are built on BLAS and LAPACK primitives including operations like matrix-vector and matrix-matrix multiplication, rank updates by matrices or vectors, direct linear solvers and a col-

Colt Colt [1] is a library providing fundamental generalpurpose data structures optimized for numerical data, such as resizable arrays, dense and sparse matrices (multidimensional arrays), linear algebra, associative containers and buffer management. It also contains packages providing mathematical and statistical tools for data analysis, powerful histogramming functionality, random number generators and distributions useful for (event) simulations. It sup3

lection of matrix decompositions (LU and Cholesky, eigenvalue and singular value decompositions for unsymmetrical dense matrices, eigenvalue decompositions for symmetrical matrices and orthogonal matrix decompositions for dense matrices (QR, RQ, LQ and QL)). MTJ uses optimized BLAS and LAPACK libraries if available thus ensuring improved performance. In case MTJ is not configured to use these native libararies, it reverts to JLAPACK, a Java translation of BLAS and LAPACK. Unstructured sparse matrices support operations like matrix-vector (optimized) and matrix-matrix multiplication, rank updates by matrices or vectors and iterative linear solvers adapted from the Templates project [21]. MTJ also includes matrix I/O in Matrix Market’s coordinate format and in an earlier version it supported MPI-like communication of distributed processes, used for building a PETSc-like abstraction for distributed matrices.

3.3

upcalls, dynamic change in the number of processes, manyto-one and one-to-many communication endpoints, etc). One very handy feature of Ibis (apart from its focus to portability and performance) are mechanisms for connection establishment even in the presence of firewalls and NAT. These utterly take the form of routed messages through relays located on internet-visible gateway machines; however, even less performant, these last-resort connectivity solutions (reminiscent of the idea of application level routing found in P2P systems) can support distributed applications over diverse Wide Area Networks (WANs) in a most transparent - and least effort - way. MPJ MPJ [25] is a specification API for MPI-like programming in Java and Ibis contains an implementation of this API on top of IPL. So users with experience in MPI programming can easily migrate to this development framework. It is very interesting that MPJ/Ibis outperforms MPICH/P4 (implemented in C) for Fast Ethernet in terms of latency (by a factor of 8) and -marginally- in terms of throughput (∼ 5% better) [23]. Note that MPICH/P4 is the most popular implementation of MPI in a commodity cluster environment; so these results propose MPJ/Ibis as a performant alternative to MPICH/P4 for these environments (with the extra benefit of increased portability (stemming from its Java implementation)).

Communication models

Communication between processes can be programmed at various levels. At the lowest level we can always use the socket interface. Going higher we adopt Ibis communication library and use either its comparatively low level interface IPL (Ibis Portability Layer)- typically implemented atop sockets - or one of the programming models built atop IPL (namely RMI (Remote Method Invocation), GMI (Group Method Invocation) - RMI enhanced with primitives for group communication e.g. multicasting, Satin (a distributed version of ‘divide and rule’ paradigm) and MPJ (MPIlike bindings for Java.

3.4

Interactive visualization

Interactive visualization is supported in Jylab through VisAD. Socket interface A socket is a flexible abstraction of a communication endpoint, and can be seen as a very simple interface to the transport layer of a typical network stack. In a typical TCP scenario, sockets can act as both sources and sinks of reliable bidirectional byte streams between communicating processes; these byte streams are transformed by higher-layer network protocols into meaningful application-level structures. In Jylab, Python socket API is commonly selected, although standard Java networking facilities can also be used instead.

VisAD VisAD (Visualization for Algorithm Development) [19] is a visualization system written in Java [28]; at its core it implements a hierarchical data model and a flexible display model through a collection of components which can even be networked together over an RMI infrastructure, giving rise to distributed, collaborative visualization environments. It comes bundled with its own user interface objects (e.g. spreadsheets with cells being displays) and mechanisms for propagating changes in data to their display and vice versa. VisAD includes special support for Jython in the form of Java classes or Python modules, in effect shortcutting the path from numerical data to their visualization (at least for simple ‘plots’).

IPL Ibis [33] is a communication library written in Java. It is a multi-layer system exposing, at its lowestlevel, a generic interface, IPL. This interface can use whatever communication infrastructure is available (e.g. native or Java sockets, Myrinet, etc). The system selects the most performant possible implementation fulfilling some general criteria posed, at runtime, by the user when he constructs an Ibis object (bidirectional communication, method for data serialization, generation of threads supporting recv()

3.5

Computer algebra

Jylab includes computer algebra functionality provided by MathEclipse. 4

MathEclipse MathEclipse [8] is a project also aiming at building an online symbolic mathematics calculator; it includes a math expression parser, a symbolic math engine and list manipulation algorithms (a list is its fundamental aggregation type grouping simpler types (e.g. integer, rational, real and complex numbers, strings etc). Its syntax and naming conventions are inspired by Mathematica. It supports rule-based, pattern-matching programming and both functional(apply, map, pure functions) and procedural(control stuctures) programming styles. It also implements an extensive subset of Mathematica’s built-in mathematical functions, algebraic operations and expression-structure manipulations. It symbolically computes integrals and derivatives, includes big number support for integer-based numerical types and generates 2D and 3D plots as Mathematica expressions.

4 4.1

tolerance mechanisms and P2P computations. Its programming model is based on deeply-studied theoretical foundations [24] using active objects as its computational unit. It supports an interesting deployment model based on XML descriptors and a graphical environment for computation monitoring and steering. 4.1.1

FTP with JavaGAT

In Fig. 3 an FTP server is contacted and the first few lines of one of its files are fetched and output. The interesting point here is that JavaGAT is used; this means that a suitable adaptor is dynamically selected (driven by the protocol in url). So access to data in Grids is made as simple as a change in the protocol (e.g. gsiftp://) and security context (GATContext object); interface (standard streams) remains the same.

Extension Packages

from java . lang import ∗ from java . io import ∗ from org. gridlab . gat import ∗ from org. gridlab . gat . security import ∗ from org. gridlab . gat . io import ∗ p = r’C:\packages\jylab−0.2\lib\java\javagat−1.2’ System. setProperty ( ’gat .adaptor. path’ , p)

Grid computing

Jylab can support Grid computing through JavaGAT and ProActive JavaGAT JavaGAT is a Java implementation of GAT (Grid Application Toolkit) [26] which resembles Simple API for Grid Applications (SAGA) [17], a Global Grid Forum (GGF) [3] standardization effort. JavaGAT offers a simple, uniform interface to whatever Grid services are currently available, abstracting away idiosyncrasies of Grid middleware. It uses the notions of engines and adaptors: adaptors are connectors to actual services while an engine manages the set of adaptors and dispatches API calls to the most suitable of them. The API is divided into several subsystems: base, resource management, data management (covering interprocess communication, remote file access and management), event and monitoring, information management and utility (including security aspects) subsystems. It is important to note that if no Grid middleware is present, a Grid-enabled application (containing GAT API calls) still works since also a complete set of adaptors to local services (always available) are included in JavaGAT implementation. So a user can test his application and be sure that if it works (dynamically selecting ‘local-services’ adaptors), this application will continue working in a ‘real’ Grid environment (using then adaptors bound to actual middleware services).

location = ’ ftp :// ftp . ntua . gr/pub/00 index . txt ’ username = ’anonymous’ password = ’[email protected] . gr’ context = GATContext() pwd = PasswordSecurityContext(username, password) context . addSecurityContext (pwd) filestream = GAT.createFileInputStream ( context , URI(location )) reader = InputStreamReader( filestream ) bufferedreader = BufferedReader(reader) for i in range(10): line = bufferedreader . readLine () print line filestream . close ()

Figure 3. gatftp.py

4.2

Search engine infrastructure

Jylab fully supports search engine capabilities at local filesystem, intranet or whole Web scale using Nutch.

ProActive ProActive [14] is a Grid-oriented Java library providing a framework for parallel, distributed, and concurrent computing in a secure way also supporting migration of computing objects, group communications, fault

Nutch Nutch [13] is an open-source Java implementation of a search engine. Architecturally, it mainly consists of two highly decoupled parts: the crawler and the searcher. 5

The crawler system implements fetching content from urls, parsing and converting it into textual format and subsequently indexing this extracted text. The searcher system serves search queries by consulting the index for finding matching document IDs which can be used for retrieving detailed index data, through which a finer search into parsed content can be conducted and its results returned to the user. Nutch also provides a web interface to searcher functionality powered by servlets.

4.3

from java . lang import ∗ from it .unimi. dsi .law.rank import ∗ from it .unimi. dsi .law. stat import ∗ from StringIO import ∗ class RankerTask(Runnable): def init ( self , graph, alpha, iterations , barrier ): pagerank = PageRank(graph) pagerank.alpha = alpha pagerank. init () self .graph = graph self .alpha = alpha self . iterations = iterations self . barrier = barrier self . logger = StringIO( ’ ’ ) self .pagerank = pagerank def run( self ): print >> self. logger ,\ ’[nodes = %d, links = %d]’ % \ ( self .graph.n, self .graph.m) for i in range( self . iterations ): self .pagerank. step () if i > 0: tau = KendallTau.compute( self .pagerank.rank, self .pagerank.previousRank) print >> self. logger ,\ ’[ iter = %d, tau = %f]’ % \ ( i + 1, tau) self . barrier . await ()

Web graph analysis

Analysis of the Web link structure in Jylab is based on WebGraph.

WebGraph [20] is a framework for studying Web link structure. It introduces a compression format for web graphs, a library for accessing these compressed structures using lazy techniques (decompression is delayed until actual data is requested) and a repository of very large, freelyavailable, Webgraph datasets in this special format. Jylab includes full support for such Webgraphs (e.g. compression/decompression, traversal, etc) relying on a set of auxilliary packages (collections framework, bit-level I/O) or enriched by others (e.g. computation of PageRank and Kendall’s τ between two rankings), also included. 4.3.1

Figure 4. ranker.py

Concurrent PageRank for a compressed Web graph

5

In Fig. 5 we give code for computing the first ITERS iterations of the PageRank [32] algorithm which ranks Web pages in a descending importance order (with ‘importance’ mainly decided by their popularity in terms of incoming links). A concurrent computation with TASKS threads is actually performed with each thread computing with a different value of deflation parameter α, although the Web graph is shared. At each iteration, the similarity of the current PageRank vector (containing current relative values for the importance of Web pages) to the previously computed one is measured by means of a rank correlation index, namely Kendall’s τ. Note the size of our web matrix and the increasing values of τ (i.e. decreasing differences in consecutive rankings) (Fig. 6). Also faster convergence for smaller α, as expected from theory, is assured. Note that a thread is conveniently encapsulated in its class (Fig. 4). Support for multithreaded designs really sets Jylab apart from most other general purpose PSEs; it could mean optimal performance for modern multicore processor atrchitectures.

Building, using and connecting to new functionality

Using Jylab interactively is the most flexible way for testing short programs. Its interpreter also consumes scripts kept persistently in files. This is the preferred way for writing longer programs defining e.g. new functions or classes. Such files are just standard Python programs with the extra capability of importing arbitrary Java classes. These files are called modules and their functionality can be imported from another module or at the interpreter prompt. For performance reasons one can also write standard Java classes. Typically these classes are organized into higher level namespace hierarchies called packages. Arbitrary collections of Java classes can be packed together with other dependable resources (e.g. images, text files) into platform independent distribution units (usually jar files). Also by using a suitable ‘indirection’ layer the full CPython capabilities (including its numerous native extensions) can be accessed from within Jylab system. Vari6

from java . lang import ∗ from java . util . concurrent import ∗ from it . unimi. dsi . webgraph import ∗ from ranker import RankerTask import os

Pagerank computation tasks completed [nodes = 325557, links = 3216152] alpha = 0.75 : [ iter = 6, tau = 0.986258] alpha = 0.80 : [ iter = 6, tau = 0.982802] alpha = 0.85 : [ iter = 6, tau = 0.977097] alpha = 0.90 : [ iter = 6, tau = 0.971216]

ITERS = 6 TASKS = 4 bdir = r’C:\packages\jylab−0.2\examples\webmatrix’ relbname = r’cnr−2000’ bname = os.path. join ( bdir , relbname) graph = BVGraph.loadOffline( String (bname)) barrier = CyclicBarrier (TASKS + 1) pool = Executors . newCachedThreadPool() tasks = [] futures = [] alpha = 0.75

Figure 6. Output from rankworkers.py on other packages and instructions for downloading package files from remote code repositories and integrating them into a local Jylab installation from corresponding web site. We’ll also enhance Jylab’s interactive environment. Dockable panels for interactive console, text and graphics output, file editing and help browsing will substitute rudimentary Jython’s console. Jylab has the extra advantage of being an open-source PSE: users can freely inspect the inner workings of the system by inspecting the source code of its components, giving new insights and ideas for further improvements or additions. Creating such a community of active and contributing users is perhaps Jylab’s most ambitious expectation.

for i in range(TASKS): task = RankerTask(graph, alpha, ITERS, barrier ) tasks . append(task) future = pool. submit( task ) futures . append( future ) alpha = alpha + 0.05 barrier . await () print ’Pagerank computation tasks completed’ print ’[nodes = %d, links = %d]’ % (graph.n, graph.m) for i in range(TASKS): alpha = tasks [ i ]. alpha log = tasks [ i ]. logger . getvalue () lastlog = log . split ( ’\n’)[−2] print ’alpha = %.2f : %s’ % (alpha, lastlog )

References [1] Colt Java class library website. http://dsd.lbl.gov/ ∼hoschek/colt/. [2] Distributed Computing Toolbox website. http://www. mathworks.com/products/distribtb/. [3] Global Grid Forum (GGF) website. http://www.ggf. org/. [4] gridMathematica website. http://www.wolfram.com/ products/gridmathematica/. [5] Interactive SuperComputing company site. http:// interactivesupercomputing.com/. [6] Java vs C++ performance benchmark data website. http: //kano.net/javabench/data. [7] Jython website. http://www.jython.org. [8] MathEclipse project website. http://www.matheclipse. org/me/. [9] Mathematica website. http://www.wolfram.com/. [10] MATLAB Distributed Computing Engine website. http: //www.mathworks.com/products/distriben/. [11] Matlab website. http://www.mathworks.com/. [12] Matrix Toolkits for Java website. http://rs.cipr.uib. no/mtj/. [13] Nutch project website. http://lucene.apache.org/ nutch/. [14] ProActive project website. http://www-sop.inria.fr/ oasis/ProActive/. [15] Python language website. http://www.python.org. [16] Scilab website. http://www.scilab.org/. [17] Simple API for Grid Applications Research Group website. http://forge.gridforum.org/projects/saga-rg/. [18] Simplified Wrapper and Interface Generator (SWIG) project website. http://www.swig.org/.

Figure 5. rankworkers.py ous solutions exist with the most attractive working over a network stack. At the lowest level we could implement such network aware solutions by (remotely) launching a CPython interpreter from within Jylab and feeding it with a script implementing a customized command server.

6

Current state and future work

Currently a Jylab ‘distribution’ is automatically generated by a Python script taking as input the locations of its software components and producing a zip-compressed file containing an installer which is itself another Python script. Installing and using Jylab assumes availability of recent versions of Java and CPython (free downloads followed by simple, point-and-click installation procedures). In the near future our system will support package descriptions; a package description will contain dependencies 7

[19] VisAD project website. http://www.ssec.wisc.edu/ ∼billh/visad.html. [20] WebGraph project website. http://webgraph.dsi. unimi.it/. [21] R. Barrett, M. Berry, T. F. Chan, J. Demmel, J. Donato, J. Dongarra, V. Eijkhout, R. Pozo, C. Romine, and H. V. der Vorst. Templates for the Solution of Linear Systems: Building Blocks for Iterative Methods, 2nd Edition. SIAM, Philadelphia, PA, 1994. [22] D. M. Beazley and P. S. Lomdahl. Building Flexible Large-Scale Scientific Computing Applications with Scripting Languages. In Proceedings of the Eighth SIAM Conference on Parallel Processing for Scientific Computing. SIAM, March 1997. [23] M. Bornemann, R. V. van Nieuwpoort, and T. Kielmann. MPJ/Ibis: a flexible and efficient message passing platform for Java. In Proceedings of 12th European PVM/MPI Users’ Group Meeting, pages 217–224, Sorrento, Italy, September 2005. [24] D. Caromel and L. Henrio. A Theory of Distributed Objects. Springer-Verlag, 2005. [25] B. Carpenter, V. Getov, G. Judd, A. Skjellum, and G. Fox. MPJ: MPI-like message passing for Java. Concurrency: Practice and Experience, 12(11):1019–1038, 2000. [26] G. Allen, K. Davis, T. Goodale, A. Hutanu, H. Kaiser, T. Kielmann, A. Merzky, R. van Nieuwpoort, A. Reinefeld, F. Schintke, T. Sch¨utt, E. Seidel and B. Ullmer. The Grid Application Toolkit: Towards Generic and Easy Application Programming Interfaces for the Grid. In Proceedings of the IEEE, volume 93, pages 534–550, 2005. [27] E. Gallopoulos, E. Houstis, and J. R. Rice. Computer as Thinker/Doer: Problem-Solving Environments for Computational Science. IEEE Comput. Sci. Eng., 1(2):11–23, 1994. [28] W. Hibbard, C. Rueden, S. Emmerson, T. Rink, D. Glowacki, T. Whittaker, D. Murray, D. Fulker, and J. Anderson. Java distributed objects for numerical visualization in VisAD. Commun. ACM, 45(4):160–170, 2002. [29] J. Hugunin. Python and Java - the best of both worlds. In Proceedings of the 6th International Python Conference, pages 11–20, San Jose, Ca., Oct. 1997. [30] S. Kawata, H. Fuju, H. Sugiura, Y. Saitoh, Y. Hayase, T. Teramoto, and T. Kikuchi. A distributed problem solving environment (pse) for scientific computing. e-science, 0:470– 477, 2005. [31] J. K. Ousterhout. Scripting: Higher-level programming for the 21st century. Computer, 31(3):23–30, 1998. [32] L. Page, S. Brin, R. Montwani, and T. Winograd. The PageRank Citation Ranking: Bringing Order to the Web. Technical report, Stanford University, 1998. [33] R. V. van Nieuwpoort, J. Maassen, G. Wrzesinska, R. Hofman, C. Jacobs, T. Kielmann, and H. E. Bal. Ibis: a Flexible and Efficient Java based Grid Programming Environment. Concurrency and Computation: Practice and Experience, 17(7-8):1079–1107, June 2005.

8