Fundamentals of Computer Design. Rapid Pace of Development IBM 7094 released in 1965 – Featured interrupts – Could add floating point numbers at 350,000.

Similar presentations

Presentation on theme: "Fundamentals of Computer Design. Rapid Pace of Development IBM 7094 released in 1965 – Featured interrupts – Could add floating point numbers at 350,000."— Presentation transcript:

1
Fundamentals of Computer Design

2
Rapid Pace of Development IBM 7094 released in 1965 – Featured interrupts – Could add floating point numbers at 350,000 instructions per second – Standard 32K of core memory in 36 bit words – Occupied an entire air conditioned room – System cost of about $3.5 million

3
This laptop Fujitsu Lifebook T4220 purchased in 2008 – 16 GFLOPS (we’ll see later this is not a particularly good benchmark) – Standard 2GB of core memory in 64 bit words – Occupies 12” by 9” by 1.5” space – System cost of about $2,000

4
Transistors per inch square – Twice as many after ~1.5-2 years Related trends – Processor performance Twice as fast after ~18 months – Memory capacity Twice as much in <2 years Not a true law but an observation – We’re getting close to hitting the physical limits Moore’s Law

8
RISC vs. CISC Big debate in the 80’s Ideas from RISC won – Although you don’t think of it as RISC, today’s Intel Architecture adopted many RISC ideas internally

9
Terms for a Computer Designer Instruction Set Architecture – The assembly instructions visible to a programmer Organization – Mostly transparent to the programmer, but high-level design aspects such as how much cache, replacement policies, cache mapping algorithm, bus structure, internal CPU design. Computer Architecture – We’ll refer to this as instruction set design, organization of the hardware design, and the actual hardware itself.

14
Technology Trends In 1943, Thomas Watson predicted “I think there is a world market for maybe five computers." – (The IBM PC was an “undercover” project and saved the company) In the 70’s and 80’s IBM pursued the high- speed Josephson Junction, spending $2 billion, before scrapping it and using CMOS like everyone else.

16
Implementation Trends IC density is increasing at close to 35% per year, while the die size is also increasing at close to 15% per year. This results in transistor count increasing at 40-55% per year. Factors into a lower future cost for developing the same chip! Semiconductor DRAM density increasing around 40% per year, bandwidth and latency also improving. Disk technology increasing at an astounding rate, about % per year

23
Cost per die The book has some examples of computing the die yield for various wafer and die sizes. For a designer, the wafer yield, cost, and defects are all determined by the manufacturing process. The designer has control over the die area. – If alpha is typically 4, then this means that the die_yield is proportional to (Die_Area) -4. Plugging this in to the equation for die cost gives us: Size matters!

24
Optimization Problem Optimize price/performance ratio Conflicting goals due to interactions between components – If adding a new feature, die size goes up, number of defects goes up and fewer dies per wafer, may need more testing, power usage may increase requiring larger battery or heat sink, etc…

25
Measuring Performance What does it mean to say one computer is faster than another? – Historically, advertisers and consumers have used clock speed. 2Ghz vs. 1Ghz means the first is twice as fast as the second? – Pentium 4E in 2004 Whopping 3.6 Ghz! 31 stage integer pipeline! – Core i5 750 in 2010 Only 2.66 Ghz

26
Execution Time – A Better Metric Compare two machines, X and Y, on the same task: Another metric sometimes used is performance, which is just the reciprocal of execution time:

27
Measuring Execution Time More difficult than it seems to measure execution time – Wall-clock time, response time, or elapsed time - Total time to complete a task. Note the system might be waiting on I/O, performing multiple tasks, OS activities, etc. – CPU time – Only the time spent computing in the CPU, not waiting for I/O. This includes time spent in the OS and time spent in user processes. – System CPU Time – Portion of CPU time spent performing OS related tasks. – User CPU Time – Portion of CPU time spent performing user related tasks.

