Computer Performance Metrics Measurement Evaluation 1 Defining Computer

Computer Performance: Metrics, Measurement, & Evaluation 1

Defining Computer Performance 2

What is Performance? Ø As a computer user, YOU define the performance! Ø Different users have different definitions of performance Ø You are already familiar with some performance metrics Clock Frequency: My computer runs at 500 MHz, yours only at 300 MHz, so my computer is better than yours! Ø Millions of Instructions Per Second (MIPS): In a second, my computer can execute 8 million instructions, while yours only 5 million instructions, so my computer is better than yours 3

Defining Performance: Airplane Example 4

Which Airplane performs better? "X is n times faster than Y" means Ex. Time(Y) -------Ex. Time(X) = Performance(X) -----------Performance(Y) = n Ø Time of Concorde vs. Boeing 747? Ø Throughput of Boeing 747 vs. Concorde? 5

Why measure performance? 1. Make intelligent choices 2. See through the marketing hype 3. Key to understanding underlying organizational motivation 4. We are interested in answering questions like: Why is some hardware better than others for different programs? What factors of system performance are hardware related? (e. g. , Do we need a new machine, or a new OS? ) How does the machine's instruction set affect performance? 6

Performance Metrics 7

Computer Performance Ø Response Time (latency) ü How long does it take for my job to run? ü How long does it take to execute a job? ü How long must I wait for the database query? Ø Throughput ü How many jobs can the machine run at once? ü What is the average execution rate? ü How much work is getting done? Ø If we upgrade a machine with a new processor what do we increase? Ø If we add a new machine to the lab what do we increase? 8

Program Execution Time Total Execution time of your application is the TRUE measure of performance. Why? Because that is what you are really interested in! Ø Elapsed Time ü counts everything (disk and memory accesses, I/O , etc. ) ü a useful number, but often not good for comparison purposes Ø CPU time ü doesn't count I/O or time spent running other programs ü can be broken up into system time, and user time Ø Our focus: user CPU time ü time spent executing the lines of code that are "in" our program 9

Now lets define performance… Ø For some program running on machine X, Performance. X = 1 / Execution time. X Ø "X is n times faster than Y" Performance. X / Performance. Y = n Problem: ü machine A runs a program in 20 seconds ü machine B runs the same program in 25 seconds Ø Which machine is better? Ø What are their performance values? 10

Clock Cycles Ø Instead of reporting execution time in seconds, we often use cycles Ø Clock “ticks” indicate when to start activities (one abstraction): cycle time = time between ticks = seconds per cycle time Ø clock rate (frequency) = cycles per second (1 Hz. = 1 cycle/sec) A 200 MHz. clock has a cycle time 11

How to Improve Performance So, to improve performance (everything else being equal) you can either ____ the # of required cycles for a program, or ____ the clock cycle time or, said another way, ____ the clock rate. 12

How many cycles are required for a program? . . . 6 th 5 th 4 th 3 rd instruction 2 nd instruction 1 st instruction Ø Could assume that # of cycles = # of instructions time Ø This assumption is incorrect. Different instructions take different amounts of time on different machines. Why? hint: remember that these are machine instructions, not lines of C code 13

Different numbers of cycles for different instructions time Ø Multiplication takes more time than addition Ø Floating point operations take longer than integer ones Ø Accessing memory takes more time than accessing registers Important point: changing the cycle time often changes the number of cycles required for various instructions (more later) 14

An Example • Our favorite program runs in 10 seconds on computer A, which has a 400 MHz. clock. We are trying to help a computer designer build a new machine B, that will run this program in 6 seconds. The designer can use new (or perhaps more expensive) technology to substantially increase the clock rate, but has informed us that this increase will affect the rest of the CPU design, causing machine B to require 1. 2 times as many clock cycles as machine A for the same program. What clock rate should we tell the designer to target? “ 15

Now that we understand cycles… Ø A given program will require ü some number of instructions (machine instructions) ü some number of cycles ü some number of seconds Ø We have a vocabulary that relates these quantities: cycle time (seconds per cycle) ü clock rate (cycles per second) ü CPI (avg. cycles per instruction) a floating point intensive application might have a higher CPI ü MIPS (millions of instructions per second) this would be higher for a program using simple instructions 16

Performance Ø Performance is determined by execution time Ø Do any of the other variables equal performance? ü # of cycles to execute program? ü # of instructions in program? ü # of cycles per second? ü average # of cycles per instruction? ü average # of instructions per second? Ø Common pitfall: thinking one of the variables is indicative of performance when it really isn’t 17

