%% This section compares *T-ng with other work, both in terms of
%% architecture, and maybe performance for some of the most closely
%% related ones. 
%% 
%%   - its heritage as second incarnation of *T.
%%     * NIU much further away in *T-ng, and have lower bandwidth.  
%%     * addition of global shared memory support. 
%%   - FLASH
%%     * an earlier project then FLASH; much less aggressive shared
%%       memory support.  
%%     * We came from the message passing end and added shared memory.
%%       They came from the shared memory end and added message
%%       passing.   
%%     * *T-ng has faster path for purely local access, but suffers
%%       for local-global.  However, we may be able to recover some
%%       performance with page localization.  
%%     * compare some numbers 
%%   - DASH
%%     * Dash has no messaging support. 
%%     * Both use SMPs, but *T-ng is relying on software/firmware to
%%       run protocol.  Much less special hardware compared to Dash. 
%%     * incidentally, the hack to use higher order address bits to
%%       channel accesses to ACD is not required in DASH or FLASH. 
%%   - Alewife 
%%     * very different generation machine.  Alewife is very nice in
%%       many ways, but no longer possible to build that kind of
%%       machine with commercial microprocessors.  
%%     * a more realistic machine than Alewife: will run slightly
%%       modified OS. 
%%   - Typhoon 
%%     * got to find out more about this.  
%%   - Shrimp
%%     * got to find out more about this.  
%%   - Berkeley's NOW. 
%%     * much better performance!  
%% 
%%------------------------------------------------------------------------
\section{Related Work}
%%------------------------------------------------------------------------
\label{sec:related-wk}
%%------------------------------------------------------------------------


%% First consider parallel machines that influence the design of
%% *T-ng, or which are very similar to *T-ng in functionality.  

%% Next, let us consider other projects with the concept of Network of
%% Workstation idea.  

%% Monsoon, EM-4, J-Machine, M-Machine.
%% Alewife, Dash, Flash.
%% Wisconsin Wind Tunnel, NVM.

\start/ is heavily influenced by dataflow architectures.  Its message
passing architecture is optimized for low-latency messaging rather than
high-bandwidth messaging (although its bandwidth is very competitive.)
Though it is a more difficult objective to achieve, low-latency messaging
is essential for our compiler research.  Machines that have influenced us
in this area are the original *T project\cite{Papadopoulos93}, MIT's
Monsoon\cite{Papadopoulos91}, ETL's EM-4\cite{Sakai89}, the
J-Machine\cite{Dally92} and the M-Machine\cite{Keckler&Dally92}.

\start/'s software approach to cache-coherency is shared by other projects
as well.  The Wisconsin Wind Tunnel\cite{Reinhardt93} (WWT) uses minimal
hardware support\footnote{They hijack the ECC bits and handlers rather than
adding any additional hardware.  Unfortunately, this strategy cannot be
supported on more aggressive processor architectures which do not provide
precise ECC exceptions.} to implement shared memory.  Network Virtual
Memory\cite{Li89a,Li86} (NVM) takes advantage of virtual-memory management
hardware to maintain coherency on a page-granularity basis.

\start/ is remarkably similar in some ways to Typhoon\cite{Reinhardt94}, a
paper architecture developed at Wisconsin.  Typhoon, however, is not SMP
based and proposes a much larger degree of custom hardware for its message
passing and shared memory support than \start/ does.


Alewife\cite{Agarwal91} and FLASH\cite{Heinrich94} use varying degrees
of software in their coherency processing.  Alewife has hardware
support for maintaining coherence, but traps to software for
exceptional cases not supported in hardware.  Each Alewife site
consists of a modified SPARC 2 processor and a fully custom memory
controller, the CMMU.  Unlike \start/, Alewife cannot use standard
commercial software such as the operating system.

Cache-coherency on FLASH, like on \start/, is maintained completely in
software.  That software, however, runs on a special piece of
hardware, the Magic chip, which replaces the standard memory
controller.  The Magic chip is much more aggressive, technology-wise,
than \start/, and achieves better performance when a cache-miss
occurs, but requires much more design effort, not only in the special
hardware but in the system to use it.  FLASH's shared memory design is
conceptually cleaner since it avoids unnecessarily recrossing the L3
and thus eliminates some of the deadlock situations.

The Stanford DASH\cite{Lenoski&others92,Lenoski90} is similar to
\start/ in that it uses SMPs as building blocks for parallel machines.
It adds custom shared memory boards to provide cache-coherent shared
memory across multiple SMP sites.  Unlike \start/, all the protocol
processing is performed by hardware on the shared memory board.  All
the directory memory also resides on this board.  DASH's shared memory
implementation, unlike \start/'s, allows access to resident global
memory to proceed without going through the shared memory board,
unless coherency action has to be carried out on remote sites.
However, the protocol is fixed in hardware, and dedicated memory is
used to maintain directory information.

\start/'s approach to shared memory uses much simpler hardware than
any of the hardware supported shared memory schemes that we have
encountered, allows finer-grained coherency than NVM, and works with
much more aggressive processors than the Wisconsin Wind Tunnel.  We
believe that this system will allow us to conduct interesting research
into real problems using globally shared memory and running message
passing codes with very competitive performance.


%%------------------------------------------------------------------------
%%                               END
%%------------------------------------------------------------------------

