lecture 2: system metrics and pipeliningrajeev/cs6810/pres/07-6810-02.pdf · amdahl’s law •...

21
1 Lecture 2: System Metrics and Pipelining Today’s topics: (Sections 1.6, 1.7, 1.9, A.1) ¾ Quantitative principles of computer design ¾ Measuring cost and dependability ¾ Introduction to pipelining

Upload: others

Post on 22-Apr-2020

5 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

1

Lecture 2: System Metrics and Pipelining

• Today’s topics: (Sections 1.6, 1.7, 1.9, A.1)

Quantitative principles of computer designMeasuring cost and dependabilityIntroduction to pipelining

Page 2: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

2

Amdahl’s Law

• Architecture design is very bottleneck-driven – make thecommon case fast, do not waste resources on a componentthat has little impact on overall performance/power

• Amdahl’s Law: performance improvements through anenhancement is limited by the fraction of time theenhancement comes into play

• Example: a web server spends 40% of time in the CPUand 60% of time doing I/O – a new processor that is tentimes faster results in a 36% reduction in execution time(speedup of 1.56) – Amdahl’s Law states that maximumexecution time reduction is 40% (max speedup of 1.66)

Page 3: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

3

Principle of Locality

• Most programs are predictable in terms of instructionsexecuted and data accessed

• The 90-10 Rule: a program spends 90% of its executiontime in only 10% of the code

• Temporal locality: a program will shortly re-visit X

• Spatial locality: a program will shortly visit X+1

Page 4: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

4

Exploit Parallelism

• Most operations do not depend on each other – hence,execute them in parallel

• At the circuit level, simultaneously access multiple waysof a set-associative cache

• At the organization level, execute multiple instructions atthe same time

• At the system level, execute a different program while oneis waiting on I/O

Page 5: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

5

Factors Determining Cost

• Cost: amount spent by manufacturer to produce a finishedgood

• High volume faster learning curve, increasedmanufacturing efficiency (10% lower cost if volume doubles),lower R&D cost per produced item

• Commodities: identical products sold by many vendors inlarge volumes (keyboards, DRAMs) – low cost because ofhigh volume and competition among suppliers

Page 6: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

6

Wafers and Dies

An entire wafer is produced and chopped into dies that undergo testing and packaging

Page 7: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

7

Integrated Circuit Cost

• Cost of an integrated circuit =(cost of die + cost of packaging and testing) / final test yield

• Cost of die = cost of wafer / (dies per wafer x die yield)

• Dies/wafer = wafer area / die area - π wafer diam / die diag

• Die yield = wafer yield x (1 + (defect rate x die area) / α) -α

• Thus, die yield depends on die area and complexityarising from multiple manufacturing steps (α

~ 4.0)

Page 8: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

8

Integrated Circuit Cost Examples

• A 30 cm diameter wafer cost $5-6K in 2001

• Such a wafer yields about 366 good 1 cm2 dies and 1014good 0.49 cm2 dies (note the effect of area and yield)

• Die sizes: Alpha 21264 1.15 cm2 , Itanium 3.0 cm2 ,embedded processors are between 0.1 – 0.25 cm2

Page 9: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

9

Contribution of IC Costs to Total System Cost

Subsystem Fraction of total costCabinet: sheet metal, plastic, power supply, fans,

cables, nuts, bolts, manuals, shipping box6%

Processor 22%DRAM (128 MB) 5%

Video card 5%Motherboard 5%

Processor board subtotal 37%Keyboard and mouse 3%

Monitor 19%Hard disk (20 GB) 9%

DVD drive 6%I/O devices subtotal 37%

Software (OS + Office) 20%

Page 10: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

10

Defining Fault, Error, and Failure

• A fault produces a latent error; it becomes effective whenactivated; it leads to failure when the observed actualbehavior deviates from the ideal specified behavior

• Example I : a programming mistake is a fault; the buggycode is the latent error; when the code runs, it is effective;if the buggy code influences program output/behavior, afailure occurs

• Example II : an alpha particle strikes DRAM (fault); if itchanges the memory bit, it produces a latent error; whenthe value is read, the error becomes effective; if programoutput deviates, failure occurs

Page 11: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

11

Defining Reliability and Availability

• A system toggles betweenService accomplishment: service matches specificationsService interruption: services deviates from specs

• The toggle is caused by failures and restorations

• Reliability measures continuous service accomplishmentand is usually expressed as mean time to failure (MTTF)

• Availability measures fraction of time that service matchesspecifications, expressed as MTTF / (MTTF + MTTR)

Page 12: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

12

The Assembly Line

A

Start and finish a job before moving to the next

Time

Jobs

Break the job into smaller stagesB CA B C

A B CA B C

Unpipelined

Pipelined

Page 13: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

13

Performance Improvements?

• Does it take longer to finish each individual job?

• Does it take shorter to finish a series of jobs?

• What assumptions were made while answering thesequestions?

• Is a 10-stage pipeline better than a 5-stage pipeline?

Page 14: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

14

Quantitative Effects

• As a result of pipelining:Time in ns per instruction goes upNumber of cycles per instruction goes up (note theincrease in clock speed)Total execution time goes down, resulting in lowertime per instructionAverage cycles per instruction increases slightlyUnder ideal conditions, speedup= ratio of elapsed times between successive instruction

completions = number of pipeline stages = increase in clock speed

Page 15: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

15

A 5-Stage Pipeline

Page 16: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

16

A 5-Stage Pipeline

Use the PC to access the I-cache and increment PC by 4

Page 17: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

17

A 5-Stage Pipeline

Read registers, compare registers, compute branch target; for now, assumebranches take 2 cyc (there is enough work that branches can easily take more)

Page 18: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

18

A 5-Stage Pipeline

ALU computation, effective address computation for load/store

Page 19: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

19

A 5-Stage Pipeline

Memory access to/from data cache, stores finish in 4 cycles

Page 20: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

20

A 5-Stage Pipeline

Write result of ALU computation or load into register file

Page 21: Lecture 2: System Metrics and Pipeliningrajeev/cs6810/pres/07-6810-02.pdf · Amdahl’s Law • Architecture design is very bottleneck-driven – make the common case fast, do not

21

Title

• Bullet