Computer performance

From Wikipedia, the free encyclopedia

Computer performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used.

Depending on the context, good computer performance may involve one or more of the following:


Contents

[edit] Performance metrics

Computer performance metrics include availability, response time, capacity, latency, completion time, service time, bandwidth, throughput, relative efficiency, scalability, Performance per watt, and speed up.

[edit] Aspect of software quality

Computer software performance, particularly software application response time, is an aspect of software quality that is important in human–computer interactions.

[edit] Technical and non-technical definitions

The performance of any computer system can be evaluated in measurable, technical terms, using one or more of the metrics listed above. This way the performance can be

- compared relative to other systems or the same system before/after changes
- defined in absolute terms, e.g. for fulfilling a contractual obligation

Whilst the above definition relates to a scientific, technical approach, the following definition given by Arnold Allen would be useful for a non-technical audience:

The word performance in computer performance means the same thing that performance means in other contexts, that is, it means "How well is the computer doing the work it is supposed to do?"[1]

[edit] Technical performance metrics

There are a wide variety of technical performance metrics that indirectly affect overall computer performance. Occasionally a CPU designer can find a way to make a CPU with better overall performance by improving one of these technical performance metrics without sacrificing any other (relevant) technical performance metric -- for example, building the CPU out of better, faster transistors. However, sometimes pushing one technical performance metric to an extreme leads to a CPU with worse overall performance, because other important technical performance metrics were sacrificed to get one impressive-looking number -- for example, the Megahertz myth.

The total amount of time required to execute a particular benchmark program is

 t=N*C/f

where

  • N is the number of instructions actually executed. The code density of the instruction set strongly affects N.
  • f is the clock frequency in cycles per second.
  • C is the average Cycles Per Instruction for this benchmark.

Even on one machine, a different compiler or the same compiler with different compiler optimization switches can change N and CPI -- the benchmark executes faster if the new compiler can improve N or C without making the other worse, but often there is a tradeoff between them -- is it better to use a few complicated instructions that take a long time to execute, or to use instructions that execute very quickly, although it takes more of them to finish the benchmark?

A CPU designer often is required to implement a particular instruction set, and so cannot change N. Sometimes a designer focuses on improving performance by making significant improvements in f (with techniques such as deeper pipelines, faster caches), while (hopefully) not sacrificing too much C -- leading to a speed-demons CPU design. Sometimes a designer focuses on improving performance by making significant improvements in CPI (with techniques such as out-of-order execution, superscaler CPUs, larger caches, caches with improved hit rates, improved branch prediction, speculative execution, etc), while (hopefully) not sacrificing too much clock frequency -- leading to a brainiac CPU design.

[edit] See also

[edit] References

  1. ^ Computer Performance Analysis with Mathematica by Arnold O. Allen, Academic Press, 1994. $1.1 Introduction, pg 1.
Languages