%* Last edited: May 31 19:05 1996 (misha)
%\subsection{MIMD Flexibility Hurts Performance}

The MIMD model incurs enormous overhead for every functional unit that
actually manipulates data. This overhead consists of silicon area required
to store the program (a 10K word program of 32 bits each corresponds to 1.8
million transistors!), instruction decoding, addressing, and control
circuitry. The overhead can easily be a factor of ten larger than
the functional unit actually processing the data.

A more subtle disadvantage is the loss of integration due to pin
limitations.  Today's chip carriers can support very few 32-bit wide
instruction ports.  Reduced integration leads to pressure on improving the
performance on a single chip. Regardless of diminishing returns, valuable
silicon resources are allocated to squeezing the last available performance
from a single instruction stream.  Thus, only a small fraction of the
circuitry on a chip is devoted to actually manipulating the data. The rest
is allocated to branch prediction, instruction caching, instruction
scheduling and reordering, etc.  Other baggage inherited from the
workstation background of RISC chips is support for operating systems, such
as interrupts and fast context switches.


Many important applications are characterized by irregular data and
instruction flow, complex interactions between data sets, and highly
conditional execution.  For this wide variety of important computing tasks,
high performance uniprocessors and MIMD parallel machines have emerged as
the best architectural choices.  

 A general purpose MIMD machine capable of performing the
required massive data manipulations would be prohibitively costly.
Especially in constrained environments where power and size requirements
dictate efficient solutions, the uniprocessor/MIMD approaches are a poor
application of resources.




On a philosophical note, the microprocessor approach locks architecture and
programmers into a rigid way of thinking, as the cycle count does not
reflect the true silicon cost of operations. When logical shift and
multiplication take nearly the same amount of time, programmers (and
compilers) start to use multiplication more. Algorithms get slanted towards
using multiplications, and what's worse, profiling programs for instruction
frequency shows that multiplications are used frequently and should be
accelerated by allocating more area.



%%% Local Variables: 
%%% TeX-master: "main"
%%% comment-start: "%%% "  
%%% End: ***