%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusion}
% ----------------------------------------------------------------------------
\label{sec:conclusion}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%This paper describes a new, relatively easy to build parallel machine.
%Though it is not an ultimate design, it is practical and could be built
%in a short amount of time. 

In this paper we have examined the problems of supporting fine-grain
parallelism on a machine built out of stock processors.  We have
discussed the lessons we learned from the Monsoon project.  Monsoon
was a fully custom, pure dataflow machine.  Though it was very
successful running fine-grain parallel code, for pragmatic reasons we
were forced to move to machines built from stock processors.  We also
briefly presented the *T model which was motivated by the desire to
create a better building block for parallel machines.  We then
discussed our first implementation of a *T node which was based on a
Motorola 88110 RISC processor.  This project was abandoned in favor of
a move towards the PowerPC architecture family.  We took the
opportunity to incorporate global caching into the *T model.  The
resulting model is called {\archname} for *T, the Next Generation.

%% ----------------------------------------------------------------------------
%\subsection{Related Work}
%% ----------------------------------------------------------------------------

There are many machines that have much in common with {\archname}.
Japan's Electrotechnical Laboratory's (ETL) EM-4\cite{sakai89} and its
descendant architectures are custom machines designed to execute
multithreaded code.  In fact, those architectures are far more
aggressive since their network interfaces are embedded into the
processing pipeline itself.  A message can be sent in a single
instruction.  Synchronization is built into the processor as well.
{\archname}'s hardware support for messaging is far less aggressive,
since we use stock processors, but it will use state-of-the-art
processing elements and will support global caching.

The machines that are most similar to {\archname} are MIT's
Alewife\cite{Alewife-overall} and Stanford's FLASH\cite{flash93}.
Both machines support global cached memory as well as message passing,
and both are based on stock processors.  Alewife's processor, is
modified to some degree for better support of cache coherency.  It has
greater support for user-level interrupts, including a division of the
Sparc register set into four parts instead of using Sparc register
windows, and has a few extra signalling pins.  FLASH uses one stock
processor and one very heavily modified processor (called MAGIC) to
build a processing node.  It is important to note that our
implementation is far less aggressive than FLASH and, in many ways,
Alewife.  We plan to use completely stock processors running on a
stock memory bus which will hopefully reduce development time
relative to Alewife and FLASH. It will be interesting to see how close
to FLASH and Alewife in performance {\archname} can get.

It is exciting to see that parallel architectures are converging.  The
machines mentioned in the previous paragraph differ only in detail
from {\archname}.  They all attempt to integrate shared memory with
message passing, and are therefore significantly different from pure
message passing machines, such as the J-machine\cite{dally}, dataflow
machines like Monsoon, and pure shared memory machines such as
\DASH.  Eventual success of these attempts will depend very much on
the quality of the hardware implementations, and the system software
that is provided for using these machines. 

%% ----------------------------------------------------------------------------
%\subsection{Future Work}
%% ----------------------------------------------------------------------------
%
%Since we are just beginning, there is a lot of work to do on {\archname}.  The
%hardware design has to be completed.  There is substantial amounts of
%compiler work to be done.  Choosing whether to use global caching or
%split-phase transactions will probably be difficult, but will most
%likely yield enormous benefits.  We have to study the effect of global
%caching on the way we partition our code as well.  We plan on
%compiling very aggressively for this machine.
%
%There are many features that we desire, such as a tightly coupled
%network interface and support for fast context switching, that we are
%not able to put into {\archname}.  We hope to study the amount of performance
%degradation due to the lack of those features.  Perhaps they are not
%absolutely necessary for good performance.  It is important to
%understand, however, what architectural features help and by how much.
%
%{\archname}'s design is necessarily undetailed and vague at this stage
%since we have not yet completed the design phase.  Details will become
%much clearer in the next few months.  We look forward to presenting a
%more concrete design in the near future.
