%$Id: lessons-conclusion.tex,v 1.5 1997/07/30 20:00:29 cierniak Exp $
\section{CONCLUSIONS}
\label{sec:concl}

In this paper we have described a Java based browser that will be
valuable for a performance oriented programmer. We are not aware of
any software that provide such extensive compiler optimization
information as well as combines runtime performance information with
compiler optimization information in a visually appealing way either
in academia or industry.

We learned several things from designing and implementing jCITE.
\begin{itemize}
\item Combining compiler information with runtime performance
  information can lead to new insights into how application
  performance matches the hardware.
\item Novel visual displays are much more attractive in presenting
  performance data than static text data.  Correlating data to provide
  information is even more useful.
\item Java specific lessons:
  \begin{itemize}
  \item Java based technology promises portability, better client
    software on Unix machines, and much more of a chance for ISV's to
    participate in providing tools for high end programming like
    scientific and engineering programming.
  \item GUI portability has a price: performance. The state of art of
    Java compilers and components are not yet sufficient to develop
    large scale portable GUI software.
  \item Using multi threading safe data structures such as
    Vectors~\cite{Gosling96Java} is expensive today on most platforms
    even when the application is single-threaded. jCITE uses Vectors
    in a number of places.
  \item The I/O performance of Java VM's used by us has been
    insufficient for programs such as jCITE that read many files.
  \item The lack of features in AWT (JDK 1.0.2) such as pop-up menus
    or cut-and-paste was disheartening. Several of these deficiencies
    have been fixed in JDK 1.1~\cite{SunMicrosystems96Java}. Sun has
    also provided a road map for lightweight and fast UI components.
  \end{itemize}
\item It is better to design a lightweight browser from the ground up
  for performance programming than integrate functionality into a
  fully functional editor. jCITE's precursor, CITE, was written
  entirely in Emacs Lisp and worked within Lucid's XEmacs. CITE was
  heavyweight due to its dependence on XEmacs.
\end{itemize}

\subsection{Related work}
Sigma~\cite{Sigmacs} was a project at Indiana University. It had an
Emacs based front-end which allowed interactive transformations to be
applied to a program. It had a library to examine and manipulate
Intermediate Representation of the program. It was intended more as a
restructuring tool than for performance programming.

The Parascope programming environment, the D editor~\cite{Deditor} and
the subsequent work at Rice on compilation and performance evaluation
environment is similar in spirit to ours. They focus more on data
parallel programs in a message passing environment. We plan to
incorporate results from data distributions for parallel programs
running on Scalable Shared Memory machines that are being developed in
our compiler into our programming tool.

SGI's Workshop MPF tool~\cite{MPF} provides information on KAI
parallelizer optimizations. It works only on SGI computers.
KAI~\cite{KAI} announced a new suite of tools written in Java to
provide portability.  They are also working towards providing
portability of the parallel directives across a number of platforms so
that ISV's can migrate their parallel code easily across platforms.

\subsection*{Acknowlegements}

We would like to acknowledge the members of the ``Developer Magic Group''
working on Compilers and Tools at Silicon Graphics Inc.\ for all their
help.  Special thanks to Ron Price and Dror Maydan for their encouragement.
The first author was funded through a summer internship when much of this
work was completed.
