\chapter{Conclusion}
\label{chap:conclusion}

\pagestyle{myheadings}
\markright{CHAPTER~\ref{chap:conclusion}. CONCLUSION}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Conclusion}
We have explored the practicality of doing parallel computing in Java,
and of providing Java interfaces to High Performance Computing
software.  For various reasons, the success of this exercise was not a
foregone conclusion.  Java sits on a virtual machine model
significantly different to the hardware-oriented model that C or
Fortran exploit directly.  Java discourages or prevents direct access
to the some of the fundamental resources of the underlying hardware
(most extremely, its memory).

Our earliest experiments in this direction involved working entirely
within Java, building new software on top of the communication
facilities of the standard API.  The work in Chapters
\ref{chp:mpiJava} and \ref{chap:objseri} involved creating a Java
interface to an existing HPC package.  Which is the better strategy?
In the long term Java may become a major implementation language for
large software packages like MPI.  It certainly has advantages in
respect of portability that could simplify implementations
dramatically.  In the immediate term recoding these packages does not
appear so attractive.  Java wrappers to existing software look more
sensible.  On a cautionary note, our experience with MPI suggests that
interfacing Java to non-trivial communication packages may be less
easy than it sounds.  Nevertheless, we intend to create
a Java interface to an existing run-time library for data parallel
computation.

So is Java, as it stands, a good language for High Performance
Computing?

It still has to be demonstrated that Java can be compiled to code of
efficiency comparable with C or Fortran.  Many avenues are being
followed simultaneously towards a {\em higher performance} Java. 
%For
%example, besides the Java chip effort of Sun, it has been reported in
%an earlier workshop \cite{syracuse} that IBM is developing an
%optimizing Java compiler that produces binary code directly, that Rice
%University and Rochester University are working on optimization and
%restructuring of bytecode generated by {\em javac}, and that Indiana
%University is working on source restructuring to parallelize Java.
%Parallel interpretation of bytecode is also an emerging practice.  For
%example, the IBM JVM, an implementation of JVM on shared memory
%architectures, was released in spring 1996, and UIUC has recently
%started work aimed at parallel interpretation of Java bytecode for
%distributed memory systems.
%
%Another promising approach under investigation \cite{ii/cvm} is to integrate 
%interpretation and compilation techniques for parallel execution of
%Java programs. In such a system, a partially ordered set of {\em interpretive
%frames} is generated by an 
%{\em II/CVM compiler}. A frame is a description of some subtask, 
%whose granularity may range from a single scalar assignment statement to 
%a solver for a system of equations.
%Under supervision of the virtual machine (II/CVM), 
%the actions specified in a frame may be performed in one of three ways:
%\begin{itemize}
%\item
%Executed by an {\em interpretive module} directly, which also
%incorporates JIT compilation capability.
%\item
%Some precompiled {\em computational library} function is invoked
%locally to accomplish the task; this function may be executed
%sequentially or in parallel.
%\item
%The frame is sent to some {\em registered remote system}, which
%will get the work done, once again either sequentially or in
%parallel.
%\end{itemize}
%With this approach, optimized binary codes for {\em well formed} computation
%subtasks exist in runtime libraries, supporting a high level 
%interpretive environment. Task parallelism is observed among different
%frames executed by the three mechanisms simultaneously, while data 
%parallelism is observed in the execution of some of the runtime functions.
%
%Presuming these efforts satisfactorily address the performance issue,
%a second question concerns expressiveness of the Java language.
%Our final interface to MPI is quite elegant, and provides much
%of the functionality of the standard C and Fortran bindings.  But
%creating this interface was a more difficult process than one might
%hope, both in terms of getting a good specification, and in terms of
%making the implementation work.  In section \ref{data} we noted
%that the lack of features like C++ templates (or any form of parametric
%polymorphism) and user-defined operator overloading (available in many
%modern languages)
%made it difficult to produce a completely satisfying interface to a
%data parallel library.  The Java language as currently defined imposes
%various limits to the creativity of the programmer.
%

