Bob Jarvis wrote:

>That's an interesting question.  I'd like to ask two related questions:
>
>	Why and how does hardware get faster?


How:

Hardware (specifically, the microprocessor) has achieved a factor of 
roughly 500x performance improvement over the past 20 years.  By far the 
largest factor in this is raw clock frequency, going from ~16MHz to  
greater than 1GHz (60x).  Most of this is directly due to process 
improvements ("process" here means the feature size and series of steps 
used in fabricating devices on the silicon wafer).

As more and more transistors were able to be packed into the same area, 
due to the same process improvements that gave us higher frequencies, 
microarchitectural improvements were able to achieve another factor of 
10x.  These improvements, such as pipelining, superscalar and speculative 
execution, exploit various levels of parallelism, and trade off increased 
die area for decreased time.  Larger caches also exploit spatial and 
temporal locality found in almost all code.

Why:

The demand for high-performance processors has been large.  Since the 
cost to process a silicon wafer is relatively fixed, shrinking the die 
size via process improvements allows many more parts to be produced for 
the same fixed cost.  And as a side-effect, the parts run faster (since 
those same process improvements give us higher frequencies).  Processor 
designers then have a new process available in which to pack more 
performance-enhancing features in the next-generation processor, and we 
jump on the treadmill again.

Another factor here is that improving performance is a fairly easy goal 
to quantify and verify.  It can be attacked by standard scientific and 
engineering techniques.

>	Can we do similar things to improve software?

Depends upon what you mean by "improve".  There's no economic incentive 
to reduce the size of software, since replication is essentially free.  
And smaller software doesn't automatically run faster, anyway.

Software users complain more about general software "bugginess" rather 
than performance.  But program correctness is a much harder goal to 
quantify and verify.




     -- tim