Lecture Topics. Principle #1: Exploit Parallelism ECE 486/586. Computer Architecture. Lecture # 5. Key Principles of Computer Architecture

Transcription

1 Lecture Topics ECE 486/586 Computer Architecture Lecture # 5 Spring 2015 Portland State University Quantitative Principles of Computer Design Fallacies and Pitfalls Instruction Set Principles Introduction Classifying Instruction Set Architectures Reference: Chapter 1: Sections 1.9, 1.11 Appendix A: Sections A.1, A.2 Key Principles of Computer Architecture Take Advantage of Parallelism Principle of Locality Focus on the Common Case Amdahl s Law Processor Performance Equation Principle #1: Exploit Parallelism System Level Multiple processors Multiple disks Multiple memory channels Pipelined buses Processor Level Pipelined instruction execution Multiple functional units Logic level Carry lookahead adders Multi-banked caches Multi-ported register files

2 Principle #2: Exploit Locality Temporal Recently accessed items likely to be accessed in the near future Code Loops and function calls Data Repeated access to the same variable, e.g., loop counter Spatial Items whose addresses are near one another tend to be referenced close together in time Code Sequential instruction execution Data Array elements, fields in a data structure Principle # 3: Focus on Common Case Implication of Amdahl s Law: Speeding up 90% of the execution by only 10% is as good as speeding up 10% of the execution by 10x Examples: The number of add/subtract instructions in a typical program is substantially higher than divide instructions Focus more on building fast adders as compared to fast dividers Most loop branches are taken Use branch prediction (fetch the branch target instead of the next sequential instruction) Fallacies and Pitfalls A falsehood often widely believed to be true Pitfall Easily made mistake Generalizations of principles that are true in a limited context The relative performance of two processors with the same ISA can be judged by clock rate or by the performance of a single benchmark suite Problems with the above argument: The processors may have the same clock rate, but may differ considerably in their pipelines and cache subsystems Same clock rate but different CPIs A processor may be tuned to one particular benchmark suite, while performing poorly on other benchmarks

3 Benchmarks remain valid indefinitely Why not? Vulnerability to Benchmark engineering Once a benchmark becomes popular, there is tremendous pressure to improve performance by bending the rules for running the benchmark Kernels which spend majority of their time on a very small section of code are particularly vulnerable Example: matrix300 kernel Peak performance tracks observed performance Problems with the above argument: Peak performance is only useful as an upper bound on the performance that a system can deliver Typical performance can vary 10x or more from peak performance Difference between typical performance and peak performance can vary greatly from program to program Multiprocessors are a silver bullet Why not? The switch to multiprocessors happened due to ILP wall and Power wall, not due to dramatically simplified parallel programming In the multi-core era, improving performance is now the burden of programmers Programmers must make their programs more and more parallel, an uphill task Synthetic benchmarks predict performance for real programs Why not? Synthetic benchmarks may not take into account effects of real world systems (loading, context switching) System may not fare as well in practice as it does on the benchmark Synthetic benchmarks may under-reward performanceenhancing optimizations Whetstone loops with few iterations System which optimizes loop branch prediction won t fare as well on the benchmark as in practice

4 MIPS (Millions of Instructions per Second) is an accurate measure for comparing performance among computers = 106= 10 6 Problems: What s an instruction? Depends upon ISA One instruction on an ISA may do as much work as ten instructions on another ISA MIPS can vary inversely with performance HW floating point instructions vs. software routines HW faster but executes fewer instructions MIPS can vary among programs on same computer Pitfall Comparing hand-coded assembly and compiler-generated, high-level language performance Potential issues: Hand-coded assembly requires specialized programmers; less likely to be used except in embedded systems Unless the compiler can perform the same optimizations that can be done by assembly language programmer, performance of the compiler-generated code will not match the hand-coded program Pitfall Falling prey to Amdahl s Law Don t forget to assess the potential usage/impact of a feature before embarking on the long journey to implement it Pitfall A single point of failure Dependability is no stronger than the weakest link in the chain Make every component redundant so that no single component failure could bring down the whole system

5 Instruction Set Principles Reading: Hennessy and Patterson, Appendix A RISC paper (Patterson & Sequin): posted on course website Instruction Set Architecture Instruction Set Architecture (ISA) Traditional meaning of computer architecture What is visible to the programmer/compiler writer Independent of organization and implementation E.g., ISA doesn t include caches and pipelines Instructions, Operands, Addressing Modes Instruction Set Architecture ISA Classification Compiler Input: high level language Output: assembly language for target ISA Global, local optimizations Register allocation Assembler Input: Assembly language Output: Machine code ( object file ) Linker Inputs: Object files, library files Outputs: Executable program Loader Reads executable from disk Passes command line arguments Optionally fixes absolute addresses

6 ISA Classification ISA Examples C = A + B A, B and C are memory locations. R1, R2 and R3 are registers Stack HP calculator Pentium FP (x87 co-processor) 8 registers organized as stack Accumulator PDP microcontroller Load/Store (Register/Register) RISC: MIPS, Alpha, ARM, PowerPC, SPARC Itanium Register/Memory IA-32 (Intel x86), Motorola 68000, IBM 360 PDP-11 VAX (really Memory/Memory)