توجه ! این یک نسخه آرشیو شده میباشد و در این حالت شما عکسی را مشاهده نمیکنید برای مشاهده کامل متن و عکسها بر روی لینک مقابل کلیک کنید : درخواست مقاله به زبان اصلی
Nafas
12 October 2010, 09:13 AM
سلام
موضوع مقاله : برنامه نویسی موازی شبکه در جاوا
اصل مقاله :
- 1 -
JPVM: Network Parallel Computing in Java
Adam J. Ferrari
لینک ها فقط به اعضای سایت نمایش داده می شوند.
Technical Report CS-97-29
Department of Computer Science
University of Virginia, Charlottesville, VA 22903, USA
December 8, 1997
Abstract
The JPVM library is a software system for explicit message-passing based distributed memory MIMD
parallel programming in Java. The library supports an interface similar to the C and Fortran interface
provided by the Parallel Virtual Machine (PVM) system, but with syntax and semantics modifications
afforded by Java and better matched to Java programming styles. The similarity between JPVM and the
widely used PVM system supports a q uick learning curve for experienced PVM programmers, thus
making the JPVM system an accessible, low-investment target for migrating parallel applications to
the Java platform. At the same time, JPVM offers novel features not found in standard PVM such as
thread safety, multiple communication end-points per task, and default-case direct message routing.
JPVM is implemented entirely in Java, and is thus highly portable among platforms supporting some
version of the Java Virtual Machine. This feature opens up the possibility of utilizing resources commonly
excluded from network parallel computing systems such as Macintosh and Windows-NT based
systems. Initial applications performance results achieved with a prototype JPVM system indicate that
the Java-implemented approach can offer good performance at appropriately coarse granularities.
1 Introduction
The use of heterogeneous collections of computing systems interconnected by one or more networks
as a single logical computational resource has become a wide-spread approach to high-performance
computing. Network parallel computing systems allow individual applications to harness the
aggregate power of the increasingly p owerful, well-networked, heterogeneous, and o ften largely
under-utilized collections of resources available to many users [1]. In this paper, we describe a network
p arallel computing software system for use with and implemented in the Java language.
Because of its mandated platform independence and uniform interface to system services, Java provides
an attractive environment for the implementation of both network parallel applications and the
system software needed to support them.
Although numerous software systems support some form of network parallel computing, the
majority of use has thus far been based on a small set of popular packages that provide an explicit
message-passing, distributed memory MIMD programming model such as Parallel Virtual Machine
(PVM) [4], and the Message Passing Interface (MPI) [6]. These software systems support simple,
portable library interfaces for typical high-performance computing languages such as C and Fortran.
For example, PVM provides the programmer with a library routines to perform task creation, data
marshalling, and asynchronous message passing. In addition, PVM provides tools for specifying and
managing a collection of hosts on which applications will execute.
Results obtained with network parallel computing systems have been encouraging. For example,
a performance study of the NAS benchmark suite implemented in PVM demonstrated that relatively
small clusters of workstations could provide performance comparable to significantly more expensive
supercomputers [9]. However, the utilization of distributed, heterogeneous, shared resources
- 2 -
connected by commodity networks as a single, virtual parallel computer poses serious problems for
both the application and system software programmer. For example, from the application perspective,
it has been found that successful network parallel programs will almost always exhibit medium
to coarse granularity, and will be tolerant of network latency, for example through the use of a sendahead
programming style. These attributes can be difficult to achieve within some applications. From
the system programmer perspective, heterogeneity results in difficult problems such as task to platform
matching and system portability.
The Java language provides a number of features that appear to be promising tools for addressing
some of the inherent problems associated with network parallel programming. For example, from
the application perspective, Java provides a portable, uniform i nterface to threads. Using threads
instead of traditional heavyweight processes has been found to be an avenue for increasing latency
tolerance and allowing finer-grained computations to achieve good performance in distributed memory
parallel processing environments [3]. From the system implementation perspective, Java supports
a high degree of code portability and a uniform API for operating system services such as network
communications.
The JPVM (Java Parallel Virtual Machine) library is a software system for explicit messagepassing
based d istributed memory MIMD parallel programming in Java. The library supports an
interface similar to the C and Fortran interfaces provided by the Parallel Virtual Machine (PVM) system,
but with syntax and semantics enhancements afforded by Java and better matched to Java programming
styles. The similarity between JPVM and the widely used PVM system supports a quick
learning curve for experienced PVM programmers, thus making the JPVM system an accessible,
low-investment t arget for migrating p arallel applications to the Java platform. At the same time,
JPVM offers novel features not found in standard PVM such as thread safety, multiple communication
end-points per task, and default-case direct message routing. JPVM is implemented entirely in
Java, and is thus highly po rtable among p latforms supporting some version of the Java Virtual
Machine. This feature opens up the possibility of utilizing resources commonly excluded from network
parallel computing systems such as Macintosh and Windows-NT based systems.
In this paper we describe the JPVM system interface, implementation, and performance. In Section
2 we describe the interface to the JPVM system including the programming model and interactive
c onsole. In Section 3 we describe key features of a c omplete, working JPVM prototype
implementation. In Section 4 we describe initial performance results achieved with JPVM. In Section
5 we describe related systems, and in Section 6 we conclude.
2 Interface
The programming interface provided by the JPVM system is intentionally similar to that supported
by the PVM system, with the addition of enhancements to better exploit the potential benefits
of Java as a language for implementing network parallel applications. As in PVM, the programmer
decomposes the problem t o be solved into a set of cooperating sequential task implementations.
These sequential tasks execute on a collection of available processors and invoke special library routines
to control the creation of additional tasks and to pass messages among tasks. In JPVM, task
implementations are coded in Java, and support for task creation and message passing is provided by
the JPVM library.
The central interface through which most JPVM interaction takes place is exported by the jpvmEnvironment
Java class. Instances of this class are declared by JPVM tasks to connect to and
interact with the JPVM system and other tasks executing within the system. Objects of this class represent
communications end-points within the system, and are identified by system-wide unique identifiers
of the opaque type jpvmTaskId (analogous to a PVM task identifier). Whereas standard
- 3 -
PVM restricts each task to having a single communications end-point (and correspondingly a single
task identifier), JPVM allows tasks to maintain a logically unlimited number of communication connections
simply by allocating multiple instances of jpvmEnvironment. The ability to contain
multiple communication end-points in a single task simplifies the process of developing separate
linkable modules that need to p erform communication. First-class s eparation o f communication
streams eliminates the need to artificially distinguish between messages intended for different modules.
After an instance of jpvmEnvironment is allocated, its containing task can invoke basic
JPVM services such as task creation and message passing. For example, a task can determine its
identity for JPVM communication by invoking the pvm_mytid() method. A task can detach a
jpvmEnvironment from the JPVM system by invoking the pvm_exit() method. The basic
jpvmEnvironment interface is depicted in Figure 1.
2.1 Task Creation
The first action performed by a typical JPVM program is the creation of additional t asks to
achieve parallel execution. Task creation in JPVM is supported by the pvm_spawn() method,
which takes a string parameter indicating the name of a valid Java class visible in the CLASSPATH
environment variable, as well as the number of tasks to spawn and an array into which the
class jpvmEnvironment {
public jpvmEnvironment(); // Constructor registers task with the JPVM system
public void pvm_exit();
// Identity:
public jpvmTaskId pvm_mytid();
public jpvmTaskId pvm_parent();
// Task creation:
public int pvm_spawn(String task_name, int num, jpvmTaskId tids[]);
// Send messages:
public void pvm_send(jpvmBuffer buf, jpvmTaskId tid, int tag);
public void pvm_mcast(jpvmBuffer buf, jpvmTaskId tids[], int ntids, int tag);
// Receive messages, blocking (non-blocking versions not depicted):
public jpvmMessage pvm_recv(jpvmTaskId tid, int tag);
public jpvmMessage pvm_recv(jpvmTaskId tid);
public jpvmMessage pvm_recv(int tag);
public jpvmMessage pvm_recv();
//Probe for message availability:
public boolean pvm_probe(jpvmTaskId tid, int tag);
public boolean pvm_probe(jpvmTaskId tid);
public boolean pvm_probe(int tag);
public boolean pvm_probe();
// System configuration and control:
public jpvmConfiguration pvm_config();
public jpvmTaskStatus pvm_tasks(jpvmConfiguration conf, int which);
public void pvm_halt();
};
Figure 1. jpvmEnvironment interface excerpt.
- 4 -
jpvmTaskIds of the newly created tasks will be placed on successful return. Each task created
through pvm_spawn() executes in its own instance of the Java Virtual Machine, avoiding issues
such as conflicting usage of system services among tasks. These newly created instances of the Java
Virtual Machine are placed throughout the set of processors available to JPVM, and each runs an
object of the specified Java class.
The identity of newly spawned tasks gives rise to a basic problem for JPVM. In PVM, the identity
of a task is clear since tasks have a single communication end-point and thus a single task identifier.
In JPVM, tasks can have any number of communication end-points, and thus it is unclear what
identity for a newly spawned task should be returned to the parent (i.e. the spawning task). One simple
solution would be to remove the return of task identifiers from the spawn interface. Spawned
tasks could communicate their identities to their parents explicitly to enable communication. In order
to retain an interface similar to PVM, and to avoid additional application code in the common case of
a single identity per task, JPVM instead addresses this issue by returning the identity of the first
jpvmEnvironment allocated in each newly spawned task. For standard, single-identity tasks, this
provides the familiar PVM style of identifying newly spawned tasks.
2.2 Message Passing
Message passing in JPVM is performed using the pvm_send() and pvm_recv() methods of
the jpvmEnvironment class. However, before data can be sent, it must be collected into a jpvm-
Buffer object. Analogous to PVM buffers, jpvmBuffer objects are the message content containers
of JPVM. The jpvmBuffer interface (depicted in Figure 2) contains two b asic groups of
methods: those to pack data into a buffer, and those to extract data from a buffer. Where possible,
overloading is used in the interface to simplify application code. Scalar and vector pack and unpack
operations are provided for all basic Java types as well as String and jpvmTaskId objects.
An important difference between JPVM buffers and standard PVM buffers is the explicit nature
of the JPVM buffer data structure. In standard PVM, send and receive buffers are manipulated
implicitly by the pvm_pk*() and pvm_upk*() library routines. Whereas routines are provided to
manage multiple buffers, the implicit nature of the buffer being packed or unpacked gives rise to a
difficult interaction with threaded programs. In PVM, if a thread is packing one buffer, and a second
thread is packing another buffer, the threads must explicitly set the send buffer before each pack routine
(since the other thread may have run and set the send buffer since the current thread’s last pack).
Furthermore, a synchronization mechanism such as a lock must be used to ensure that the send buffer
is not reset by another thread between being set and packed by the current thread. This is a complex
and unnecessary requirement to place on applications programs. In JPVM this problem is addressed
class jpvmBuffer {
public jpvmBuffer();
public void pack(int v[], int n, int stride);
public void pack(int s);
public void pack(float v[], int n, int stride);
public void pack(float s);
. . .
public void unpack(int v[], int n, int stride);
public int upkint();
public void unpack(float v[], int n, int stride);
public float upkfloat();
. . .
};
Figure 2. jpvmBuffer interface excerpt.
- 5 -
simply and directly through the use of explicit buffers. Pack and unpack operations manipulate the
buffer object on which they are invoked, leading to a simplified interface for dealing with threaded
tasks. This is one example of JPVM’s changes to the standard PVM interface to better support common
Java programming styles such as the use of threads.
After the contents of a message have been marshalled into a jpvmBuffer object, the buffer
can be sent to any task in the JPVM system using the pvm_send() method of the jpvmEnvironment
class. Besides taking the buffer to be sent, pvm_send() also requires the identity of the
task to which to the message should be delivered (in the form of a jpvmTaskId) and an integer
identification number for the message called the message tag. The send operation is asynchronous—
the sending task proceeds immediately after the send is initiated, regardless of when (or if) the message
is received.
To receive messages, tasks must execute the pvm_recv() method of the jpvmEnvironment
class. Using the various versions of pvm_recv() d epicted in Figure 1, tasks can request
messages based on the identity of the message sender, the identification number (tag) of the message,
both of these, or neither (i.e. receive any message). Receive operations block until a message of the
requested type is available (non-blocking pvm_nrecv() versions are also supported, but are not
depicted in Figure 1), at which point a jpvmMessage structure is returned containing the received
message. Besides containing a jpvmBuffer with the message contents, a received jpvmMessage
object contains an indication of the identity of the sender of the message as well as the identification
number of the message, as depicted in Figure 3.
2.3 Program Example
A brief example of a JPVM program is depicted in Figure 4. This task represents the master in a
simple master/slave program organization. Note that t he task is implemented as a standard Java
application object with a public main method. The program first creates a connection to the JPVM
system on line 5 where it allocates a jpvmEnvironment object. It then spawns a set of worker
tasks on line 9. Note, for this s pawn to succeed, a valid Java c lass must be stored in the file
“worker.class” located in a directory listed in the CLASSPATH variable. The spawn operation
creates N new Java Virtual Machine processes, each executing an instance of the class worker, and
returns the identity of these tasks’ first jpvmEnvironment connections.
The loop on lines 11-16 demonstrates the creation of a jpvmBuffer, message marshalling,
and use of the pvm_send() method to send a message to each newly spawned task. This loop
might correspond to farming out work to a group of worker tasks. Correspondingly, the loop on lines
17-21 demonstrates the receipt of messages from each of the worker tasks, which might correspond
to gathering results. On line 22 the program invokes the pvm_exit() method to disconnect from
the JPVM system.
class jpvmMessage {
public int messageTag;
public jpvmTaskId sourceTid;
public jpvmBuffer buffer;
};
Figure 3. jpvmMessage data structure.
- 6 -
2.4 System Configuration
The above discussion of the programming model describes the basic syntax and semantics of the
JPVM library. However, the JPVM library routines require run-time support during execution in the
form of a set of JPVM daemon processes running on the available collection of processors. These
daemon processes are required primarily to support task creation (unlike in standard PVM, JPVM
daemon processes do not perform message routing). JPVM system configuration is a two-phase process.
First, daemon processes must be started manually on all hosts of interest. The daemon program
is provided in the form of a java class (jpvmDaemon), so daemon startup simply involves running
Java Virtual Machine processes to execute the daemon class instances. After the daemons are started,
they must be notified of one another’s existence. This is accomplished through an interactive JPVM
console program. Again, the console program is a java class (jpvmConsole) and should be started
in a Java Virtual Machine process.
Besides adding hosts, the JPVM console can be used to list the hosts available to the system and
JPVM tasks running in the system. An example console session is depicted in Figure 5.
3 Implementation
As was mentioned previously, JPVM is implemented entirely in Java. Although current execution
environments for Java limit performance significantly, the use of Java as a system implementation
language provides a number of distinct advantages over commonly used system implementation
languages such as C. For example, the use of threads in a communications system is an attractive
approach for dealing with the asynchronous activities involved in this type of software. However,
1 import jpvm.*;
2 class example {
3 public static void main(String args[]) {
4 try {
5 jpvmEnvironment jpvm = new jpvmEnvironment();
6
7 // Spawn N worker tasks
8 jpvmTaskId tids[] = new jpvmTaskId[N];
9 jpvm.pvm_spawn("worker",N,tids);
10
11 for (int i=0;i<N; i++) { // Farm out work
12 jpvmBuffer buf = new jpvmBuffer();
13 int work = getWork(i);
14 buf.pack(data);
15 jpvm.pvm_send(buf, tids[i], 123);
16 }
17 for (int i=0;i<N; i++) { // Receive results
18 jpvmMessage message = jpvm.pvm_recv(tids[i]);
19 int result = message.buffer.upkint();
20 processResult(result);
21 }
22 jpvm.pvm_exit();
23 }
24 catch (jpvmException jpe) {
25 System.out.println("Error - jpvm exception");
26 }
27 }
28 };
Figure 4. JPVM programming example.
- 7 -
porting threads-based systems implemented in traditional languages such as C can be a complex and
error-prone task. Java reduces the risks associated with employing threads in system designs by providing
a uniform, portable threads interface and implementation across all supported p latforms.
Another example of the portability advantage of Java is network APIs. Although network-based systems
such as standard PVM are generally portable among Unix variants, they are more difficult to
port t o o ther readily available e nvironments s uch as PCs running Windows NT. For example,
although a wide variety of PVM ports for Unix-based systems have been available for close to a
decade, only in the past year has a Windows based implementation become available. Java essentially
eliminates this issue by providing a uniform, portable interface to operating system services
such as network communication.
Given the portability advantage of Java, we chose to implement the JPVM interface entirely in
Java. In this section we discuss some of the core features of the JPVM system implementation.
3.1 Communications Implementation
In standard PVM, the use of direct task-to-task TCP connections has been found to significantly
outperform the older UDP-based daemon-routed message passing implementation [9]. Thus, the current
internal JPVM message passing implementation is based on direct task-to-task communication
over TCP sockets using the Java object serialization interface for message transfer. Each jpvmEnvironment
instance creates a server socket during initialization and embeds the host name and
port number needed to connect to it within its jpvmTaskId identity. Thus, when JPVM task X
wishes to send a message to JPVM task Y, it simply connects to Y using the host and port contained
within Y’s task identifier, and sends a message over the newly created TCP connection.
Internally, JPVM uses threads to manage connections and message delivery. Each jpvmEnvironment
creates a dedicated thread to listen for and accept peer connections, as depicted in Figure
6. When a connection is accepted by this special dedicated connection management thread, it creates
a new message receiver thread dedicated to the new connection. This receiver thread blocks for messages
on its connection. As it receives messages, it enqueues them on an internal message queue, as
illustrated in Figure 6. Thus when user threads perform pvm_recv() operations, instead of performing
any network input directly, they simply consult the internal message queue for messages of
the appropriate type.
$ java jpvm.jpvmConsole
jpvm> conf
4 hosts:
stonesoup00.cs.virginia.edu
stonesoup01.cs.virginia.edu
stonesoup02.cs.virginia.edu
stonesoup03.cs.virginia.edu
jpvm> ps
stonesoup00.cs.virginia.edu, 2 tasks:
(command line jpvm task)
jpvm console
stonesoup01.cs.virginia.edu, 1 tasks:
mat_mult
stonesoup02.cs.virginia.edu, 1 tasks:
mat_mult
stonesoup03.cs.virginia.edu, 1 tasks:
mat_mult
jpvm>
Figure 5. Example interactive JPVM console session.
- 8 -
An important attribute of the JPVM communications system implementation is thread safety. As
depicted in Figure 6, multiple user threads can concurrently perform pvm_recv() operations—the
internal message queue structure is a synchronized data type that may safely be manipulated by any
number of reader (user) and writer (internal receiver) threads. Similarly, pvm_send() operations
are synchronized to support thread safety. Threads can be employed in a variety of design schemes in
JPVM programs. For example, a traditional threaded server JPVM task is one possibility. Another
possibility is the use of threads as the basic units of parallel execution, as in TPVM [3]. In this
scheme, each thread would be implemented as a normal JPVM task with its own jpvmEnvironment
instance.
3.2 Daemon Services Implementation
The ability to spawn new tasks, to determine and extend system configuration, and to determine
the set of tasks executing in the system is based on services provided by JPVM daemon processes
executing on each host in the JPVM system. The current implementation of the JPVM daemon processes
is layered on the standard JPVM communication mechanism—i.e. the JPVM daemon implementation
is simply a normal JPVM program employing the interface described in Section 2. The
daemon program employs a server style organization, executing a loop that repeatedly blocks for and
then services a new request. For most client requests (e.g. task status, system configuration information)
the daemon can respond immediately. However, for task creation requests the daemon creates a
thread to start the new local process. This design p revents slow response to o ther client requests
while tasks are being created.
4 Performance
To evaluate the performance of the current JPVM implementation we conducted a set of experiments
to quantify the costs of the basic library primitives and to measure actual application performance.
The testbed used for these experiments was a set of five dual-processor Pentium Pro hosts
connected by 10 megabit ethernet. Each host in the system contained two 200 MHz Pentium Pro processors
and 128 MB of memory, and was running Linux 2.0. The version of Java used was the Linux
JDK version 1.1.3.
Figure 6. JPVM communication implementation.
Receiver
Thread 1
Receiver
Thread 2
Receiver
Thread n
Connection
Thread
User
Thread
User
Thread
Message
Queue
TCP Connections
Connection
Requests
JPVM Task
- 9 -
Our first set of experiments measured the cost of task creation. In Table 1 we present the time to
create various numbers of tasks on a single host system and in the full five host system. Since each
host is a dual processor machine, the difference in time to create one or two hosts is negligible. The
cost for task creation is not small—when creating more than one task, approximately 0.5 seconds per
task in the single host system, and between 0.5 and 1.5 seconds per task in the multi-host system are
required. Spawn is somewhat less expensive for small numbers of tasks in the single host system
because less communication is required. For larger numbers of tasks the multi-host system begins to
perform better as it can amortize communications costs by parallelizing the creation of a set of tasks.
Our next set of measurements examined the communication costs associated with JPVM. In
Table 2 we present round-trip message times between two tasks for various message sizes. We performed
these measurements on messages containing integers and raw bytes to examine the overhead
associated with the requirement of masking byte ordering differences. As might be expected, the
message passing overheads introduced by the Java implemented JPVM system are very high—an
order of magnitude of latency is added, and only about an eighth of the available bandwidth is utilized.
Given the high costs associated with both of the basic JPVM primitives, it is tempting to conclude
that the overhead introduced by the strategy of using a Java-implemented system as runtime
support for parallel Java applications outweighs the potential benefits. In fact, the high costs of these
operations does essentially rule out JPVM as a platform for network-intensive applications. However,
for applications that exhibit medium to coarse granularities, and also exhibit some tolerance of
network latencies, JPVM may provide sufficiently efficient services to allow good speedup.
To verify this claim, we measured the performance of a parallel matrix multiplication algorithm
implemented in JPVM and compared to a sequential version of the program also implemented in
Java. In Table 3 we present the results of these experiments for three problem sizes. Times are presented
for both the complete program (including task creation time), and for the multiplication algorithm
alone (excluding task creation time). As might be expected, at the smallest problem size, poor
speedup is achieved for the multiplication algorithm, and slowdown is observed for the program as a
whole. This problem size is simply too fine grained given the basic costs associated with JPVM. At
the middle problem size we find that the multiplication algorithm begins to speed up well, but the
program as a whole has poor efficiency due to the high cost of task creation. Finally, at the largest
problem size, both the multiplication algorithm and the program as a whole speed up well. As
expected, better speedups are ac hieved for the program when task creation costs are excluded.
Although this may seem like an unfair comparison, it provides valuable insight that for long-running
JPVM programs that can amortize task creation costs, good efficiency is possible for the compute/
communicate phases of the program.
tasks 1 host 5 hosts
1 886 2437
2 1075 2509
4 2092 2574
8 4042 3683
16 7938 6156
Table 1. Task creation times,
milliseconds
size int byte
1 byte 240 224
1 KB 271 243
10 KB 293 282
100 KB 1160 846
1 MB 9309 7535
Table 2. Round-trip message costs,
milliseconds
- 10 -
5 Related Work
A number of other systems have been developed to support network parallel programming in
Java. One common approach to this problem is the use of volunteer-based systems such as Bayanihan
[7] and Javelin [2]. As opposed to JPVM which is based on stand-alone Java applications, these
systems are based on Java applets that execute within the context of a web browser. In these systems,
applications are decomposed into sub-tasks that can be downloaded in the form of Java applets by
clients who wish to volunteer computing resources. When the task completes, its result is uploaded
to the server. These approaches have a number of attractive properties, foremost among which is the
possibility of employing the vast array of processing power available in the form of client machines
connected to the web. The primary drawback of these approaches is the significant restrictions placed
on communications by the Java security model for applets. The restriction that downloaded applets
may communicate only with their server essentially limits these systems to applications that can be
decomposed into non -communicating, coarse-grained, completely independent functional t asks.
Although this is possible for many applications such as parameter space studies, it rules out most
potentially successful network parallel applications.
A system similar to JPVM in its programming interface and model is the JavaPVM library [8].
This s ystem also p rovides a PVM-like interface for Java a pplications. The primary d ifference
between JavaPVM and JPVM is in implementation. Unlike JPVM which is implemented entirely in
Java, JavaPVM is based on the Java Native Methods mechanism, providing native method wrappers
around the existing standard PVM routines. This approach has a number of advantages. First, this
approach takes clear advantage of software reuse—the e ffort t o p roduce the PVM library is not
duplicated, and advances in the standard PVM system can be tracked closely. Also, since JavaPVM
is based on native methods wrappers to the standard PVM library, JavaPVM programs are interoperable
with standard PVM programs written in C and Fortran. Furthermore, by using native methods
JavaPVM offers a clear performance advantage in the short term. Currently, systems implemented in
lower-level l anguages such as C can easily o utperform Java-based implementation. However, the
JavaPVM approach is not without drawbacks. First, by using native methods, this system is limited in
its portability. JavaPVM can be used only on platforms where standard PVM is available—for example,
JavaPVM isn’t currently supported on Windows-NT or Macintosh systems. Furthermore, in
being a simple wrapper around the standard PVM implementation, JavaPVM is limited by the
semantic and syntactic features of PVM. For example, JavaPVM programs retain the single communication
end-point PVM model, the thread-unfriendly PVM buffer interface, and so on.
Another software package for network parallel computing in Java is the IceT system [5]. This
problem tasks multiply speedup total speedup
size time time
1 3.2 - 3.2 -
128 4 2.2 1.4 6.6 0.5
9 1.5 2.1 6.7 0.5
1 26.7 - 26.7 -
256 4 7.7 3.5 10.3 2.6
9 4.6 5.9 8.9 3.0
1 223.3 - 223.3 -
512 4 59.7 3.7 64.3 3.5
9 28.9 7.7 33.5 6.7
Table 3. Matrix multiply performance, times in seconds
- 11 -
system addresses a number of concerns not covered by the JPVM design. Whereas JPVM allows a
single user to combine resources on which that user has access privileges, IceT is an inherently collaborative,
multi-user environment. IceT provides mechanisms by which resources can be made
available to the system for use by users who do not have log-on privileges. The attractive goals of this
metacomputing-based approach include better utilization of larger r esources based, as well as an
enhanced collaborative environment for high performance computing. Among the challenges introduced
by this idea are the numerous security issues introduced by code-upload capabilities for nonprivileged
uses.
6 Conclusions
We have described the JPVM system, both in terms of programming model and interface, interactive
interface, and implementation. This system combines the goals of supporting network parallel
programming in Java, providing a familiar and proven-effective programming interface, and taking
advantage of the attractive features of Java as a system implementation language. The combination of
Java as an applications programming language and system implementation languages allows the support
of a number of powerful features in JPVM, including thread safety and multiple communication
end-points per process. Initial performance experiments with the system indicate that the costs associated
with the basic JPVM primitives are quite high, but his is not unexpected given the use of Java
for system implementation. However, we have demonstrated that t he system can support good
speedup for applications that exhibit an appropriately coarse level of granularity, tolerance of network
latency, and ability to amortize task creation costs. Furthermore, these are issues already wellknown
applications programers who employ network parallel programming. Given this observation,
we argue that the added costs associated with a Java-based system do not outweigh the benefits of the
added features, portability, and programming flexibility afforded by Java.
References
[1] T.E. Anderson, D.E. Culler, D.A. Patterson, and the NOW team, “A Case for NOW (networks of
Workstations),” IEEE Micro, vol. 15, no. 1, pp. 54-64, February, 1995.
[2] P. Cappello, B.O. Christiansen, M.F. Ionescu, M.O. Neary, K.E. Schauser, and D. Wu, “Javelin: Internet-
based Parallel Computing Using Java,” ACM Workshop on Java for Science and Engineering
Computation, June, 1997.
[3] A.J. Ferrari and V.S. Sunderam, “Multiparadigm Distributed Computing with TPVM,” Journal of
Concurrency, Practice and Experience, (to appear).
[4] A. Geist, A Beguelin, J. Dongarra, W. Jiang, R. Manchek, and V.S. Sunderam, PVM: Parallel Virtual
Machine, MIT Press, 1994.
[5] P.A. Gray and V.S. Sunderam, “IceT: Distributed Computing and Java,” available from:
لینک ها فقط به اعضای سایت نمایش داده می شوند.
[6] W. Gropp, E. Lusk, and A. Skjellum, Using MPI: Portable Parallel Programming with the Message-
Passing Interface, MIT Press, 1994.
[7] L.F.G. Sarmenta, “Bayanihan: Web-Based Volunteer Computing Using Java,” available from:
لینک ها فقط به اعضای سایت نمایش داده می شوند.
[8] D. Thurman, JavaPVM, available from:
لینک ها فقط به اعضای سایت نمایش داده می شوند.
[9] S. White, A. lund, and V.S. Sunderam, “Performance of the NAS Parallel Benchmarks on PVM
Based Networks,” Journal of Parallel and Distributed Computing, vol. 26, no. 1, pp. 61-71, April
1995.
ترجمه :
JPVM
برنامه نویسی موازی شبکه در جاوا
چکیده:
یک سیستم نرم افزاری برای برنامه نویسی موازی JPVM کتابخانه
بر پایه مخابره پیام ساده می باشد. این MIMD حافظه توزیع شده
و فرترن که توسط C کتابخانه از اینترفیسی شبیه به اینترفیسزبان
تولید می شود پشتیبانی می (PVM) سیستم ماشین مجازی موازی
JPVM گردد، ولی با دستوراتی با ساختار دستورات زبان جاوا. شباھت
سرعت یادگیری بالایی را برای برنامه نویسانی PVM با سیستم رایج
کار کرده اند فراھم می آورد. PVM که قبلاً با سیستم
ھمچنین انتقال برنامه ھای کاربردی موازی را به پلت فرم جاوا، امری
امکان پذیر و کم ھزینه می سازد. علاوه براین ویژگی ھای تازه ای
ھمچون ارتباط امن، نقاط پایان با چند اتصال و ارسال مستقیم پیام به
دیده نمی PVM صورت پیشفرضرا فراھم می آورد که در سیستم ھای
کاملاً مرتبط با جاوا است و ھمچنین تا حد زیادی قابل JPVM . شود
انتقال بین پلت فرم ھایی که تا حدی از جاوا پشتیبانی می کنند. این
ویژگی امکان استفاده از منابع رایج غیر از سیستم ھای برنامه نویسی
و مکینتاشرا NT موازی شبکه، ھمچون سیستم ھای بر پایه ویندوز
ھموار می سازد.
مقدمه:
استفاده ناھمگون از چند سیستم برنامه نویسی مرتبط با یک یا تعداد
بیشتری شبکه به عنوان یک منبع محاسباتی منطقی محاسبات وسیع
با کارایی بالایی را ممکن می سازد. سیستم ھای موازی شبکه، برنامه
ھای کاربردی شخصی را قادر می سازد از قدرت فزاینده منابع شبکه
شده، غیر ھمزمان و اغلب با کارایی بالا که در دسترسکاربران
فراوانی قرار دارد استفاده کند. در این مقاله ما یک سیستم نرم افزاری
محاسباتی موازی شبکه را که به زبان جاوا نوشته شده شرح می
دھیم. به دلیل پلت فرم و اینترفیسیکسان، جاوا محیط جذابی را برای
به کارگیری برنامه ھای کاربردی موازی شبکه و نرم افزار سیستمی
که آن را پشتیبانی می کند، فراھم می آورد. اگر تعداد زیادی از
سیستم ھای نرم افزاری از برخی از سیستم ھای محاسباتی
پشتیبانی می کنند، اکثر آنھا تا حد کمی با پکیج ھایی که امکان ارسال
سازگار (MIMD) پیام ساده مدل برنامه نویسی حافظه توزیع شده
و اینترفیسارسال پیام (PVM) ھستند. از قبیل ماشین موازی مجازی
این سیستم ھای نرم افزاری از اینترفیسھای کتابخانه ای قابل (MPI)
و فرترن C انتقال ساده برای زبان ھای محاسباتی پرکاربرد از قبیل
برنامه نویسرا قادر می ،PVM پشتیبانی می کنند. به عنوان مثال
سازد به برنامه ی ذخیره داده ھا و ارسال پیام غیر ھمزمان، دسترسی
امکاناتی را برای خصوصی سازی و PVM ، داشته باشد. علاوه بر این
مدیریت میزبان ھا که برنامه ھا در آنھا اجرا می شوند، به برنامه نویس
می دھد. نتایج بدست آمده از سیستم ھای محاسباتی موازی شبکه
که در NAS امیدوار کننده بوده است. برای مثال: مطالعه آزمون سویت
صورت گرفت نشان داد که گروه ھای کوچک مرتبط از ایستگاه PVM
ھای کاری می نوانند کارایی ای قابل مقایسه با سوپر کامپیوترھای
بسیار گرانتر داشته باشد. اگر چه استفاده از منابع غیر ھمزمان توزیع
شده و متصل در یک شبکه به عنوان یک کامپیوتر واحد مجازی مشکلات
جدی بسیاری برای برنامه ھای کاربردی و برنامه نویسان به وجود می
آورد. برای مثال از منظر برنامه ھای کاربردی، مشخصشد که برنامه
ھای موفق موازی شبکه تقریباً ھمواره در زمینه تنظیم جزئی و
موردی، متوسط عمل کردند و در برابر فعالیت ھای پنھانی شبکه دوام
داشته اند. مثلاً برای استفاده در سبک برنامه نویسی پیشارسال
این ویژگی ھا می توانند برای دسترسی به برخی .،(send_ahead)
کاربردھا مشکل ساز باشند. از دید برنامه نویسسیستم، نتایج
گرفته تا ماشین پلت (tasks) ناھمگون در مسائل دشوار مانند کارھا
.(system portability) فرم (سکوی اجرا) و قابلیت انتقال سیستم
زبان جاوا ویژگی ھایی را پدید می آورد که احتمالاً ابزارھایی برای
آدرسدھی و حل مشکلات اصلی برنامه نویسی موازی شبکه در
اختیار خواھد گذاشت. برای مثال، از دید برنامه ھای کاربردی، جاوا
اینترفیسی یکپارچه و قابل انتقال برای رشته ھا (پروسیجر ھای
به (threads: اجرایی ای که قسمتی از یک برنامه کاربردی ھستند
وجود می آورد. استفاده از رشته ھا به جای پروسه ھای سنگین
سنتی، به عنوان راه اصلی افزایشتوانایی شبکه و قدرت محاسباتی
برای دستیابی به کارایی مناسب در حافظه توزیع شده ی محیط ھای
پردازشموازی شناخته شده است. در زمینه قدرت اجرایی سیستم،
یکپارچه برای سرویسھای API جاوا از سطح بالایی از انتقال کد و
سیستم عامل، ھمچون ارتباطات شبکه پشتیبانی می کند.
یک سیستم نرم افزاری برای برنامه نویسی موازی JPVM کتابخانه
بر پایه مخابره پیام ساده می باشد. این MIMD حافظه توزیع شده
و فرترن که توسط C کتابخانه از اینترفیسی شبیه به اینترفیسزبان
تولید می شود پشتیبانی می (PVM) سیستم ماشین مجازی موازی
با JPVM کند، ولی با دستوراتی با ساختار دستورات زبان جاوا. شباھت
سرعت یادگیری بالایی را برای برنامه نویسانی که PVM سیستم رایج
کار کرده اند فراھم می آورد. PVM قبلاً با سیستم
ھمچنین انتقال برنامه ھای کاربردی موازی را به پلت فرم جاوا، امری
امکان پذیر و کم ھزینه می سازد. علاوه براین، ویژگی ھای تازه ای
ھمچون ارتباط امن، نقاط پایان با چند اتصال و ارسال مستقیم پیام به
دیده نمی PVM صورت پیشفرضرا فراھم می آورد که در سیستم ھای
کاملاً مرتبط با جاوا است و ھمچنین تا حد زیادی قابل JPVM . شود
انتقال بین پلت فرم ھایی که تا حدی از جاوا پشتیبانی می کنند. این
ویژگی امکان استفاده از منابع رایج غیر از سیستم ھای برنامه نویسی
و مکینتاشرا NT موازی شبکه، ھمچون سیستم ھای بر پایه ویندوز
ھموار می سازد.
را شرح JPVM در این مقاله ما اینترفیس، پیاده سازی و اجرای سیستم
شامل مدل برنامه JPVM می دھیم. در بخشاینترفیسسیستم
نویسی و میز فرمان اینتراکتیو، در بخش ٣ ویژگی ھای کلیدی پیاده
کامل در حال کار، در بخش ۴ نتایج اولیه بدست آمده JPVM سازی اولیه
و در بخش ۵ سیستم ھای مرتبط شرح داده خواھد JPVM از بکارگیری
شد. در بخش ۶ نیز نتیجه گیری خواھیم کرد.
اینترفیس:
بسیار شبیه به JPVM اینترفیسبرنامه نویسی ساخته شده توسط
پشتیبانی می شود، علاوه بر این PVM اینترفیسی است که توسط
توسعه ھایی نیز برای بھره برداری بھتر از فواید نھفته جاوا به عنوان
یک زبان برای اجرای برنامه ھای کاربردی موازی شبکه به آن افزوده
برنامه نویسمشکلات را برای حل تجزیه می ،PVM شده است. ھمانند
زنجیره ای پیشرود. این کارھا توسط (task) کند، تا در اجرای کارھای
یک مجموعه از پردازشگرھای در دسترساجرا می شوند و یک سری
از کتابخانه ھای به خصوصرا برای کنترل ایجاد کارھای افزوده و
ارسال پیام بین کارھا فراخوانی می کنند.
اجرای کارھا، در جاوا کد می شوند و پشتیبانی برای ایجاد JPVM در
انجام می شود. JPVM کارھا و ارسال پیام توسط کتابخانه
در آن جای دارد توسط JPVM اینترفیسمرکزی که بیشتر تعاملات
جاوا اکسپورت می شود. نمونه ھای این jpvmEnvironment کلاس
JPVM شناسایی می شوند تا به سیستم JPVM کلاستوسط کارھای
و دیگر اجرا کننده ھای سیستم متصل و با آنھا وارد تعامل شوند. اشیاء
این کلاسنقاط پایان ارتباطات با سیستم را نشان می دھند و توسط
شناسایی می jpvmTaskId شناساگرھای یکپارچه سیستم گسترده
استاندارد، ھر کار PVM در حالی که .( PVM شوند(به جای شناساگر کار
را به داشتن یک نقطه پایان ارتباطی (و به تبع آن داشتن یک شناساگر)
به ھر یک از کارھا اجازه می دھد با اختصاص JPVM ، محدود می کند
دادن چندگانه اینستنسھای (شیء خاصی از یک کلاسدر برنامه
بینھایت نقطه اتصال jpvmEnvironment (instance: نویسی شیء گرا
داشته باشند. قابلیت داشتن چندین نقطه پایان ارتباطی در یک کار،
پروسه توسعه جداگانه ماژول ھای قابل اتصال که نیاز به ارتباط دارند
را ساده خواھد کرد. جداسازی اولیه جریان ھای اتصال، نیاز به
شناسایی مجازی پیام ھای ماژول ھای مختلف را از بین می برد. بعد از
یک کار با توانایی فراخوانی jpvmEnvironment تخصیصیک شیء از
و ارسال پیام (task creation) از قبیل ایجاد کار JPVM سرویسھای
خواھیم داشت. برای مثال، یک کار می تواند (message passing)
تعیین pvm_myid( ) با فراخوانی متد JPVM خاصیت خود را برای اتصال
را از سیستم jpvmEnvironment یک pvm_exint( ) کند یا با فراخوانی
در شکل یک نشان jpvmEnvironment جدا سازد. اینترفیسپایه JPVM
داده شده است.
jpvmEnvironment شکل ١: اجرای
(task creation) ١٫٢ . ایجاد کار
انجام می گیرد ایجاد JPVM اولین عملی که توسط یک برنامه جامع
توسط متد JPVM کارھای اضافی برای اجرای موازی است. ایجاد کار در
پشتیبانی می شود. این متد یک پارامتر رشته ای که pvm_spawn( )
نام یک کلاسصحیح جاوا و قابل مشاھده در متغیر محیطی
و ھمچنین تعداد کارھایی که قرار است تولید شوند و یک CLASSPATH
ھایی از کارھایی که اخیراً ایجاد شده اند و jpvmTaskId آرایه از
بازگشت موفق خواھند داشت دریافت می کند. ھر کاری که توسط
ایجاد می شود در اینستنس مخصوصخودشدر pvm_spawn( )
ماشین مجازی جاوا اجرا می گردد که باعث عدم تداخل در بکارگیری
سرویسھا، در حین اجرای کارھا در سیستم می شود. این اینستنس
PVM می شود. در JPVM ھای جدید باعث بروز مشکلات پایه ای برای
شناسایی یک کار به طور مشخصاز یک نقطه پایان ارتباطی و به تبع
کارھا می توانند به ھر ،JPVM آن یک شناساگر کار انجام می شود. در
تعداد نقطه پایان ارتباطی داشته باشند.و این ارجاع آنھا به کارھای
بالایی را مشکل می سازد. یک راه حل ساده می تواند حذف ارجاع
باشد. کارھای تکثیر شده می spawm شناساگرھای کار از اینترفیس
توانند خاصیت ھای خود را برای اتصال مستقیم با کارھای بالایی به کار
و جلوگیری از لزوم PVM گیرند. به منظور حفظ شباھت اینترفیسبا
این موارد را با ارجاع خاصیت JPVM ، کدنویسی اضافی
که توسط ھر یک از کارھای تکثیر شده اختصاص jpvmEnvironment
یافته آدرسدھی می کند. این امر باعث ایجاد محیطی شبیه به محیط
می گردد. PVM
٢٫٢ . ارسال پیام:
pvm_recv() و pvm_send() توسط متدھای JPVM ارسال پیام در
انجام می گیرد. اگر چه قبل از اینکه داده jpvmEnvironment کلاس
جمع آوری شود. در jpvmBuffer() بتواند تکثیر شود باید توسط شیء
حاوی محتوای پیام ھای jpvmBuffer اشیاء ،PVM مقایسه با بافر ھای
نشان داده شده در شکل ٢) دو ) jpvmBuffer ھستند. اینترفیس jpvm
گروه پایه از متد ھا را شامل می شود: آنھایی که داده را در بافر بسته
بندی می کنند و آنھایی که داده ھا را استخراج می کنند. در جایی که
over ممکن باشد، در اینترفیساز اورلودینگ (بارگذاری اضافی
برای ساده سازی کد برنامه کاربردی استفاده می شود. (loading
عملیات برداری و غیر برداری بسته بندی و باز کردن برای تمامی انواع
فراھم می شود. jpvmTaskId و string پایه جاوا و ھمچنین اشیاء
jpvmBuffer شکل ٢. قطعه اینتفیس
استاندارد، ماھیت PVM و بافرھای JPVM یک تفاوت مھم میان بافرھای
استاندارد، PVM می باشد. در JPVM ساده ی ساختار داده ھای بافر
و pvm_pk*() ارسال و دریافت داده ھا توسط روتین ھای کتابخانه ای
انجام می گیرد. در حالی که روتین ھا برای مدیریت pvm_upk*()
چندین بافر تولید شده اند، ماھیت مجازی بافر در حال بسته بندی یا باز
شدن باعث تعامل مشکل تر با برنامه ھای رشته ای می شود. در
اگر یک رشته در حال بسته بندی یک بافر است و رشته دوم بافر ،PVM
دیگری را بسته بندی می کند، این رشته ھا باید ارسال بافر را قبل از
روتین ھر پک(بسته) تنظیم کنند.(زیرا رشته دیگر ممکن است تنظیمات
خود را روی آن اعمال کند) علاوه بر این، یک مکانیزم ھمزمانی ھمچون
باید برای حصول اطمینان از اینکه بافر ارسال شده (lock) یک قفل
توسط رشته ی دیگری تنظیم نگردیده نیز به کار گرفته می شود. این
این مشکل با استفاده از JPVM یک نیاز پیچیده و غیر ضروری است. در
بافر ھای ساده به راحتی حل شده است. عملیات بسته بندی و باز
کردن شیء بافر را در جایی که فراخوانی شده اند کنترل می کند و این
باعث ساده شدن اینترفیسکارھا می شود. این یک مثال از تغییرات
استاندارد، برای پشتیبانی بھتر از قالب ھای رایج PVM نسبت به JPVM
برنامه نویسی جاوا ھمچون استفاده از رشته ھا می باشد.
جمع آوری شد، بافر jpvmBuffer بعد از اینکه محتویات پیام در شیء
jpvmEnvironment از کلاس pvm_send() می تواند با استفاده از متد
ارسال شود. علاوه بر این JPVM به ھر یک از کارھای سیستم
به شاخصشناسایی کاری که قرار است بافر به آن pvm_send()
جمع آوری شد، بافر می تواند با (jpvmTaskId تحویل گردد (در قالب
به ھر یک از jpvmEnvironment از کلاس pvm_send() استفاده از متد
به pvm_send() ارسال شود. علاوه بر این JPVM کارھای سیستم
شاخصشناسایی کاری که قرار است بافر به آن تحویل داده شود (در
و یک مقدار اینتیجر (عددی) شناسایی که برچسب (jpvm_TaskId فرم
پیام نامیده می شود نیز نیاز دارد. ارسال پیام بدون توجه به اینکه پیام
کی دریافت شده یا اصلاً دریافت شده یا خیر به طور غیر ھمزمان
بلافاصله بعد از شروع ارسال می تواند انجام شود. برای دریافت پیام
را اجرا کند. jpvmEnvironment از کلاس pvm_recv() کار باید متد
در شکل ١ نشان داده شده اند. کارھا pvm_recv() حالت ھای مختلف
می توانند پیام ھا را بر اساسشناسایی ارسال کننده پیام، شماره
شناسایی (برچسب) پیام، ھر دوی اینھا یا ھیچکدام دریافت کند.
عملیات ارسال پیام، تا زمان در دسترسقرار گرفتن پیام به طور کامل،
غیر فعال است. (البته حالت آزاد آن نیز وجود دارد ولی در شکل نمایش
به ھمراه محتوای jpvmMessage داده نشده است.) تا اینکه ساختار
دریافت شده یک شناسه از ارسال کننده پیام jpvmMessage پیام، یک
و شماره شناسایی پیام را نیز شامل می شود، که در شکل ٣ نشان
داده شده است.
jpvmMessage شکل ٣. ساختار داده
٢٫٣ . نمونه برنامه:
در شکل ۴ نمایشداده شده است. JPVM یک مثال کلی از برنامه ی
توجه داشته باشید که کار ھمانند برنامه ھای استاندارد جاوا با متد
در خط ۵ JPVM اجرا شده است. برنامه ابتدا یک ارتباط با سیستم main
تخصیصداده می شود برقرار jpvmEnvironment جایی که یک شیء
می کند. سپسدر خط ٩ یک تنظیم از کارھای در حال اجرا تکثیر می
شود. توجه کنید که برای عملکرد موفق این تکثیر، یک کلاسجاوای
در شاخه ای که در متغیر worker.class صحیح می بایست در فایل
پردازش N ، لیست شده قرار داشته باشد. عملگر تکثیر CLASSPATH
ماشین مجازی جاوای جدید می سازد، ھر یک قسمتی از کلاس
را اجرا می کند و شناسه ی ارتباط ھای اول worker
ای ن کارھا را باز می گرداند. حلقه ای که در jpvmEnvironment
جمع آوری پیام و استفاده ،jpvmBuffer ١١ آمده ساخت یک - خطوط ١۶
برای ارسال به ھر ی از کارھای تکثیر شده را pvm_send() از متد
١٧ آمده پیام ھر یک - نشان می دھد. . متقابلاً حلقه ای که در خطوط ٢١
از کارھا را نشان می دھد که ممکن است مشابه با گردآوری نتایج
JPVM را برای قطع با سیستم pvm_exit() باشد. در خط ٢٢ برنامه متد
فراخوانی می کند.
JPVM شکل ٤. مثال برنامه نویسی
۴٫٢ . پیکر بندی سیستم:
بحث بالا در مورد مدل برنامه نویسی، اصول دستوری پایه و کتابخانه
توضیح می JPVM توضیح می دھد. اگر چه روتین ھای کتابخانه JPVM
در حین اجرا در فرم پردازش JPVM دھد. اگر چه روتین ھای کتابخانه
که روی پردازشگرھای در دسترسعمل می کند. JPVM Deamon ھای
این پردازشھای دیمون برای پشتیبانی از ایجاد کار ضروری ھستند.
روتین پیام را JPVM استاندارد، پردازشھای دیمون PVM (بر خلاف
یک پروسه دو مرحله ای JPVM انجام نمی دھند.) پیکر بندی سیستم
است. اول باید پردازشھای دیمون در تمامی میزبان ھا به طور دستی
شروع شوند. یک برنامه دیمون در جاوا به شکل یک کلاسایجاد می
بنابراین شروع ما تنھا شامل راه اندازی (jpvmEnvironment) . شود
پردازشھایب ماشین مجازی جاوا برای اجرای اینستنسھای کلا
دیمون می شود. بعد از آغاز برنامه ھای دیمون، آنھا باید از وجود دیگری
مطلع شوند. این امر توسط یک برنامه تعاملی میز فرمان یا کنسول
انجام می گیرد. خود برنامه کنسول نیز یک کلاسجاوا (console)
است و باید در یک پردازشماشین مجازی جاوا آغاز شود. در کنار
می تواند برای لیست کردن میزبان JPVM افزودن میزبان، میز فرمان
در حال اجرا در سیستم JPVM ھای در دسترسسیستم و کارھای
مورد استفاده قرار می گیرد.
(implementation) ٣. پیاده سازی
کاملاً در جاوا پیاده سازی می شود. JPVM ، ھمان طور که قبلاً ذکر شد
اگر چه محیط ھای پیاده سازی جاوا محدودیت ھای به ھمراه دارند،
ولی استفاده از جاوا به عنوان زبان پیاده سازی سیستم امتیازات
دارد. C مشخصی در برابر سیستم ھای رایج استفاده شده ھمچون
برای مثال استفاده از رشته ھا در سیستم ھای ارتباطی روشجذابی
برای فائق آمدن بر فعالیت ھای ناھمگون اینگونه نرم افزارھا است.
JPVM interactive console session شکل ٥. مثالی از
وارد کردن سیستم ھای مبنی بر رشته ھای پیاده سازی شده در زبان
می تواند امری پرخطا و پیچیده باشد. جاوا با C ھای سنتی ھمچون
این (portable) پشتیبانی از یک اینترفیسپیشرفته و قابل انتقال
مشکل را حل نموده است و در تمامی پلت فرم ھای پشتیبانی شده
قابل پیاده سازی است. مثال دیگری از امتیاز انتقال پذیری جاوا.
PVM ھای شبکه ھستند. اگر چه سیستم ھای بر پایه ھمچون API
ھای گوناگون قابل انتقال ھستند، اما اکثراً به Unixs استاندارد در
دچار NT ھا ھمچون ویندوز ھای PC ھنگام اجرا در سیستم ھای رایج
استانداردی که در ده PVM مشکل می شوند. برای مثال سیستم ھای
سال اخیر در تمامی یونیکسھا قابل اجرا بودند تنھا در یک سال
گذشته در سیستم ھای برپایه ویندوز قابل پیاده سازی شدند و جاوا
این مشکل را به طور کامل از پیشرو برداشته است. این امتیاز باعث
را کاملاً در جاوا پیاده سازی کنیم. JPVM شد ما تصمیم بگیریم سیستم
در این بخشکا در مورد برخی از ویژگی ھای ھسته پیاده سازی
بحث می کنیم. JPVM سیستم
١٫٣ . پیاده سازی ارتباطات:
(task-to-task) کار به کار TCP استاندارد، استفاده از ارتباطات PVM در
غیر قابل اجرا بوده است. UDP در سیستم ھای مبنی بر
مبنی بر ارتباط کار به کار JPVM بنابراین پیاده سازی ارسال پیام داخلی
با استفاده از اینترفیسانتقال پیام TCP مستقیم روی سوکت ھای
شیء جاوا انجام می گیرد.
یک سوکت سرور در حین آماده jpvmEnvironment ھر اینستنس
سازی و قالب بندی تولید می کند و نام میزبان و شماره پورت لازم برای
می خواھد یک X jpvm اتصال به آن را درج می کند. بنابراین وقتی کار
ارسال کند، کافی است نام میزبان و شماره پورت Y jpvm پیام به کار
جدیدی که TCP دریافت کند و پیام را از طریق ارتباط Y آن را از شناساگر
برقرار شده ارسال کند.
برای ارسال و دریافت پیام و مدیریت ارتباط ھا از رشته ھا JVPM
یک رشته jpvmEnvironment استفاده می کند. ھر (thread)
اختصاصی برای شنیدن و ایجاد ارتباط تولید می کند. (شکل ۶ را ببینید)
وقتی یک ارتباط از طریق یک رشته مدیریت ارتباط قبول می شود،
رشته ای مخصوصبرای دریافت پیام از طریق آن ارتباط ایجاد می
شود. بعد از اینکه پیام دریافت شد رشته ی مورد نظر پیام ھا را در یک
آرایه صف بندی می کند. بنابراین زمانی که رشته کاربر عملگر
را اجرا می کند، به جای ایجاد یک ارتباط برای دریافت pvm_send()
پیام، پیام ھای دریافت شده و صف بندی شده پردازشمی شوند.
JPVM پیاده سازی ارتباط
رشته ھای امن آن است. JPVM یک خصیصه مھم سیستم ارتباط
ھمانطور که در شکل ۶ می بینید، چندین رشته میب توانند در ان واحد
را اجرا کنند پیام ھای دریافت شده و صفبندی شده به pvm_send()
راحتی می توانند توسط رشته ھای خواننده و نویسنده به صورت امن
نیز می تواند رشته ھا را pvm_send() پردازششوند. ھمچنین عملگر
در انواع ،JPVM به صورت امن پشتیبانی نماید. رشته در برنامه ھای
مختلفی از طراحی ھای برنامه نویسی به کار گرفته شوند. برای مثال
سنتی است. امکان دیگر استفاده از رشته JPVM یک امکان، کار سرور
ھا به عنوان واحد ھای پایه ی اجرای موازی است.
JPVM در این طراحی، ھر رشته باید به عنوان یک کار عادی ،TPVM مثل
خودشپیاده سازی شود. JPVM Environm با اینستنس
برنامه سرور برای یک )Deamon ٢- پیاده سازی سرویسھای -٣
پروتکل ویژه) توانایی تکثیر کارھای جدید، برای تعیین و گسترش
پیکربندی سیستم و تعیین اجرای کارھا در سیستم بر پایه سرویس
در ھر میزبان انجام می JPVM Deamon ھایی که توسط پردازشھای
شود.
در مکانیزم JPVM Deamon پیاده سازی فعلی پروسه ھای
لایه بندی شده است. این عملیات (i.e.) JPVM استانداردھای ارتباطی
است که در بخش ٢ JPVM به سادگی بکارگیری یک برنامه معمولی
یک سازمان سبک سرور را در Deamon توضیح داده شد. یک برنامه
اختیار می گیرد و با یک حلقه مرتبا بلاک ھایی تولید کرده و برای
درخواست بعدی سرویسدھی می کند. برای اکثر درخواست ھای
اطلاعات پیکربندی سیستم e.g. وضعیت کار – (Client) سمت مشتری
بلافاصله پاسخ می دھد. اگر چه، برای درخواست ایجاد کار، Deamon
بلافاصله پاسخ می دھد. اگر چه، برای درخواست ایجاد کار، Deamon
یک رشته جدید برای شروع یک پردازشمحلی جدید ایجاد Deamon
می کند. این طراحی از کند شدن پاسخدھیبه سابر درخواست ھا به
ھنگام ایجاد کارھای جدید جلوگیری می کند.
(Performance) عملکرد
یک آزمایشانجام JVPM ما برای ارزیابی عملکرد جریان پیاده سازی
دادیم تا ھزینه ی کتابخانه پایه اولیه و عملکرد واقعی برنامه کاربردی را
اندازه بگیریم ابزار آزمایشیک دستگاه از ۵ عدد پردازشگر جفتی
١٠ متصل بودند. ھر میزبان MB بود به شبکه اترنت Pentium Pro
١٢٨ حافظه ھر MB و Pentium Pro ٢٠٠ مدل MHZ شامل دو پردازشگر
کار می کرد. ورژن جاوای استفاده Linux بود و تحت سیستم عامل . 2.0
بود. JPK شده در سیستم عامل ھای لینوکس 1.1.3
او این دستگاه آزمایشما ، زمان مصرفی ایجاد کار را اندازه گرفت. در
جدول ١، زمان ایجاد کار در دو سیستم یک پردازشگری و سیستم کامل
۵ پردازشگر اندازه گرفتیم. ھمانطور که می بینید برای ایجاد یک کار
سیستم ١ پردازشگری بھتر عمل می کند زیرا ارتباط ھای کمتری مورد
نیاز است.
اما در مواردی که تعداد کارھای ایجاد شده افزایشمی یابد عملکرد
سیستم ۵ پردازشگری بھتر است زیرا می تواند با موازی سازه
ارتباطات زمان مصرفی آن را کاھشمی دھد.
جدول ھا
را اندازه می گیرد. در JVPM آزمایشبعدی زمان ارتباط با استفاده از
جدول ٢ زمان رفت و برگشت پیام بین دو کار برای اندازه ھای متفاوت
پیام ھا نشان داده شده است. این اندازه گیری ھا برای دو نوع متفاوت
اینتیجر و ناخالصدر حجم ھای مختلف اندازه گیری شده است.
ھمانطور که انتظار می رفت سرعت ارسال پیام سیستم پیاده سازی
با جاوا بسیار بالا است. JVPM شده
پایه ای به ھمراه دارد، این JVPM زمان بالایی که استفاده از دستورات
فکر را در ذھن می پروراند که تعریف او دھد با استفاده از استراتژی
(runtime) سیستم ھای مبتنی بر جاوا به عنوان پشتیبانی زمان اجرا
برای برنامه ھای کاربردی موازی جاوا فواید بالقوه فراوانی دارد. در
را به عنوان یک پلت فرم برنامه ھای کاربردی JVPM واقع این زمان بالا
متمرکز شبکه رد می کند. اگر چه برای برنامه ھایی که سطح چند
شاخه ای متوسطی دارند و ھمچنین توانایی بازیابی شبکه کافی
می تواند سرویسھای کارآمد و مناسبی برای افزایش JVPM ، دارند
سرعت به ھمراه داشته باشد. برای اثبات این ادعا، ما عملکرد یک
را با یک نسخه JVPM الگوریتم ضرب ماتریسپیاده سازی شده در
زنجیره ای از برنامه ای که آنھا ھم در جاوا پیاده سازی شده بود
مقایسه کردیم. در جدول ٣ ما نتایج سه سایز از از مسائل را آماده
کردیم.
زمان ھا برای دو بازه اجرای کامل برنامه ( شامل ایجاد کار) و محاسبه
الگوریتم ضرب ( به غیر از زمان ایجاد کار) اندازه گیری شده اند. ھمان
طور که انتظار می رفت در مسائلی که حجم پائینی دارند افزایش
سرعت برای الگوریتم ضرب بسیار ناچیز بود و برای کل برنامه کاھش
سرعت مشاھده شد.
در سایز متوسط در حل الگوریتم افزایشسرعت خوبی مشاھده شد
ولی برای کل مساله به علت زمان زیادی که صرف ایجاد کار می شود
کار این ضعیف بود.
و سرانجام برای بزرگترین سایز در ھر دو قسمت حل الگوریتم ضرب و
کل مساله افزایشسرعت خوبی مشاھده شد. ھمانطور که انتظار
می رفت پاسخگوئی با در نظر نگرفتن زمان ایجاد کار با سرعت خوبی
انجام می گیرد اگر چه این مقایسه منصفانه ای به نظر نمی آید، اما
دیدگاه خوبی برای برنامه ھای حجم که در آنھا زمان ایجاد کار قابل
اغماضاست در ذھن می آورد. کارایی مناسب در بعد محاسباتی/
ارتباطی برنامه امکان پذیراست.
جدول
۵- سیستم ھای مرتبط
سیستم ھای دیگری را نیز برای پشتیبانی از برنامه نویسی موازی
شبکه در جاوا توسعه داده شد. در برخی از آنھا از سیستم ھای
.Javelin و Bayanihan اختیاری استفاده شده ھمچون
که بر پایه برنامه ھای کاربردی مستقل بنا نھاده شده، JVPM بر خلاف
این سیستم ھا تحت پلت ھای جاوا که توسط مرورگرھای وب اجرا می
شوند به اجرا در می آیند. در این سیستم ھا برنامه کاربردی به دلخواه
کاربر می تواند دانلود و اجرا شود. وقتی یک کار به پایان می رسد
نتیجه آن به سمت سرور آپلود می شود. این روشچند امتیاز دارد، که
مھمترین آنھا امکان به کارگیری قدرت پردازشطیف وسیعی از مشتری
ھای متصل به وب است. محدودیت اجرایی جاوا به علت ریسک ھای
امنیتی ١ پلت ھا است.
از نظر مدل و اینترفیسکتابخانه JPVM یک سیستم اشتباه با
است. [ ٨] این سیستم ھمچنین یک اینترفیسمشابه با JAVAPVM
برای برنامه ھای کاربردی جاوا فراھم می آورد. تفاوت اصلی PVM
که JPVM در نحوه پیاده سازی آنھاست. بر خلاف JPVM با JAVAPVM
بر پایه مکانیزم متدھای JAVAPVM ، کاملا در جاوا پیاده سازی می شود
استوار است. این روشچند امتیاز (Java Native method) بومی جاوا
دارد. اول اینکه از امتیاز باز خوانی نرم افزارھا بدون تلاشبرای ایجاد
بر JAVAPVM برخوردار است. ھمچنین از آنجا که PVM مجدد کتابخانه
استاندارد کار می کند، برنامه ھای PVM پایه رپرھای متدھای بومی در
نوشته Fortran و C استاندارد که با زبان ھای PVM آن با برنامه ھای
Java شده اند سازگارتر است. علاوه بر این با استفاده از متدھای بومی
عملکرد سریع تری خواھد داشت. از طرقی با استفاده از متدھای PVM
تنھا در پلت فرم Java PVM . بومی این سیستم در انتقال محدودیت دارد
استاندارد آنھا وجود دارد امکان اجرا دارد و برای مثال در PVM ھایی که
Java PVM قابل اجرا نمی باشد. علاوه بر این NT سیستم ھای ویندوز
چند تفاوت مھم از نظر دستوری نیز دیده می شود. برای مثال برنامه
تنھا قادرند یک نقطه پایان ارتباطی داشته باشند Java PVM ھای
استاندارد و PVM ھمچنین رشته ھایی غیر ھمسان با اینترفیسبافر
غیره.
پکیج نزم افزاری دیگری که برای برنامه نویسی موازی شبکه در جاوا
است [ ۵]. این سیستم برخی از کمبودھای ICET وجود دارد سیستم
تنھا به یک کاربر JPVM را پوششمی دھد. در حالی که JPVM سیستم
اجازه دسترسی به منابع و ترکیب آنھا را با سطح دسترسی تعیین
به طور ذاتی محیط مولتی یوزر یا چند کاربره دارد. ICET شده می دھد
مکانیزمی دارد که در آن کار برای بدون داشتن اجازه دسترسی ICET
می توانند به منابع دسترسی داشته باشند. نتیجه این امر دستیابی به
امکان استفاده از منابع بیشتر در حد محیط ھای پیشرفته کامپیوترھای
بسیار قوی است. اما موضوعی که باعث مخالفت با این ساختار می
None شود مشکلات امنیتی متعددی است که با آپلود قابلیت کدھای
به وجود می آید. Privilaged
۶- نتیجه گیری
شروع داده شد، از دیدگاه مدل برنامه JPVM در این مقاله سیستم
نویسی و اینترفیس، اینترفیستعاملی (اینتراکتیور) و پیاده سازی. این
نوع سیستم از جاوا در برنامه نویسی موازی شبکه، تولید یک محیط
آشنا و کاربردی برنامه نویسی و استفاده از آن به عنوان زبان پیاده
سازی سیستم بھره می برد. استفاده از جاوا در ھر دو قسمت زبان
برنامه نویسی برنامه ھای کاربردی و زبان پیاده سازی سیستم باعث
ھمچون ایجاد رشته JPVM پشتیبانی از چند ویژگی قدرتمند در سیستم
ھای امن و نقاط پایان ارتباطی چندگانه در ھر پردازشمی شود.
ما نشان دادیم که این سیستم می تواند در برنامه ھایی که شامل
تولید سطح بالایی از کارھا می شوند باعث افزایشسرعت شود، در
برابر ھفتگی شبکه دوام داشته باشد و زمان لازم برای ایجاد کار را
کاھشدھد.
علاوه بر این برای برنامه نویسان برنامه ھای کاربردی که از برنامه
نویسی موازی شبکه استفاده می کنند کاملا شناخته شده است. با
این دید نشان دادیم که برخی از مشکلات زمانی که با سیستم ھای
مبنی بر جاوا ھمراه است نمی تواند فواید آن ویژگی ھای فراوان،
قابلیت انتقال و انعطاف پذیری زبان جاوا را پوششدھد.
vBulletin® v4.1.11, Copyright ©2000-2012, Jelsoft Enterprises Ltd.