28
What programs should we run? Real Programs – Run the programs users will use. Examples are compilers, office tools, etc. – Unfortunately there is a porting problem among different architectures, so it might not be a fair comparison if the same software is coded differently. Kernels – These are small, intensive, key pieces from real programs that are run repeatedly to evaluate performance. – Examples include Livermore Loops and Linpack. Here is a code fragment from Livermore Loops: for (l=1; l<=loop; l++) { for (k=0; k

29
Benchmarks Toy benchmarks - this includes small problems like quicksort, sieve of eratosthenes, etc. – They are best saved for CS201 programming assignments! Synthetic benchmarks - These are similar to kernels, but try to match the average frequency of operations and operands of a large set or programs. – Examples: Whetstone and Dhrystone – The problem is no user really runs these either. Programs typically reside entirely in cache and don’t test the entire system performance!

30
Benchmarks Benchmark Suites - These are a collection of benchmarks together in an attempt to measure the performance of processors with a variety of applications. – Suffers from problems of OS support, compiler quality, system components, etc. – Suites such as CrystalMark or the SPEC (www.spec.org) benchmark seem to be required for the industry today, even if the results may be somewhat meaningless.www.spec.org –

34
Benchmark Trick Example Certain flags during compilation can have a huge effect on final execution time for some tests – The Whetstone loop contains the following expression: SQRT(EXP(X)) – A brief analysis yields: It would be surprising to see such an optimization automatically performed by a compiler due to the expected rarity of encountering SQRT(EXP(X)). Nevertheless, several compilers did perform this optimization!

35
Comparing Performance The table lists the time in seconds that each computer requires to run a particular program. Computer AComputer BComputer C Program P Program P Total Time Which computer is better? For P1, A is 10 times faster than B, but for P2 B is 10 times faster than A.

36
Total Execution Time A consistent summary measure Simplest approach: compare relative performance in total execution time So then B is 9.1 times faster than A (1001/110), while C is 2.75 times faster than B. Of course this is all relative to the programs that are selected.

37
Other Total Execution Time Metrics Arithmetic mean Weighted arithmetic mean Normalize the execution time with respect to some reference machine. – Geometric mean

38
Geometric Mean For the previous example referenced to A: For A For B For C This says that the execution time of these programs on C is 0.63 of A and B.

39
Quantitative Principles of Computer Design Take Advantage of Parallelism – Instruction level, application level, system level Principle of Locality – Temporal and spatial Focus on the Common Case – In design, favor the frequent case over the infrequent case E.g. if adding two numbers rarely results in overflow, can improve performance by optimizing the more common case of no overflow – Will be slower when overflow occurs, but rare so overall performance will be improved

40
Amdahl’s Law The performance improvement to be gained from using some faster mode of execution is limited by the fraction of time the faster mode can be used. Speedup = (Performance for entire task using enhancement) / (Performance for entire task without enhancement) Another variant is based on the ratio of Execution times, where Execution time = 1/speedup.

41
Speedup Fraction(enhanced) is just the fraction of time the enhancement can be used. For example, if a new enhancement is 20 times faster but can only be used 5% of the time:

42
Example Consider a critical benchmark. Floating Point Square Root is responsible for 20% of the execution time. You could increase this operation by a factor of 10 via hardware. Or at the same cost, you could make all FP instructions run 2 times faster, which accounts for 50% of the execution time. Which is better?

43
CPU Performance All commercial computers are synchronous – they have a clock that “ticks” once per cycle. – Usually the cycle time is a constant, but it may vary (e.g. SpeedStep). – Duration is usually on the order of nanoseconds, or more commonly the rate is expressed instead, e.g. 100 Mhz. CPU time for a program can then be expressed two ways: – CPU Time = CPU clock cycles for a program * Clock cycle time or – CPU Time = CPU clock cycles for a program / Clock Rate

44
Cycles Per Instruction We can count the number of instructions executed – the instruction path length or Instruction Count (IC). Given IC and the number of clock cycles we can calculate the average number of clock cycles per instruction, or CPI: – CPI (Ave # clock cycles per instr) = CPU clock cycles for a program / IC With a little algebraic manipulation we can use CPI to compute CPU Time: – CPU clock cycles for a program = CPI * IC Substitute this in for CPU Time.. – CPU Time = CPI * IC * Clock Cycle Time Or – CPU Time = CPI * IC / ClockRate

45
CPI Unfortunately, CPI, IC, and the Clock Cycle Time are all subtly inter-related. – CPI and cycle time depend on the instruction set – The instruction set depends on the hardware – The hardware impacts the cycle time, etc. Sometimes CPI is more useful to deal with in terms of all individual instructions. We can denote this by: – CPU Time = and CPI Total=

46
CPI Example CPI is useful because it is measurable, unlike the nebulous “fraction of execution” in Amdahl’s equation. Consider the previous example to compute the speedup of Floating Point Square Root: Suppose you run your program and as it runs collect the following data: – 100 total instructions – 25 of these instructions are floating point instructions – 2 of these instructions are floating point square root – 100 clock cycles were spent on floating point instructions 40 of these 100 cycles were spent on floating point square root 100 clock cycles were spent on non-floating point instructions

48
Measuring Components of CPU Performance Cycle Time is easy to measure for an existing CPU (whatever frequency it is running at). Cycle Time is hard to measure for a CPU in design! The logic design, VLSI process, simulations, and timing analysis need to be done. IC – This is one thing that is relatively easy to measure, just count up the instructions. This can be done with instruction trace, logging, or simulation tools. CPI – This can be difficult to measure exactly because it depends on the processor organization as well as the instruction stream. Pipelining and caching will affect the CPI, but it is possible to simulate the system in design and estimate the CPI.

49
Example on effect of locality

50
Common Fallacies, Pitfalls Falling prey to Amdahl’s Law – Should measure speedup before spending effort to enhance it Single point of failure – E.g. single fan may limit reliability of the disk subsystem Fallacy: The cost of the processor dominates the cost of the system

51
Common Fallacies, Pitfalls Fallacy: Benchmarks remain valid indefinitely – Benchmark reverse engineering in compilers Fallacy: The rated mean time to failure of X is 1,200,000 hours or almost 140 years, so X will practically never fail – More useful measure would be % of disks that fail Fallacy: Peak performance tracks observed performance – Example: Alpha in 1994 announced as being capable of executing 1.2 billion instructions per second at its 300 Mhz clock rate.

52
Common Fallacies, Pitfalls Fault detection can lower availability – Hardware has a lot of state that is not always critical to proper operation E.g. if cache prefetch fails, program will still work, but a fault detection mechanism could crash the program or raise errors that take time to process Less than 30% of operations on the critical path for Itanium 2

53
Common Fallacies, Pitfalls Fallacy: MIPS is a useful benchmark Example: Say multiply FP instruction requires 4 clock cycles. However, instead of executing the FP multiply instruction, we could instead use a software floating point routine that used only Integer instructions. Since the integer instructions are simpler, they will require fewer clock cycles. For simplicity say that each integer instruction requires 2 clock cycles and it takes 20 of them to implement the FP multiply. Then for a 1 Mhz machine: – FP Multiply has a CPI of 4 – MIPS = 1 / 4 = 0.25 The software FP Multiply using integer instructions has a CPI of 2 – MIPS = 1 / 2 = 0.50 The software version has higher MIPS! Lost in the analysis is that it takes many more integer instructions than floating point instructions to do the same thing.