CPI Example Ø Suppose we have two implementations of the same instruction set architecture (ISA). For some program, Ø Machine A has a clock cycle time of 10 ns. and a CPI of 2. 0 Ø Machine B has a clock cycle time of 20 ns. and a CPI of 1. 2 Ø Which machine is faster for this program, and by how much? 18

# of Instructions Example Ø A compiler designer is trying to decide between two code sequences for a particular machine. Based on the hardware implementation, there are three different classes of instructions: Class A, Class B, and Class C, and they require one, two, and three cycles(respectively) The first code sequence has 5 instructions: 2 of A, 1 of B, and 2 of C The second sequence has 6 instructions: 4 of A, 1 of B, and 1 of C Ø Which sequence will be faster? How much? Ø What is the CPI for each sequence? 19

Performance Evaluation Benchmarking 20

Why Do Benchmarks? Ø How we evaluate differences ü Different systems ü Changes to a single system Ø Provide a target ü Benchmarks should represent large class of important programs ü Improving benchmark performance should help many programs Ø For better or worse, benchmarks shape a field Ø Good ones accelerate progress ü good target for development Ø Bad benchmarks hurt progress ü help real programs Vs. sell machines/papers? ü Inventions that help real programs don’t help benchmark 21

Programs to Evaluate Processor Performance Ø(Toy) Benchmarks ü 10 -100 line üe. g. , : sieve, puzzle, quick sort ØSynthetic Benchmarks üattempt to match average frequencies of real workloads üe. g. , Whetstone, dhrystone ØKernels üTime critical excerpts Real programs üe. g. , gcc, spice 22

Benchmarks Ø Performance best determined by running a real app. ü Use programs typical of expected workload ü Or, typical of expected class of applications e. g. , compilers/editors, scientific applications, graphics, etc. Ø Small benchmarks ü nice for architects and designers ü easy to standardize ü can be abused Ø SPEC (System Performance Evaluation Cooperative) ü companies have agreed on a set of real program and inputs ü valuable indicator of performance (and compiler technology) 23

SPEC ‘ 89 Ø Compiler “enhancements” and performance 24

SPEC ’ 95 CPU Benchmarks 25

• Does doubling the clock rate double the performance? 26

Limits on Performance Amdahl’s Law 27

Amdahl's Law Execution Time After Improvement = Execution Time Unaffected + ( Execution Time Affected / Amount of Improvement ) Example: Ø "Suppose a program runs in 100 seconds on a machine, with multiply responsible for 80 seconds of this time. How much do we have to improve the speed of multiplication if we want the program to run 4 times faster? " How about making it 5 times faster? Principle: Make the common case fast 28

Performance Evaluation Summary CPU time = Seconds Program = Instructions x Cycles Program Instruction x Seconds Cycle Ø Time is the measure of computer performance! Ø Good products created when we have: üGood benchmarks üGood ways to summarize performance Ø Remember Amdahl’s Law: Speedup is limited by unimproved part of program 29

Performance Fallacies & Pitfalls 30

Fallacies & Pitfalls Ø Expecting the improvement of one aspect of a machine to increase performance by an amount proportional to the size of improvement. . Look at Amdahl’s Law Ø Hardware-independent metrics predict performance Ø Using MIPS as a performance metric 31

MIPS example Ø Two different compilers are being tested for a 100 MHz. machine with three different classes of instructions: Class A, Class B, and Class C, which require one, two, and three cycles (respectively). Both compilers are used to produce code for a large piece of software. The first compiler's code uses 5 million Class A instructions, 1 million Class B instructions, and 1 million Class C instructions. The second compiler's code uses 10 million Class A instructions, 1 million Class B instructions, and 1 million Class C instructions. Ø Which sequence will be faster according to MIPS? Ø Which sequence will be faster according to execution time? 32

Fallacies & Pitfalls. . Contd. , Ø Synthetic benchmarks predict performance Ø Using arithmetic mean of normalized execution times to predict performance Ø The geometric mean of execution time ratios is proportional to total execution time 33

Variants of MIPS: MOPS and Other FLOPS! Ø MIPS = Million Instructions Per Second Ø Peak MIPS is obtained by choosing an instruction mix that minimizes CPI, even if the mix is impractical!! Ø Computer manufacturers announce produces using peak MIPS as a metric, often neglecting the word “peak” Ø MOPS = Million Operations Per Second 34