In many respects Java is undoubtedly a better language than Fortran.
It is object-oriented to the core and highly dynamic, and there is
every reason to suppose that such features will be as valuable in
scientific computing as in any other programming discipline.  But to
displace established scientific programming languages Java will probably
have to acquire some of the facilities taken for granted in those
languages.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\subsection{HPJava}
\paragraph{HPJava}

%\begin{itemize}

%\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\subsection{mpiJava}
\paragraph{mpiJava}

\begin{itemize}

\item \texttt{mpiJava} provides a fully functional and efficient Java
interface to MPI. 

\item Our performance tests have shown that, in terms of
communications speeds, WMPI on NT out performs MPICH on Solaris.

\item When used for distributed computing the current implementation
of \texttt{mpiJava} does not impose a huge overhead on-top of the
native MPI interface.

\item As interfacing Java to MPI is not always trivial, in earlier
implementation we often saw low-level conflicts between the Java
runtime and the interrupt mechanisms used in the MPI implementations. 
These new \emph{native} thread feature in JDK 1.2 has eliminated the
interrupt problem that we encountered with earlier releases of the JDK. 
\texttt{mpiJava} is now stable on UNIX and Linux platforms using MPICH
and JDK 1.2 .  

\item Our performance tests indicate that much of the additional
latency that \texttt{mpiJava} imposes is due to the relatively poor
performance of the JVM rather than the impact of messages traversing
additional software layers.

\item The syntax of \texttt{mpiJava} is easy to understand and use,
thus making it relatively simple for programmers with either a Java or
Scientific background to take up. 

\item We believe that \texttt{mpiJava} will also provide a popular
means for teaching students the fundamentals of parallel programming
with MPI. 

\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Contributions}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The major contributions of this research is the proposing the potential
of Java as a language for scientific parallel programming, and then
providing Java interfaces to High Performance Computing software. 

\begin{itemize}

\item {We have designed and proposed a high-level structured SPMD
programming style,
\emph{HPJava}.  \emph{HPJava} is a programming language extended from
Java to support parallel programming, especially (but not exclusively)
data parallel programming on message passing and distributed memory
systems, from multi-processor systems to workstation clusters.
We propose introducing some of the characteristic ideas of
HPF---specifically its distributed array model and array intrinsic 
functions and libraries---into a basically SPMD programming model.
}

\item {We have developed an object-oriented Java interface to MPI,
\emph{mpiJava}. We have discussed the design of the \emph{mpiJava} API
and the issues associated with its development. In addition we have
presented the steps necessary to port \emph{mpiJava} onto a range of
operating systems, including Windows NT, Linux and Solaris. 
The \emph{mpiJava} package have been released 2nd version and
currently more than 400 people download from all around the world.
The releases of mpiJava include complete source, makefiles,
configuration scripts, compiled libraries for WMPI, release test codes
(based on the IBM MPI test suite), example applications, javadoc
documentation, and installation and usage notes.  
The software
is publically available from: 
\begin{verbatim}
  http://www.npac.syr.edu/projects/pcrc/mpiJava
\end{verbatim}
}


\item {We have developed the the Java object serialization model for
marshalling general communication data 
in MPI-like APIs.  This approach is compared with a Java transcription
of the standard MPI derived datatype mechanism.  We describe an
implementation of the \emph{mpiJava} interface to MPI that
incorporates automatic object serialization.  Benchmark results
confirm that current JDK implementations of serialization are not fast
enough for high performance messaging applications.  Means of solving
this problem are discussed, and benchmarks for greatly improved
schemes are presented.
}


\item {Finally, we have developed \emph{mpiJava} version of Monte Carlo spin
models using a parallel Java random number genrator. We also have
evaluated these with comparable native parallel MPI-C and MPI-Fortran
and sequencial C, F77 and Java codes for performance comparison.
In addition we have presented graphical parallel Potts model
simulation with GUI using Java AWT.
}

\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Future Work}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
HPJava...


mpiJava
We plan to continue to improve \texttt{mpiJava} and add-in the functionality
that has been proposed in MPI-2\cite{MPI2}. We intend to 'port'
\texttt{mpiJava} to a multitude of new MPI environments, including
LAM\cite{LAM} and Globus\cite{GLOBUS}.
We are also planning a \emph{pure}-Java MPI environment which does not rely
on native MPI services. 

MPJ...

