2. Basic Terminology. 1. Chapter 1 Concepts. 1. Terminology 2. Trends 3. Measures of Computer Performance 4. Principles of Computer Design

Transcription

1 2. Basic Terminology. Chapter Concepts. Terminology 2. Trends 3. Measures of Computer Performance 4. Principles of Computer Design ILP: inst lvl parallelism CPI: clocks per inst IPC: inst per clock FPU: floating point unit ALU: arithmetic logic unit PE : processing element (eg, FPU, ALU, etc ISA: instruction set architecture CISC: complex instruction set computer RISC: reduced instruction set computer VLIW: very long instruction word CMP: Chip multiprocessor multi-issue: ability to perform more than one inst at once pipelining: breaking single inst up into sub-processes 3. Microprocessor Performance Growth (ispec 4. Classes of Computers Computer Architecture, Henn & Patt, Fig., pg 3 Software trends reducing arch inertia: Standard operating systems (unix, dos, windows Less use of assembly Perf relative to VAX /780 Diff between 25% and 50% due to arch & org ideas: caches Increased ILP (pipelining, multiple inst issue FP speedups even greater. In 2002 hit wall: 20% Power dissipation little ILP left memory latency Old classes based loosely on size: Microcomputer: Computer in which entire CPU is on one chip microprocs now used in all types of computers Minicomputer Mainframes Supercomputer New classes based on usage:. Desktop: iface directly wt user, includes PCs and workstations Emphasize both price and performance 2. Servers: provides computation or data to other devices Emphasize availability, scalability, and throughput 3. Embedded systems: computer lodged in other devices Variable, but tend to emphasize price, minimizing memory and power usage, and often require predictability

2 5. Three aspects to architecture 6. Goals for Computer Architect. Instruction Set Architecture: programmer-visable machine instructions. Really binary numbers, but can think of it as assembly code Architecture used to imply only ISA design, but modern ISAs fairly uniform, except in embedded 2. Organization: high-level aspects of machine memory system (including caches, bus structure, CPU, etc. 3. Hardware: low-level aspects of machine detailed logic design and packaging technology We will emphasize application of 2. Functional requirements/usage Application area: main jobs (desktop, scientific, database, embedded software compatibility: ISA compat needed or not OS requirements: address space, memory management, etc standards: IEEE fp, I/O devices, networking, etc. find correct balance of: 2. Price lowered through less customization and greater volume 3. Performance 4. Power constraints Increasingly important, even in desktop/servers 5. Time-to-market New features must be worth additional devel time 7. Trends 8. Results of Trends hardware increase per year: Transisters on a chip: 55% Program memory usage:.5-2 per year. DRAM density: 40-60% disk density: more than 00% software trends: Languages become higher level assembly, F77/C, C++, java/python Backend optimization controlled at higher levels user+assmblr, compiler, VM design trends: 980: CISC gives way to RISC 995: PentiumPRO: Revenge of the CISC Frontend translates CISC inst to RISC microcode semiannually: newest gen of VLIW fails in marketplace 2004: PowerPC790FX: VLIW, kinda Frontend translates pseudo- RISC to pseudo-vliw inst 2005: Dual-core on one chip (AMD/Intel/IBM now : heat wall refocuses arch from clock rate to CMP Use for transisters Put entire CPU on one chip Put fancy front-end on chip Can design backend independantly, make ISA almost irrelevant put caches on chip too Perform compiler-like transforms in hardware inst reordering (dep analysis, reg renaming, OOE, speculative execution, etc. Put multiple cores on chip Mem controllers, GPU, more cache, etc., on chip. Some observations Software slow to adapt, hardware quick VLIW exposed at assembly level requires software to adapt with hardware Clock speed is hitting power/heat walls, but so far transister counts are not Expect hardware support to continue to expand (VLIW/SS, multicore, VM Expect ISA to less and less describe machine Experts predict a reversal of these trends, I m dubious

3 0. Approximate cost breakdown for $000 PC in 200 Terms Wafer: a slice of silicon crystal ingot (chopped into dies Die/Chip: a portion of the wafer that is an independent component Yield: the % of manufactured devices that work 9. Computer Manufacturing Improve yield/decrease price learning curve: experience with particular manufacturing process volume: speeds curve, amortizes R&D costs, lowers margins commoditization: allow for competition, rewarding best-ofbreed processes, and minimal margins Computer Architecture 3rd ed, Henn & Patt, Fig.9, pg 2 Est % costs of $K PC Subsystem has little room for improvement Mem, video, disks expand, costs dec slower Processor & monitor biggest hardware costs Software costs almost greatest, despite lowest manufacturing costs MS resists loss of monopoly commodization lower margins software costs are really in maintainence and support, not manufacturing. Performance Terms 2. Relative performance Indiv process metrics Wall-clock time: actual time between start and finish of task AKA: walltime, elapsed time AKA(BI: response time CPU time: time CPU spends processing task Doesn t include IO, other processes, etc Further split into:. user CPU: CPU time in user-space of process 2. system CPU: time spent by OS perf tasks requested by process Server metric throughput: total amount of work done in given time (multiple tasks Questions CPU or wall have greater resolution? CPU or wall have greater nonres variability? Why are timings not repeatable? Which metrics make sense for what tasks? Finding speedup value (n: perf x perf y = n = time y time x y takes 30 sec to run a routine, while x takes 0, x is three times faster Time only absolute measure For performance metric to be useful, must standardize conversion performance metrics MIPS - depends on too many factors (compiler, ISA, implementation, etc. MFLOPS - most useful when you standardize FLOP count, regardless of algorithm Usefulness of performance Performance is a measure of speed Speed less affected by size You know the top possible speed for each arch Bigger being better is intuitive

4 type, best to worst. User applications: most important apps used by end-user 2. Kernels: key kernels extracted from popular applications (linpack, livermore loops, gemm, etc 3. toy benchmark: small prog that produce known result (puzzle, sieve, quicksort, arraymerge, etc 4. synthetic benchmarks: attempts to match freq of ops and operands from real progs (drhystone, whetstone 3. Benchmarking gotchas Compilers/archs may tune for benchmark, wtout generality Benchmark may not use kernel in same way as application Hard to capture all important info (compilers/caches/os/settings Worsens problems of reproducibility Hard to tell what is causing scores Benchmarks will vary on relative score for same machine 4. Amdahl s Law States that the perf improv from using some faster mode of exec is limited by the fraction of time the faster mode can be used Allows user to understand limits of a considered optimization May be applied to any method of speedup: hardware improvement, software optimization, parallelization, etc. Urges us to optimize common case More rigorous form of 90/0 rule Can get rough idea by asking what if this execution were free T n : new time, T o : original time, F e : frac of T o exploiting enhanc, : speedup from enhanc, S t : speedup of total program after enhanc T n = (opt time + (non-opt time = ( T o F e + (T o (T o F e = T o ( F e +( ( F e = T o ( F e + F e T n = T o ( F e + F e S t = T o T n = S t = /( F e + F e T o T o ( F e + Fe Se = /( F e + F e Clock Rates (clock ticks in a second hertz (Hz: one cycle per sec KHz: one thousand cyc/sec (0 3 MHz: one million cyc/sec (0 6 GHz: one billion cyc/sec (0 9 Thz: on trillion cyc/sec ( Measuring clock speed Clock Periods (tick interval millisecond (ms: 000 = 0 3 microsecond (µs: = 0 6 nanosecond (ns: (billionth 0 9 = 0 9 picosecond (ps: (trillionth 02 = 0 2 rate: cycles/sec, period = sec/cycle they are inverses!. What is the period of a 500 Mhz chip? 2. What is the clock rate of a chip with a 50 picosecond cycle time? 6. CPUtime, CPI, etc CPUtime = CPUCycles * ClockPeriod (duh CPUtime = InstCount * CPI * Period CPI = CPUCycles IC, IC : Instruction Count InstCount: ISA & compiler ClockPeriod: hardware tech and org CPI: compiler (inst selection, org, ISA CPI varies by instruction, machine state, and inst mix* Given program wt IC t insts of n types each with CPI i and IC i, CPI t = n i= (% of inst of type i CPI i = ( n ICi i= IC CPI t i CPI i = issuerate +(stallcycles This formulation more useful once we learn pipelining, which allows us to compute stall cycles IPC = CPI = instructions executed per clock cycle For CPI, lower is better (time For IPC, higher is better (performance

5 7. CPI Questions. Assume loads take 4 cycles, all other operations complete in cycle, that our application has 40,000 instructions, 800 of which are loads. What is the CPI of this application? 2. Assume FP ops 25% of inst, average CPI of FP ops is 4.0, average CPI of non-fp inst is 3 4, frequency of FPSQR is 2%, and a FPSQR takes 20 cycles. (a What is the CPI of this app on the original machine? (b If new hardware reducec FPSQR to only 2 cycles, what will CPI for this app on the new hardware be? (c For same hardware budget, can instead reduce avg CPI of all fp inst to 2.5. What is the CPI of app now? (d What is the speedup of the best design over original? 3. Assume single issue machine, all loads hit the cache, and that loading a value from the cache stalls execution for 5 cycles. What s the CPI of load inst on this machine? 8. Measurement Techniques Amdahl s Law tells us to make common case fast: need a way to find common case! Therefore, common to run typical applications with:. Hardware perf counters: most machines keep track of number of inst, general type, total cycles, etc. pros: represents machine used in real world, very fast cons: may be imprecise & unrepeatable, hard to avoid contamination, only limited # of counters 2. Instrumented execution: extra code inserted into exec to monitor events, which can then be processed later pro/con same as above, but more flexible at cost of running slower and possibly having instrumentation interfere with run 3. ISA interpretation: Write an interpreter that simulates the architecture in question (to greater or lesser accuracy pros: repeatable, cycle accurate, does not require hardware cons: very slow ( 000 times slower, hard to take all factors into account, and without hardware, unverifiable. 9. Locality of Reference Steeper architectural improvement rate enabled by exploiting properties possessed by most applications. One of the most important of these is locality of reference: programs tend to reuse data and instructions they have recently accessed. Two important types of locality:. Temporal Locality: recently accessed items are likely to be accessed in the near future inst: loops, small functions, etc data: stack, global scalar 2. Spatial Locality: items stored in close proximity tend to be referenced close together during execution inst: only long jumps mess this up data: sequential array access Exploit these localities through caches (smaller, faster memories that store recently used and proximal addresses 20. Exploiting Parallelism digital design: parallel completely from hardware Checking for address in all levels of cache sim Checking multiple tags sim in set-assoc cache carry lookahead for addition within a processor: (exploiting ILP, hardware & compiler pipelining issuing multiple instructions simultaneously (super scalar system level: (improves throughput, assigned by OS perform tasks on different processors accessing different disks simultaneously

6 2. Fallacies and Pitfalls fallacy: incorrect common belief Rel perf of archs wt same ISA judged by clock rate or single benchmark Actual perf tracks peak MIPS is a good way to compare computers Widely used benchmarks are always meaningful pittfall: an easily made mistake Extrapolating compilation performance from hand-tuned kernels Assuming software cheap & quick Not applying Amdahl s Law