Computer Architecture

Lecture 2: Fundamentals,
Memory Hierarchy, Caches

Prof. Onur Mutlu

ETH Zurich
Fall 2017
21 September 2017
Agenda for Today
n Finish up logistics from last lecture

n Why study computer architecture?

n Some fundamental concepts

n Memory hierarchy

n Caches

2
Takeaway From Lecture 1

Breaking the abstraction layers

(between components and
transformation hierarchy levels)

and knowing what is underneath

enables you to understand and

solve problems
3
Review: Major High-Level Goals of This Course
n Understand the principles
n Understand the precedents

n Based on such understanding:

q Enable you to evaluate tradeoffs of different designs and ideas
q Enable you to develop principled designs
q Enable you to develop novel, out-of-the-box designs

n The focus is on:

q Principles, precedents, and how to use them for new designs

n In Computer Architecture

4
 A Note on Hardware vs. Software
n This course might seem like it is only “Computer Hardware”

n However, you will be much more capable if you master both

hardware and software (and the interface between them)
q Can develop better software if you understand the hardware
q Can design better hardware if you understand the software
q Can design a better computing system if you understand both

n This course covers the HW/SW interface and microarchitecture

q We will focus on tradeoffs and how they affect software

5
What Do I Expect From You?
n Required background: Digital circuits course, programming, an
open mind willing to take in many exciting concepts.

n Learn the material thoroughly

q attend lectures, do the readings, do the exercises, do the labs
n Work hard: this will be a hard, but fun & informative course
n Ask questions, take notes, participate
n Perform the assigned readings
n Come to class, participate
n Start early
n If you want feedback, come to office hours

n Remember “Chance favors the prepared mind.” (Pasteur)

6
What Do I Expect From You?
n How you prepare and manage your time is very important

n There will be many lab and homework assignments

q They will take time
q Start early, work hard

n This will be a heavy course

q However, you will learn a lot of fascinating topics and
understand how a computing platform works
q And, it will hopefully change how you look at and think about
designs around you

7
How Will You Be Evaluated?

n Project assignments: 35%

n Midterm exam: 25%
n Final exam: 25%
n Homeworks: 15%

n More on this later

8
What Will You Learn
n Computer Architecture: The science and art of
designing, selecting, and interconnecting hardware
components and designing the hardware/software interface
to create a computing system that meets functional,
performance, energy consumption, cost, and other specific
goals.

n Traditional definition: “The term architecture is used

here to describe the attributes of a system as seen by the
programmer, i.e., the conceptual structure and functional
behavior as distinct from the organization of the dataflow
and controls, the logic design, and the physical
implementation.” Gene Amdahl, IBM Journal of R&D, April
1964
9
Computer Architecture in Levels of Transformation

Problem
Algorithm
Program/Language
Runtime System
(VM, OS, MM)
ISA (Architecture)
Microarchitecture
Logic
Circuits
Electrons

n Read: Patt, “Requirements, Bottlenecks, and Good Fortune: Agents for

Microprocessor Evolution,” Proceedings of the IEEE 2001.

10
Levels of Transformation, Revisited
n A user-centric view: computer designed for users
Problem
Algorithm
Program/Language User

Runtime System
(VM, OS, MM)
ISA
Microarchitecture
Logic
Circuits
Electrons

n The entire stack should be optimized for user

11
What Will You Learn?
n Fundamental principles and tradeoffs in designing the
hardware/software interface and major components of a
modern programmable microprocessor
q Focus on state-of-the-art (and some recent research and trends)
q Trade-offs and how to make them

n How to design, implement, and evaluate a functional modern

processor
q Semester-long lab assignments
q A combination of RTL implementation and higher-level simulation
q Focus is functionality first (then, on “how to do even better”)

n How to think critically and broadly

n How to work efficiently
12
Course Goals
n Goal 1: To familiarize those interested in computer system
design with both fundamental operation principles and design
tradeoffs of processor, memory, and platform architectures in
today’s systems.
q Strong emphasis on fundamentals, design tradeoffs, key
current/future issues
q Strong emphasis on looking backward, forward, up and down

n Goal 2: To provide the necessary background and experience to

design, implement, and evaluate a modern processor by
performing hands-on RTL and C-level implementation.
q Strong emphasis on functionality, hands-on design &

implementation, and efficiency.

q Strong emphasis on making things work, realizing ideas

13
Course Website

n http://safari.ethz.ch/architecture

n All slides, lecture videos, readings, assignments to be

posted
n Plus other useful information for the course

n Check frequently for announcements and due dates

14
Homework 0
n Due Sep 27
q https://safari.ethz.ch/farm/architecture_fs17/doku.php?
id=homeworks

n Information about yourself

n All future grading is predicated on homework 0

15
Heads Up
n We will have a few required review assignments
q Due likely end of next week

n HW1 will be out early next week

q Due in ~2 weeks

n Lab 1 will be out mid next week

q Due in ~2 weeks

n Check the website. Will also be announced in lecture

16
Why Study Computer
Architecture?

17
What is Computer Architecture?

n The science and art of designing, selecting, and

interconnecting hardware components and designing the
hardware/software interface to create a computing system
that meets functional, performance, energy consumption,
cost, and other specific goals.

n We will soon distinguish between the terms architecture,

and microarchitecture.
q Actually, we have, in Digital Circuits course

18
An Enabler: Moore’s Law

Moore, “Cramming more components onto integrated circuits,”

Electronics Magazine, 1965. Component counts double every other year

Image source: Intel

19
Number of transistors on an integrated circuit doubles ~ every two years
Image source: Wikipedia
20
Recommended Reading
n Moore, “Cramming more components onto integrated
circuits,” Electronics Magazine, 1965.

n Only 3 pages

n A quote:
“With unit cost falling as the number of components per
circuit rises, by 1975 economics may dictate squeezing as
many as 65 000 components on a single silicon chip.”

n Another quote:
“Will it be possible to remove the heat generated by tens of
thousands of components in a single silicon chip?”
21
What Do We Use These Transistors for?
n Your readings for this week should give you an idea…

n Required
q Patt, “Requirements, Bottlenecks, and Good Fortune: Agents for
Microprocessor Evolution,” Proceedings of the IEEE 2001.

n Required for Review as part of HW 1

q Moscibroda and Mutlu, “Memory Performance Attacks: Denial of
Memory Service in Multi-Core Systems,” USENIX Security 2007.
q Liu+, “RAIDR: Retention-Aware Intelligent DRAM Refresh,” ISCA
2012.
q Kim+, “Flipping Bits in Memory Without Accessing Them: An
Experimental Study of DRAM Disturbance Errors,” ISCA 2014.

22
Why Study Computer Architecture?
n Enable better systems: make computers faster, cheaper,
smaller, more reliable, …
q By exploiting advances and changes in underlying technology/circuits

n Enable new applications

q Life-like 3D visualization 20 years ago? Virtual reality?
q Self-driving cars?
q Personalized genomics? Personalized medicine?

n Enable better solutions to problems

q Software innovation is built on trends and changes in computer architecture
n > 50% performance improvement per year has enabled this innovation

n Understand why computers work the way they do

23
Computer Architecture Today (I)
n Today is a very exciting time to study computer architecture

n Industry is in a large paradigm shift (to multi-core and

beyond) – many different potential system designs possible

n Many difficult problems motivating and caused by the shift

q Power/energy constraints à heterogeneity?
q Complexity of design à multi-core and heterogeneity?
q Difficulties in technology scaling à new technologies?
q Memory wall/gap à processing in memory?
q Reliability wall/issues à new technologies?
q Programmability wall/problem
q Huge hunger for data and new data-intensive applications

n No clear, definitive answers to these problems

24
Computer Architecture Today (II)
n These problems affect all parts of the computing stack – if
we do not change the way we design systems
Problem
Many new demands
from the top Algorithm
(Look Up) Program/Language User Fast changing
demands and
personalities
of users
Runtime System
(VM, OS, MM) (Look Up)

ISA
Microarchitecture
Many new issues Logic
at the bottom Circuits
(Look Down)
Electrons

n No clear, definitive answers to these problems

25
Computer Architecture Today (III)
n Computing landscape is very different from 10-20 years ago
n Both UP (software and humanity trends) and DOWN
(technologies and their issues), FORWARD and BACKWARD,
and the resulting requirements and constraints

Hybrid Main Memory

Heterogeneous Persistent Memory/Storage

Processors and
Accelerators Every component and its
interfaces, as well as
entire system designs
are being re-examined
General Purpose GPUs

26
Computer Architecture Today (IV)
n You can revolutionize the way computers are built, if you
understand both the hardware and the software (and
change each accordingly)

n You can invent new paradigms for computation,

communication, and storage

n Recommended book: Thomas Kuhn, “The Structure of

Scientific Revolutions” (1962)
q Pre-paradigm science: no clear consensus in the field
q Normal science: dominant theory used to explain/improve
things (business as usual); exceptions considered anomalies
q Revolutionary science: underlying assumptions re-examined

27
Computer Architecture Today (IV)
n You can revolutionize the way computers are built, if you
understand both the hardware and the software (and
change each accordingly)

n You can invent new paradigms for computation,

communication, and storage

n Recommended book: Thomas Kuhn, “The Structure of

Scientific Revolutions” (1962)
q Pre-paradigm science: no clear consensus in the field
q Normal science: dominant theory used to explain/improve
things (business as usual); exceptions considered anomalies
q Revolutionary science: underlying assumptions re-examined

28
… but, first …
n Let’s understand the fundamentals…

n You can change the world only if you understand it well

enough…
q Especially the past and present dominant paradigms
q And, their advantages and shortcomings – tradeoffs
q And, what remains fundamental across generations
q And, what techniques you can use and develop to solve
problems

29
Fundamental Concepts

30
What is A Computer?
n Three key components

n Computation
n Communication
n Storage (memory)

31
What is A Computer?
n We will cover all three components

Processing
control Memory
(sequencing) (program I/O
and data)
datapath

32
The Von Neumann Model/Architecture
n Also called stored program computer (instructions in
memory). Two key properties:

n Stored program
q Instructions stored in a linear memory array
q Memory is unified between instructions and data
n The interpretation of a stored value depends on the control
signals When is a value interpreted as an instruction?

n Sequential instruction processing

q One instruction processed (fetched, executed, and completed) at a
time
q Program counter (instruction pointer) identifies the current instr.
q Program counter is advanced sequentially except for control transfer
instructions
33
The Von Neumann Model/Architecture
n Recommended readings
q Burks, Goldstein, von Neumann, “Preliminary discussion of
the logical design of an electronic computing instrument,”
1946.

q Patt and Patel book, Chapter 4, “The von Neumann Model”

n Stored program

n Sequential instruction processing

34
The Von Neumann Model (of a Computer)
MEMORY
Mem Addr Reg

Mem Data Reg

PROCESSING UNIT
INPUT OUTPUT
ALU TEMP

CONTROL UNIT

IP Inst Register

35
The Von Neumann Model (of a Computer)
n Q: Is this the only way that a computer can operate?

n A: No.
n Qualified Answer: No, but it has been the dominant way
q i.e., the dominant paradigm for computing
q for N decades

36
The Dataflow Model (of a Computer)
n Von Neumann model: An instruction is fetched and
executed in control flow order
q As specified by the instruction pointer
q Sequential unless explicit control flow instruction

n Dataflow model: An instruction is fetched and executed in

data flow order
q i.e., when its operands are ready
q i.e., there is no instruction pointer
q Instruction ordering specified by data flow dependence
n Each instruction specifies “who” should receive the result
n An instruction can “fire” whenever all operands are received
q Potentially many instructions can execute at the same time
n Inherently more parallel
37
Von Neumann vs Dataflow
n Consider a Von Neumann program
q What is the significance of the program order?
q What is the significance of the storage locations?
a b
v <= a + b;
w <= b * 2;
x <= v - w + *2
y <= v + w
z <= x * y
- +
Sequential
*
Dataflow

z
n Which model is more natural to you as a programmer?
38
More on Data Flow
n In a data flow machine, a program consists of data flow
nodes
q A data flow node fires (fetched and executed) when all it
inputs are ready
n i.e. when all inputs have tokens

n Data flow node and its ISA representation

39
Data Flow Nodes

40
An Example Data Flow Program

OUT

41
ISA-level Tradeoff: Instruction Pointer
n Do we need an instruction pointer in the ISA?
q Yes: Control-driven, sequential execution
n An instruction is executed when the IP points to it
n IP automatically changes sequentially (except for control flow
instructions)
q No: Data-driven, parallel execution
n An instruction is executed when all its operand values are
available (data flow)

n Tradeoffs: MANY high-level ones

q Ease of programming (for average programmers)?
q Ease of compilation?
q Performance: Extraction of parallelism?
q Hardware complexity?

42
ISA vs. Microarchitecture Level Tradeoff
n A similar tradeoff (control vs. data-driven execution) can be
made at the microarchitecture level

n ISA: Specifies how the programmer sees instructions to be

executed
q Programmer sees a sequential, control-flow execution order vs.
q Programmer sees a data-flow execution order

n Microarchitecture: How the underlying implementation

actually executes instructions
q Microarchitecture can execute instructions in any order as long
as it obeys the semantics specified by the ISA when making the
instruction results visible to software
n Programmer should see the order specified by the ISA
43
Let’s Get Back to the Von Neumann Model
n But, if you want to learn more about dataflow…

n Dennis and Misunas, “A preliminary architecture for a basic

data-flow processor,” ISCA 1974.
n Gurd et al., “The Manchester prototype dataflow
computer,” CACM 1985.
n A later lecture or course

n If you are really impatient:

q http://www.youtube.com/watch?v=D2uue7izU2c
q http://www.ece.cmu.edu/~ece740/f13/lib/exe/fetch.php?
media=onur-740-fall13-module5.2.1-dataflow-part1.ppt

44
The Von-Neumann Model
n All major instruction set architectures today use this model
q x86, ARM, MIPS, SPARC, Alpha, POWER

n Underneath (at the microarchitecture level), the execution

model of almost all implementations (or, microarchitectures)
is very different
q Pipelined instruction execution: Intel 80486 uarch
q Multiple instructions at a time: Intel Pentium uarch
q Out-of-order execution: Intel Pentium Pro uarch
q Separate instruction and data caches

n But, what happens underneath that is not consistent with

the von Neumann model is not exposed to software
q Difference between ISA and microarchitecture
45
What is Computer Architecture?
n ISA+implementation definition: The science and art of
designing, selecting, and interconnecting hardware
components and designing the hardware/software interface
to create a computing system that meets functional,
performance, energy consumption, cost, and other specific
goals.

n Traditional (ISA-only) definition: “The term

architecture is used here to describe the attributes of a
system as seen by the programmer, i.e., the conceptual
structure and functional behavior as distinct from the
organization of the dataflow and controls, the logic design,
and the physical implementation.” Gene Amdahl, IBM
Journal of R&D, April 1964
46
ISA vs. Microarchitecture
n ISA
q Agreed upon interface between software Problem
and hardware Algorithm
n SW/compiler assumes, HW promises
Program
q What the software writer needs to know ISA
to write and debug system/user programs Microarchitecture
n Microarchitecture Circuits
q Specific implementation of an ISA Electrons

q Not visible to the software

n Microprocessor
q ISA, uarch, circuits
q “Architecture” = ISA + microarchitecture
47
ISA vs. Microarchitecture
n What is part of ISA vs. Uarch?
q Gas pedal: interface for “acceleration”
q Internals of the engine: implement “acceleration”

n Implementation (uarch) can be various as long as it

satisfies the specification (ISA)
q Add instruction vs. Adder implementation
n Bit serial, ripple carry, carry lookahead adders are all part of
microarchitecture
q x86 ISA has many implementations: 286, 386, 486, Pentium,
Pentium Pro, Pentium 4, Core, …

n Microarchitecture usually changes faster than ISA

q Few ISAs (x86, ARM, SPARC, MIPS, Alpha) but many uarchs
q Why?
48
ISA
n Instructions
q Opcodes, Addressing Modes, Data Types
q Instruction Types and Formats
q Registers, Condition Codes
n Memory
q Address space, Addressability, Alignment
q Virtual memory management
n Call, Interrupt/Exception Handling
n Access Control, Priority/Privilege
n I/O: memory-mapped vs. instr.
n Task/thread Management
n Power and Thermal Management
n Multi-threading support, Multiprocessor support

49
Microarchitecture
n Implementation of the ISA under specific design constraints
and goals
n Anything done in hardware without exposure to software
q Pipelining
q In-order versus out-of-order instruction execution
q Memory access scheduling policy
q Speculative execution
q Superscalar processing (multiple instruction issue?)
q Clock gating
q Caching? Levels, size, associativity, replacement policy
q Prefetching?
q Voltage/frequency scaling?
q Error correction?
50
Property of ISA vs. Uarch?
n ADD instruction’s opcode
n Number of general purpose registers
n Number of ports to the register file
n Number of cycles to execute the MUL instruction
n Whether or not the machine employs pipelined instruction
execution

n Remember
q Microarchitecture: Implementation of the ISA under specific
design constraints and goals

51
Design Point
n A set of design considerations and their importance
q leads to tradeoffs in both ISA and uarch
n Considerations Problem
q Cost Algorithm
q Performance Program

q Maximum power consumption ISA

Microarchitecture
q Energy consumption (battery life)
Circuits
q Availability
Electrons
q Reliability and Correctness
q Time to Market

n Design point determined by the “Problem” space

(application space), the intended users/market
52
Application Space
n Dream, and they will appear…

53
Tradeoffs: Soul of Computer Architecture

n ISA-level tradeoffs

n Microarchitecture-level tradeoffs

n System and Task-level tradeoffs

q How to divide the labor between hardware and software

n Computer architecture is the science and art of making the

appropriate trade-offs to meet a design point
q Why art?

54
Why Is It (Somewhat) Art?
New demands Problem
from the top Algorithm
(Look Up) New demands and
Program/Language User
personalities of users
(Look Up)

Runtime System
(VM, OS, MM)
ISA
Microarchitecture
New issues and Logic
capabilities
Circuits
at the bottom
(Look Down) Electrons

n We do not (fully) know the future (applications, users, market)

55
Why Is It (Somewhat) Art?
Changing demands Problem
at the top Algorithm
(Look Up and Forward) Changing demands and
Program/Language User
personalities of users
(Look Up and Forward)

Runtime System
(VM, OS, MM)
ISA
Microarchitecture
Changing issues and Logic
capabilities
Circuits
at the bottom
(Look Down and Forward) Electrons

n And, the future is not constant (it changes)!

56
How Can We Adapt to the Future
n This is part of the task of a good computer architect

n Many options (bag of tricks)

q Keen insight and good design
q Good use of fundamentals and principles
n Efficient design
n Heterogeneity
n Reconfigurability
n …
q Good use of the underlying technology
q …

57
 We Covered a Lot of This in
Digital Circuits & Computer Architecture
One Slide Overview of Digital Circuits SS17
n Logic Design, Verilog, FPGAs

n ISA (MIPS)

n Single-cycle Microarchitectures

n Multi-cycle and Microprogrammed Microarchitectures

n Pipelining

n Issues in Pipelining: Control & Data Dependence Handling,

State Maintenance and Recovery, …

n Out-of-Order Execution

n Other Execution Paradigms

n Memory and Caches (very brief)

59
Covered Concurrent Execution Paradigms
n Pipelining
n Out-of-order execution
n Dataflow (at the ISA level)
n Superscalar Execution
n VLIW
n SIMD Processing (Vector and array processors, GPUs)
n Decoupled Access Execute
n Systolic Arrays

60
Digital Circuits Materials for Review (I)
n All Digital Circuits Lecture Videos Are Online:
q https://www.youtube.com/playlist?list=PL5Q2soXY2Zi-
IXWTT7xoNYpst5-zdZQ6y

n All Slides and Assignments Are Online:

q http://www.syssec.ethz.ch/education/Digitaltechnik_17.html

61
Digital Circuits Materials for Review (II)
n Particularly useful and relevant lectures for this course

n Pipelining (Lecture 15)

q https://youtu.be/vBGVRURaxl8

n Dependence handling (Lecture 16)

q https://youtu.be/B7bTbBRVdxA

n Pipelining Issues (Lecture 17)

q https://youtu.be/C5ViR0dGlLI

n Out-of-order execution (Lecture 18)

q https://youtu.be/R5G05HstI3A
62
This Course
n We will have more emphasis on
q The memory system
q Multiprocessing & multithreading
q Parallel processing paradigms

n We will likely dig deeper on some Digital Circuits concepts

(as time permits)
q ISA
q Branch handling
q …

63
Tentative Agenda (Upcoming Lectures)
n The memory hierarchy
n Caches, caches, more caches (high locality, high bandwidth)
n Virtualizing the memory hierarchy
n Main memory: DRAM
n Main memory control, scheduling, interference, management
n Memory latency tolerance and prefetching techniques
n Non-volatile memory & emerging technoogies

n Multiprocessors
n Coherence and consistency
n Interconnection networks
n Multi-core issues
n Multithreading
64
Optional Readings for Today & Next Week
n Memory Hierarchy and Caches

n Cache chapters from P&H: 5.1-5.3

n Memory/cache chapters from Hamacher+: 8.1-8.7

n An early cache paper by Maurice Wilkes

q Wilkes, “Slave Memories and Dynamic Storage Allocation,”
IEEE Trans. On Electronic Computers, 1965.

65
Memory (Programmer’s View)

66
Abstraction: Virtual vs. Physical Memory
n Programmer sees virtual memory
q Can assume the memory is “infinite”
n Reality: Physical memory size is much smaller than what
the programmer assumes
n The system (system software + hardware, cooperatively)
maps virtual memory addresses to physical memory
q The system automatically manages the physical memory
space transparently to the programmer

+ Programmer does not need to know the physical size of memory

nor manage it à A small physical memory can appear as a huge
one to the programmer à Life is easier for the programmer
-- More complex system software and architecture

A classic example of the programmer/(micro)architect tradeoff

67
(Physical) Memory System
n You need a larger level of storage to manage a small
amount of physical memory automatically
à Physical memory has a backing store: disk

n We will first start with the physical memory system

n For now, ignore the virtualàphysical indirection

n We will get back to it when the needs of virtual memory

start complicating the design of physical memory…

68
Idealism

Pipeline
Instruction (Instruction Data
Supply Supply
execution)

- Zero latency access - No pipeline stalls - Zero latency access

- Infinite capacity -Perfect data flow - Infinite capacity

(reg/memory dependencies)
- Zero cost - Infinite bandwidth
- Zero-cycle interconnect
- Perfect control flow (operand communication) - Zero cost

- Enough functional units

- Zero latency compute

69
The Memory Hierarchy
 71

DRAM BANKS
Memory in a Modern System

DRAM INTERFACE
DRAM MEMORY
CORE 1

CORE 3
CONTROLLER

L2 CACHE 1 L2 CACHE 3
L2 CACHE 0 L2 CACHE 2

CORE 2
CORE 0
SHARED L3 CACHE
Ideal Memory
n Zero access time (latency)
n Infinite capacity
n Zero cost
n Infinite bandwidth (to support multiple accesses in parallel)

72
The Problem
n Ideal memory’s requirements oppose each other

n Bigger is slower
q Bigger à Takes longer to determine the location

n Faster is more expensive

q Memory technology: SRAM vs. DRAM vs. Disk vs. Tape

n Higher bandwidth is more expensive

q Need more banks, more ports, higher frequency, or faster
technology

73
Memory Technology: DRAM
n Dynamic random access memory
n Capacitor charge state indicates stored value
q Whether the capacitor is charged or discharged indicates
storage of 1 or 0
q 1 capacitor
q 1 access transistor

row enable
n Capacitor leaks through the RC path
q DRAM cell loses charge over time

_bitline
q DRAM cell needs to be refreshed

74
Memory Technology: SRAM
n Static random access memory
n Two cross coupled inverters store a single bit
q Feedback path enables the stored value to persist in the “cell”
q 4 transistors for storage
q 2 transistors for access

row select

_bitline
bitline

75
Memory Bank Organization and Operation
n Read access sequence:

1. Decode row address

& drive word-lines

2. Selected bits drive

bit-lines
• Entire row read

3. Amplify row data

4. Decode column
address & select subset
of row
• Send to output

5. Precharge bit-lines
• For next access

76
SRAM (Static Random Access Memory)
Read Sequence
row select 1. address decode
2. drive row select
3. selected bit-cells drive bitlines

_bitline
bitline

(entire row is read together)

4. differential sensing and column select
(data is ready)
5. precharge all bitlines
(for next read or write)
bit-cell array
n+m n 2n 2n row x 2m-col Access latency dominated by steps 2 and 3
Cycling time dominated by steps 2, 3 and 5
(n≈m to minimize
overall latency) - step 2 proportional to 2m
- step 3 and 5 proportional to 2n
m 2m diff pairs
sense amp and mux
1
77
DRAM (Dynamic Random Access Memory)
row enable Bits stored as charges on node
capacitance (non-restorative)
bit cell loses charge when read
_bitline
-

- bit cell loses charge over time

Read Sequence
1~3 same as SRAM
4. a “flip-flopping” sense amp
RAS
bit-cell array amplifies and regenerates the
bitline, data bit is mux’ed out
n 2n 2n row x 2m-col 5. precharge all bitlines
(n≈m to minimize
overall latency) Destructive reads
Charge loss over time
m 2m
sense amp and mux Refresh: A DRAM controller must
1 periodically read each row within
A DRAM die comprises the allowed refresh time (10s of
CAS of multiple such arrays ms) such that charge is restored
78
DRAM vs. SRAM
n DRAM
q Slower access (capacitor)
q Higher density (1T 1C cell)
q Lower cost
q Requires refresh (power, performance, circuitry)
q Manufacturing requires putting capacitor and logic together

n SRAM
q Faster access (no capacitor)
q Lower density (6T cell)
q Higher cost
q No need for refresh
q Manufacturing compatible with logic process (no capacitor)
79
The Problem
n Bigger is slower
q SRAM, 512 Bytes, sub-nanosec
q SRAM, KByte~MByte, ~nanosec
q DRAM, Gigabyte, ~50 nanosec
q Hard Disk, Terabyte, ~10 millisec

n Faster is more expensive (dollars and chip area)

q SRAM, < 10$ per Megabyte
q DRAM, < 1$ per Megabyte
q Hard Disk < 1$ per Gigabyte
q These sample values (circa ~2011) scale with time

n Other technologies have their place as well

q Flash memory, PC-RAM, MRAM, RRAM (not mature yet)
80
Why Memory Hierarchy?
n We want both fast and large

n But we cannot achieve both with a single level of memory

n Idea: Have multiple levels of storage (progressively bigger

and slower as the levels are farther from the processor)
and ensure most of the data the processor needs is kept in
the fast(er) level(s)

81
The Memory Hierarchy

move what you use here fast

small

With good locality of

reference, memory

cheaper per byte

appears as fast as
and as large as

faster per byte

backup
everything big but slow
here
82
Memory Hierarchy
n Fundamental tradeoff
q Fast memory: small
q Large memory: slow
n Idea: Memory hierarchy

Hard Disk
Main
CPU Cache Memory
RF (DRAM)

n Latency, cost, size,

bandwidth

83
Locality
n One’s recent past is a very good predictor of his/her near
future.

n Temporal Locality: If you just did something, it is very

likely that you will do the same thing again soon
q since you are here today, there is a good chance you will be
here again and again regularly

n Spatial Locality: If you did something, it is very likely you

will do something similar/related (in space)
q every time I find you in this room, you are probably sitting
close to the same people

84
Memory Locality
n A “typical” program has a lot of locality in memory
references
q typical programs are composed of “loops”

n Temporal: A program tends to reference the same memory

location many times and all within a small window of time

n Spatial: A program tends to reference a cluster of memory

locations at a time
q most notable examples:
n 1. instruction memory references
n 2. array/data structure references

85
Caching Basics: Exploit Temporal Locality
n Idea: Store recently accessed data in automatically
managed fast memory (called cache)
n Anticipation: the data will be accessed again soon

n Temporal locality principle

q Recently accessed data will be again accessed in the near
future
q This is what Maurice Wilkes had in mind:
n Wilkes, “Slave Memories and Dynamic Storage Allocation,” IEEE
Trans. On Electronic Computers, 1965.
n “The use is discussed of a fast core memory of, say 32000 words
as a slave to a slower core memory of, say, one million words in
such a way that in practical cases the effective access time is
nearer that of the fast memory than that of the slow memory.”

86
Caching Basics: Exploit Spatial Locality
n Idea: Store addresses adjacent to the recently accessed
one in automatically managed fast memory
q Logically divide memory into equal size blocks
q Fetch to cache the accessed block in its entirety
n Anticipation: nearby data will be accessed soon

n Spatial locality principle

q Nearby data in memory will be accessed in the near future
n E.g., sequential instruction access, array traversal
q This is what IBM 360/85 implemented
n 16 Kbyte cache with 64 byte blocks
n Liptay, “Structural aspects of the System/360 Model 85 II: the
cache,” IBM Systems Journal, 1968.

87
The Bookshelf Analogy
n Book in your hand
n Desk
n Bookshelf
n Boxes at home
n Boxes in storage

n Recently-used books tend to stay on desk

q Comp Arch books, books for classes you are currently taking
q Until the desk gets full
n Adjacent books in the shelf needed around the same time
q If I have organized/categorized my books well in the shelf

88
Caching in a Pipelined Design
n The cache needs to be tightly integrated into the pipeline
q Ideally, access in 1-cycle so that dependent operations do not
stall
n High frequency pipeline à Cannot make the cache large
q But, we want a large cache AND a pipelined design
n Idea: Cache hierarchy

Main
Level 2 Memory
CPU Level1 Cache (DRAM)
RF Cache

89
A Note on Manual vs. Automatic Management
n Manual: Programmer manages data movement across levels
-- too painful for programmers on substantial programs
q “core” vs “drum” memory in the 50’s

q still done in some embedded processors (on-chip scratch pad

SRAM in lieu of a cache) and GPUs (called “shared memory”)

n Automatic: Hardware manages data movement across levels,

transparently to the programmer
++ programmer’s life is easier
q the average programmer doesn’t need to know about it

n You don’t need to know how big the cache is and how it works to
write a “correct” program! (What if you want a “fast” program?)

90
Automatic Management in Memory Hierarchy
n Wilkes, “Slave Memories and Dynamic Storage Allocation,”
IEEE Trans. On Electronic Computers, 1965.

n “By a slave memory I mean one which automatically

accumulates to itself words that come from a slower main
memory, and keeps them available for subsequent use
without it being necessary for the penalty of main memory
access to be incurred again.”
91
Historical Aside: Other Cache Papers
n Fotheringham, “Dynamic Storage Allocation in the Atlas
Computer, Including an Automatic Use of a Backing Store,”
CACM 1961.
q http://dl.acm.org/citation.cfm?id=366800

n Bloom, Cohen, Porter, “Considerations in the Design of a

Computer with High Logic-to-Memory Speed Ratio,” AIEE
Gigacycle Computing Systems Winter Meeting, Jan. 1962.

92
 A Modern Memory Hierarchy
Register File
32 words, sub-nsec
manual/compiler
Memory register spilling
L1 cache
AbstracWon ~32 KB, ~nsec

L2 cache
512 KB ~ 1MB, many nsec AutomaWc
HW cache
L3 cache, management
.....

Main memory (DRAM),

GB, ~100 nsec
automaWc
Swap Disk
demand
100 GB, ~10 msec paging
93
Hierarchical Latency Analysis
n For a given memory hierarchy level i it has a technology-intrinsic
access time of ti, The perceived access time Ti is longer than ti
n Except for the outer-most hierarchy, when looking for a given
address there is
q a chance (hit-rate hi) you “hit” and access time is ti

q a chance (miss-rate mi) you “miss” and access time ti +Ti+1

q hi + mi = 1

n Thus
Ti = hi·ti + mi·(ti + Ti+1)
Ti = ti + mi ·Ti+1

hi and mi are defined to be the hit-rate

and miss-rate of just the references that missed at Li-1
94
Hierarchy Design Considerations
n Recursive latency equation
Ti = ti + mi ·Ti+1
n The goal: achieve desired T1 within allowed cost
n Ti ≈ ti is desirable

n Keep mi low
q increasing capacity Ci lowers mi, but beware of increasing ti
q lower mi by smarter management (replacement::anticipate what you
don’t need, prefetching::anticipate what you will need)

n Keep Ti+1 low

q faster lower hierarchies, but beware of increasing cost
q introduce intermediate hierarchies as a compromise
95
Intel Pentium 4 Example
n 90nm P4, 3.6 GHz
n L1 D-cache if m1=0.1, m2=0.1
T1=7.6, T2=36
q C1 = 16K
q t1 = 4 cyc int / 9 cycle fp if m1=0.01, m2=0.01
n L2 D-cache T1=4.2, T2=19.8
q C2 =1024 KB if m1=0.05, m2=0.01
q t2 = 18 cyc int / 18 cyc fp T1=5.00, T2=19.8
n Main memory if m1=0.01, m2=0.50
q t3 = ~ 50ns or 180 cyc T1=5.08, T2=108
n Notice
q best case latency is not 1
q worst case access latencies are into 500+ cycles
Cache Basics and Operation
Cache
n Generically, any structure that “memoizes” frequently used
results to avoid repeating the long-latency operations
required to reproduce the results from scratch, e.g. a web
cache

n Most commonly in the on-die context: an automatically-

managed memory hierarchy based on SRAM
q memoize in SRAM the most frequently accessed DRAM
memory locations to avoid repeatedly paying for the DRAM
access latency

98
Caching Basics
n Block (line): Unit of storage in the cache
q Memory is logically divided into cache blocks that map to
locations in the cache

n On a reference:
q HIT: If in cache, use cached data instead of accessing memory
q MISS: If not in cache, bring block into cache
n Maybe have to kick something else out to do it

n Some important cache design decisions

q Placement: where and how to place/find a block in cache?
q Replacement: what data to remove to make room in cache?
q Granularity of management: large or small blocks? Subblocks?
q Write policy: what do we do about writes?
q Instructions/data: do we treat them separately?
99
Cache Abstraction and Metrics

Address
Tag Store Data Store

(is the address (stores

in the cache? memory
+ bookkeeping) blocks)

Hit/miss? Data

n Cache hit rate = (# hits) / (# hits + # misses) = (# hits) / (# accesses)

n Average memory access time (AMAT)
= ( hit-rate * hit-latency ) + ( miss-rate * miss-latency )
n Aside: Can reducing AMAT reduce performance?
100
A Basic Hardware Cache Design
n We will start with a basic hardware cache design

n Then, we will examine a multitude of ideas to make it

better

101
Blocks and Addressing the Cache
n Memory is logically divided into fixed-size blocks

n Each block maps to a location in the cache, determined by

the index bits in the address tag index byte in block
q used to index into the tag and data stores 2b 3 bits 3 bits

8-bit address

n Cache access:
1) index into the tag and data stores with index bits in address
2) check valid bit in tag store
3) compare tag bits in address with the stored tag in tag store

n If a block is in the cache (cache hit), the stored tag should be

valid and match the tag of the block
102
Direct-Mapped Cache: Placement and Access
n Assume byte-addressable memory:
256 bytes, 8-byte blocks à 32 blocks
n Assume cache: 64 bytes, 8 blocks
q Direct-mapped: A block can go to only one location
tag index byte in block
2b 3 bits 3 bits Tag store Data store
Address

V tag

byte in block
=? MUX

Hit? Data
q Addresses with same index contend for the same location
n Cause conflict misses
103
Direct-Mapped Caches
n Direct-mapped cache: Two blocks in memory that map to
the same index in the cache cannot be present in the cache
at the same time
q One index à one entry

n Can lead to 0% hit rate if more than one block accessed in

an interleaved manner map to the same index
q Assume addresses A and B have the same index bits but
different tag bits
q A, B, A, B, A, B, A, B, … à conflict in the cache index
q All accesses are conflict misses

104
 Set Associativity
n Addresses 0 and 8 always conflict in direct mapped cache
n Instead of having one column of 8, have 2 columns of 4 blocks

Tag store Data store

SET

V tag V tag

=? =? MUX

Logic byte in block

MUX
Hit?
Address
tag index byte in block
Key idea: Associative memory within the set
3b 2 bits 3 bits
+ Accommodates conflicts better (fewer conflict misses)
-- More complex, slower access, larger tag store
105
Higher Associativity
n 4-way Tag store

=? =? =? =?

Logic Hit?

Data store

MUX
byte in block
MUX

+ Likelihood of conflict misses even lower

-- More tag comparators and wider data mux; larger tags
106
Full Associativity
n Fully associative cache
q A block can be placed in any cache location

Tag store

=? =? =? =? =? =? =? =?

Logic

Hit?

Data store

MUX
byte in block
MUX

107
Associativity (and Tradeoffs)
n Degree of associativity: How many blocks can map to the
same index (or set)?

n Higher associativity
++ Higher hit rate
-- Slower cache access time (hit latency and data access latency)
-- More expensive hardware (more comparators)
hit rate

n Diminishing returns from higher

associativity

associativity
108
Computer Architecture
Lecture 2: Fundamentals,
Memory Hierarchy, Caches

Prof. Onur Mutlu

ETH Zurich
Fall 2017
21 September 2017
 We did not cover the following slides in lecture.
These are for your preparation for the next lecture.
Issues in Set-Associative Caches
n Think of each block in a set having a “priority”
q Indicating how important it is to keep the block in the cache
n Key issue: How do you determine/adjust block priorities?
n There are three key decisions in a set:
q Insertion, promotion, eviction (replacement)

n Insertion: What happens to priorities on a cache fill?

q Where to insert the incoming block, whether or not to insert the block
n Promotion: What happens to priorities on a cache hit?
q Whether and how to change block priority
n Eviction/replacement: What happens to priorities on a cache
miss?
q Which block to evict and how to adjust priorities
111
Eviction/Replacement Policy
n Which block in the set to replace on a cache miss?
q Any invalid block first
q If all are valid, consult the replacement policy
n Random
n FIFO
n Least recently used (how to implement?)
n Not most recently used
n Least frequently used?
n Least costly to re-fetch?
q Why would memory accesses have different cost?
n Hybrid replacement policies
n Optimal replacement policy?

112
Implementing LRU
n Idea: Evict the least recently accessed block
n Problem: Need to keep track of access ordering of blocks

n Question: 2-way set associative cache:

q What do you need to implement LRU perfectly?

n Question: 4-way set associative cache:

q What do you need to implement LRU perfectly?
q How many different orderings possible for the 4 blocks in the
set?
q How many bits needed to encode the LRU order of a block?
q What is the logic needed to determine the LRU victim?

113
Approximations of LRU
n Most modern processors do not implement “true LRU” (also
called “perfect LRU”) in highly-associative caches

n Why?
q True LRU is complex
q LRU is an approximation to predict locality anyway (i.e., not
the best possible cache management policy)

n Examples:
q Not MRU (not most recently used)
q Hierarchical LRU: divide the N-way set into M “groups”, track
the MRU group and the MRU way in each group
q Victim-NextVictim Replacement: Only keep track of the victim
and the next victim
114
Hierarchical LRU (not MRU)
n Divide a set into multiple groups
n Keep track of only the MRU group
n Keep track of only the MRU block in each group

n On replacement, select victim as:

q A not-MRU block in one of the not-MRU groups (randomly pick
one of such blocks/groups)

115
Hierarchical LRU (not MRU): Questions
n 16-way cache
n 2 8-way groups

n What is an access pattern that performs worse than true

LRU?

n What is an access pattern that performs better than true

LRU?

116
Victim/Next-Victim Policy
n Only 2 blocks’ status tracked in each set:
q victim (V), next victim (NV)
q all other blocks denoted as (O) – Ordinary block

n On a cache miss
q Replace V
q Demote NV to V
q Randomly pick an O block as NV

n On a cache hit to V
q Demote NV to V
q Randomly pick an O block as NV
q Turn V to O
117
Victim/Next-Victim Policy (II)
n On a cache hit to NV
q Randomly pick an O block as NV
q Turn NV to O

n On a cache hit to O
q Do nothing

118
Victim/Next-Victim Example

119
Cache Replacement Policy: LRU or Random
n LRU vs. Random: Which one is better?
q Example: 4-way cache, cyclic references to A, B, C, D, E
n 0% hit rate with LRU policy
n Set thrashing: When the “program working set” in a set is
larger than set associativity
q Random replacement policy is better when thrashing occurs
n In practice:
q Depends on workload
q Average hit rate of LRU and Random are similar

n Best of both Worlds: Hybrid of LRU and Random

q How to choose between the two? Set sampling
n See Qureshi et al., “A Case for MLP-Aware Cache Replacement,“
ISCA 2006.
120
What Is the Optimal Replacement Policy?
n Belady’s OPT
q Replace the block that is going to be referenced furthest in the
future by the program
q Belady, “A study of replacement algorithms for a virtual-
storage computer,” IBM Systems Journal, 1966.
q How do we implement this? Simulate?

n Is this optimal for minimizing miss rate?

n Is this optimal for minimizing execution time?
q No. Cache miss latency/cost varies from block to block!
q Two reasons: Remote vs. local caches and miss overlapping
q Qureshi et al. “A Case for MLP-Aware Cache Replacement,“
ISCA 2006.

121
Aside: Cache versus Page Replacement
n Physical memory (DRAM) is a cache for disk
q Usually managed by system software via the virtual memory
subsystem

n Page replacement is similar to cache replacement

n Page table is the “tag store” for physical memory data store

n What is the difference?

q Required speed of access to cache vs. physical memory
q Number of blocks in a cache vs. physical memory
q “Tolerable” amount of time to find a replacement candidate
(disk versus memory access latency)
q Role of hardware versus software
122
What’s In A Tag Store Entry?
n Valid bit
n Tag
n Replacement policy bits

n Dirty bit?
q Write back vs. write through caches

123
Handling Writes (I)
n When do we write the modified data in a cache to the next level?
n Write through: At the time the write happens
n Write back: When the block is evicted

q Write-back
+ Can combine multiple writes to the same block before eviction
q Potentially saves bandwidth between cache levels + saves energy
-- Need a bit in the tag store indicating the block is “dirty/modified”

q Write-through
+ Simpler
+ All levels are up to date. Consistency: Simpler cache coherence because
no need to check lower-level caches
-- More bandwidth intensive; no combining of writes

124
Handling Writes (II)
n Do we allocate a cache block on a write miss?
q Allocate on write miss: Yes
q No-allocate on write miss: No

n Allocate on write miss

+ Can combine writes instead of writing each of them
individually to next level
+ Simpler because write misses can be treated the same way as
read misses
-- Requires (?) transfer of the whole cache block

n No-allocate
+ Conserves cache space if locality of writes is low (potentially
better cache hit rate)
125
Handling Writes (III)
n What if the processor writes to an entire block over a small
amount of time?

n Is there any need to bring the block into the cache from
memory in the first place?

n Ditto for a portion of the block, i.e., subblock

q E.g., 4 bytes out of 64 bytes

126
Sectored Caches
n Idea: Divide a block into subblocks (or sectors)
q Have separate valid and dirty bits for each sector
q When is this useful? (Think writes…)

++ No need to transfer the entire cache block into the cache

(A write simply validates and updates a subblock)
++ More freedom in transferring subblocks into the cache (a
cache block does not need to be in the cache fully)
(How many subblocks do you transfer on a read?)

-- More complex design

-- May not exploit spatial locality fully when used for reads
v d subblock v d subblock v d subblock tag
127
Instruction vs. Data Caches
n Separate or Unified?

n Unified:
+ Dynamic sharing of cache space: no overprovisioning that
might happen with static partitioning (i.e., split I and D
caches)
-- Instructions and data can thrash each other (i.e., no
guaranteed space for either)
-- I and D are accessed in different places in the pipeline. Where
do we place the unified cache for fast access?

n First level caches are almost always split

q Mainly for the last reason above
n Second and higher levels are almost always unified
128
Multi-level Caching in a Pipelined Design
n First-level caches (instruction and data)
q Decisions very much affected by cycle time
q Small, lower associativity
q Tag store and data store accessed in parallel
n Second-level caches
q Decisions need to balance hit rate and access latency
q Usually large and highly associative; latency not as important
q Tag store and data store accessed serially

n Serial vs. Parallel access of levels

q Serial: Second level cache accessed only if first-level misses
q Second level does not see the same accesses as the first
n First level acts as a filter (filters some temporal and spatial locality)
n Management policies are therefore different
129
Cache Performance
Cache Parameters vs. Miss/Hit Rate
n Cache size

n Block size

n Associativity

n Replacement policy
n Insertion/Placement policy

131
Cache Size
n Cache size: total data (not including tag) capacity
q bigger can exploit temporal locality better
q not ALWAYS better
n Too large a cache adversely affects hit and miss latency
q smaller is faster => bigger is slower
q access time may degrade critical path
hit rate
n Too small a cache
q doesn’t exploit temporal locality well
q useful data replaced often “working set”
size

n Working set: the whole set of data

the executing application references
cache size
q Within a time interval
132
Block Size
n Block size is the data that is associated with an address tag
q not necessarily the unit of transfer between hierarchies
n Sub-blocking: A block divided into multiple pieces (each with V bit)
q Can improve “write” performance

n Too small blocks hit rate

q don’t exploit spatial locality well

q have larger tag overhead

n Too large blocks

q too few total # of blocks à less
temporal locality exploitation
block
q waste of cache space and bandwidth/energy size
if spatial locality is not high
133
Large Blocks: Critical-Word and Subblocking
n Large cache blocks can take a long time to fill into the cache
q fill cache line critical word first
q restart cache access before complete fill

n Large cache blocks can waste bus bandwidth

q divide a block into subblocks
q associate separate valid bits for each subblock
q When is this useful?

v d subblock v d subblock v d subblock tag

134
Associativity
n How many blocks can map to the same index (or set)?

n Larger associativity
q lower miss rate (reduced conflicts)
q higher hit latency and area cost (plus diminishing returns)
hit rate

n Smaller associativity
q lower cost
q lower hit latency
n Especially important for L1 caches

n Power of 2 associativity required? associativity

135
Classification of Cache Misses
n Compulsory miss
q first reference to an address (block) always results in a miss
q subsequent references should hit unless the cache block is
displaced for the reasons below

n Capacity miss
q cache is too small to hold everything needed
q defined as the misses that would occur even in a fully-associative
cache (with optimal replacement) of the same capacity

n Conflict miss
q defined as any miss that is neither a compulsory nor a capacity
miss

136
How to Reduce Each Miss Type
n Compulsory
q Caching cannot help
q Prefetching can
n Conflict
q More associativity
q Other ways to get more associativity without making the
cache associative
n Victim cache
n Better, randomized indexing
n Software hints?
n Capacity
q Utilize cache space better: keep blocks that will be referenced
q Software management: divide working set such that each
“phase” fits in cache
137
How to Improve Cache Performance
n Three fundamental goals

n Reducing miss rate

q Caveat: reducing miss rate can reduce performance if more
costly-to-refetch blocks are evicted

n Reducing miss latency or miss cost

n Reducing hit latency or hit cost

138
Improving Basic Cache Performance
n Reducing miss rate
q More associativity
q Alternatives/enhancements to associativity
n Victim caches, hashing, pseudo-associativity, skewed associativity
q Better replacement/insertion policies
q Software approaches
n Reducing miss latency/cost
q Multi-level caches
q Critical word first
q Subblocking/sectoring
q Better replacement/insertion policies
q Non-blocking caches (multiple cache misses in parallel)
q Multiple accesses per cycle
q Software approaches
139
Cheap Ways of Reducing Conflict Misses
n Instead of building highly-associative caches:

n Victim Caches
n Hashed/randomized Index Functions
n Pseudo Associativity
n Skewed Associative Caches
n …

140
Victim Cache: Reducing Conflict Misses
Victim
Direct cache
Mapped Next Level
Cache Cache

n Jouppi, “Improving Direct-Mapped Cache Performance by the Addition of a Small

Fully-Associative Cache and Prefetch Buffers,” ISCA 1990.
n Idea: Use a small fully-associative buffer (victim cache) to
store recently evicted blocks
+ Can avoid ping ponging of cache blocks mapped to the same set (if two
cache blocks continuously accessed in nearby time conflict with each
other)
-- Increases miss latency if accessed serially with L2; adds complexity

141
Hashing and Pseudo-Associativity
n Hashing: Use better “randomizing” index functions
+ can reduce conflict misses
n by distributing the accessed memory blocks more evenly to sets
n Example of conflicting accesses: strided access pattern where
stride value equals number of sets in cache
-- More complex to implement: can lengthen critical path

n Pseudo-associativity (Poor Man’s associative cache)

q Serial lookup: On a miss, use a different index function and
access cache again
q Given a direct-mapped array with K cache blocks
n Implement K/N sets
n Given address Addr, sequentially look up: {0,Addr[lg(K/N)-1: 0]},
{1,Addr[lg(K/N)-1: 0]}, … , {N-1,Addr[lg(K/N)-1: 0]}
142
Skewed Associative Caches
n Idea: Reduce conflict misses by using different index
functions for each cache way

n Seznec, “A Case for Two-Way Skewed-Associative Caches,”

ISCA 1993.

143
Skewed Associative Caches (I)
n Basic 2-way associative cache structure

Way 0 Way 1
Same index function
for each way

=? =?

Tag Index Byte in Block

144
Skewed Associative Caches (II)
n Skewed associative caches
q Each bank has a different index function
same index
redistributed to same index
Way 0 different sets same set Way 1

f0

=? tag index byte in block =?

145
Skewed Associative Caches (III)
n Idea: Reduce conflict misses by using different index
functions for each cache way

n Benefit: indices are more randomized (memory blocks are

better distributed across sets)
q Less likely two blocks have same index (esp. with strided access)
n Reduced conflict misses

n Cost: additional latency of hash function

n Seznec, “A Case for Two-Way Skewed-Associative Caches,” ISCA 1993.

146
Software Approaches for Higher Hit Rate
n Restructuring data access patterns
n Restructuring data layout

n Loop interchange
n Data structure separation/merging
n Blocking
n …

147
Restructuring Data Access Patterns (I)
n Idea: Restructure data layout or data access patterns
n Example: If column-major
q x[i+1,j] follows x[i,j] in memory
q x[i,j+1] is far away from x[i,j]

Poor code Better code

for i = 1, rows for j = 1, columns
for j = 1, columns for i = 1, rows
sum = sum + x[i,j] sum = sum + x[i,j]

n This is called loop interchange

n Other optimizations can also increase hit rate
q Loop fusion, array merging, …
n What if multiple arrays? Unknown array size at compile time?
148
Restructuring Data Access Patterns (II)
n Blocking
q Divide loops operating on arrays into computation chunks so
that each chunk can hold its data in the cache
q Avoids cache conflicts between different chunks of
computation
q Essentially: Divide the working set so that each piece fits in
the cache

n But, there are still self-conflicts in a block

1. there can be conflicts among different arrays
2. array sizes may be unknown at compile/programming time

149
Restructuring Data Layout (I)
n Pointer based traversal
struct Node { (e.g., of a linked list)
struct Node* node;
int key; n Assume a huge linked
char [256] name; list (1M nodes) and
char [256] school; unique keys
}
n Why does the code on
while (node) { the left have poor cache
if (nodeàkey == input-key) { hit rate?
// access other fields of node q “Other fields” occupy
} most of the cache line
node = nodeànext;
even though rarely
}
accessed!

150
Restructuring Data Layout (II)
struct Node { n Idea: separate frequently-
struct Node* node; used fields of a data
int key; structure and pack them
struct Node-data* node-data;
} into a separate data
structure
struct Node-data {
char [256] name;
char [256] school; n Who should do this?
} q Programmer
q Compiler
while (node) {
n Profiling vs. dynamic
if (nodeàkey == input-key) {
// access nodeànode-data q Hardware?
} q Who can determine what
node = nodeànext; is frequently used?
}
151
Improving Basic Cache Performance
n Reducing miss rate
q More associativity
q Alternatives/enhancements to associativity
n Victim caches, hashing, pseudo-associativity, skewed associativity
q Better replacement/insertion policies
q Software approaches
n Reducing miss latency/cost
q Multi-level caches
q Critical word first
q Subblocking/sectoring
q Better replacement/insertion policies
q Non-blocking caches (multiple cache misses in parallel)
q Multiple accesses per cycle
q Software approaches
152
Miss Latency/Cost
n What is miss latency or miss cost affected by?
q Where does the miss get serviced from?
n Local vs. remote memory
n What level of cache in the hierarchy?
n Row hit versus row miss
n Queueing delays in the memory controller and the interconnect
n …
q How much does the miss stall the processor?
n Is it overlapped with other latencies?
n Is the data immediately needed?
n …

153
Memory Level Parallelism (MLP)

isolated miss parallel miss

B
A
C
time

q Memory Level Parallelism (MLP) means generating and

servicing multiple memory accesses in parallel [Glew’98]
q Several techniques to improve MLP (e.g., out-of-order execution)

q MLP varies. Some misses are isolated and some parallel

How does this affect cache replacement?
Traditional Cache Replacement Policies
q Traditional cache replacement policies try to reduce miss
count

q Implicit assumption: Reducing miss count reduces memory-

related stall time

q Misses with varying cost/MLP breaks this assumption!

q Eliminating an isolated miss helps performance more than

eliminating a parallel miss
q Eliminating a higher-latency miss could help performance
more than eliminating a lower-latency miss

155
An Example

P4 P3 P2 P1 P1 P2 P3 P4 S1 S2 S3

Misses to blocks P1, P2, P3, P4 can be parallel

Misses to blocks S1, S2, and S3 are isolated

Two replacement algorithms:

1. Minimizes miss count (Belady’s OPT)
2. Reduces isolated miss (MLP-Aware)

For a fully associative cache containing 4 blocks

 Fewest Misses = Best Performance

S1Cache
P4 P3 P2 S3 P1
S2 P4 S1
P3 S2
P2 S3
P1 P4P4P3S1P2
P4S2P1
P3S3P4
P2 P3
S1 P2P4
S2P3 P2 S3

P4 P3 P2 P1 P1 P2 P3 P4 S1 S2 S3

Hit/Miss H H H M H H H H M M M
Misses=4
Time stall Stalls=4
Belady’s OPT replacement

Hit/Miss H M M M H M M M H H H
Saved
Time stall Misses=6
cycles
Stalls=2
MLP-Aware replacement
MLP-Aware Cache Replacement
n How do we incorporate MLP into replacement decisions?

n Qureshi et al., “A Case for MLP-Aware Cache

Replacement,” ISCA 2006.
q Reading for review

158
Other Recommended Cache Papers (I)

n Qureshi et al., “Adaptive Insertion Policies for High

Performance Caching,” ISCA 2007.

159
Other Recommended Cache Papers (II)

n Seshadri et al., “The Evicted-Address Filter: A Unified

Mechanism to Address Both Cache Pollution and
Thrashing,” PACT 2012.

160
Enabling Multiple Outstanding Misses
Handling Multiple Outstanding Accesses
n Question: If the processor can generate multiple cache
accesses, can the later accesses be handled while a
previous miss is outstanding?

n Goal: Enable cache access when there is a pending miss

n Goal: Enable multiple misses in parallel

q Memory-level parallelism (MLP)

n Solution: Non-blocking or lockup-free caches

q Kroft, “Lockup-Free Instruction Fetch/Prefetch Cache
Organization," ISCA 1981.

162
Handling Multiple Outstanding Accesses
n Idea: Keep track of the status/data of misses that are being
handled in Miss Status Handling Registers (MSHRs)

q A cache access checks MSHRs to see if a miss to the same

block is already pending.
n If pending, a new request is not generated
n If pending and the needed data available, data forwarded to later
load

q Requires buffering of outstanding miss requests

163
Miss Status Handling Register
n Also called “miss buffer”
n Keeps track of
q Outstanding cache misses
q Pending load/store accesses that refer to the missing cache
block
n Fields of a single MSHR entry
q Valid bit
q Cache block address (to match incoming accesses)
q Control/status bits (prefetch, issued to memory, which
subblocks have arrived, etc)
q Data for each subblock
q For each pending load/store
n Valid, type, data size, byte in block, destination register or store
buffer entry address
164
Miss Status Handling Register Entry

165
MSHR Operation
n On a cache miss:
q Search MSHRs for a pending access to the same block
n Found: Allocate a load/store entry in the same MSHR entry
n Not found: Allocate a new MSHR
n No free entry: stall

n When a subblock returns from the next level in memory

q Check which loads/stores waiting for it
n Forward data to the load/store unit
n Deallocate load/store entry in the MSHR entry
q Write subblock in cache or MSHR
q If last subblock, dellaocate MSHR (after writing the block in
cache)

166
Non-Blocking Cache Implementation
n When to access the MSHRs?
q In parallel with the cache?
q After cache access is complete?

n MSHRs need not be on the critical path of hit requests

q Which one below is the common case?
n Cache miss, MSHR hit
n Cache hit

167
Enabling High Bandwidth Memories
Multiple Instructions per Cycle
n Can generate multiple cache/memory accesses per cycle
n How do we ensure the cache/memory can handle multiple
accesses in the same clock cycle?

n Solutions:
q true multi-porting

q virtual multi-porting (time sharing a port)

q multiple cache copies

q banking (interleaving)

169
Handling Multiple Accesses per Cycle (I)
n True multiporting
q Each memory cell has multiple read or write ports
+ Truly concurrent accesses (no conflicts on read accesses)
-- Expensive in terms of latency, power, area
q What about read and write to the same location at the same

time?
n Peripheral logic needs to handle this

170
Peripheral Logic for True Multiporting

171
Peripheral Logic for True Multiporting

172
Handling Multiple Accesses per Cycle (II)
n Virtual multiporting
q Time-share a single port
q Each access needs to be (significantly) shorter than clock cycle
q Used in Alpha 21264
q Is this scalable?

173
Handling Multiple Accesses per Cycle (III)
n Multiple cache copies
q Stores update both caches
q Loads proceed in parallel
Port 1
n Used in Alpha 21164 Load Port 1
Cache
Copy 1 Data
n Scalability?
q Store operations cause a
Store
bottleneck
q Area proportional to “ports” Port 2
Cache
Port 2 Copy 2 Data
Load

174
Handling Multiple Accesses per Cycle (III)
n Banking (Interleaving)
q Bits in address determines which bank an address maps to
n Address space partitioned into separate banks
n Which bits to use for “bank address”?
+ No increase in data store area
-- Cannot satisfy multiple accesses Bank 0:
to the same bank Even
addresses
-- Crossbar interconnect in input/output

n Bank conflicts
q Two accesses are to the same bank Bank 1:
Odd
q How can these be reduced?
addresses
n Hardware? Software?

175
General Principle: Interleaving
n Interleaving (banking)
q Problem: a single monolithic memory array takes long to
access and does not enable multiple accesses in parallel

q Goal: Reduce the latency of memory array access and enable

multiple accesses in parallel

q Idea: Divide the array into multiple banks that can be

accessed independently (in the same cycle or in consecutive
cycles)
n Each bank is smaller than the entire memory storage
n Accesses to different banks can be overlapped

q A Key Issue: How do you map data to different banks? (i.e.,

how do you interleave data across banks?)
176
Further Readings on Caching and MLP
n Required: Qureshi et al., “A Case for MLP-Aware Cache
Replacement,” ISCA 2006.

n One Pager: Glew, “MLP Yes! ILP No!,” ASPLOS Wild and
Crazy Ideas Session, 1998.

n Mutlu et al., “Runahead Execution: An Effective Alternative

to Large Instruction Windows,” IEEE Micro 2003.

177
Multi-Core Issues in Caching
Caches in Multi-Core Systems
n Cache efficiency becomes even more important in a multi-
core/multi-threaded system
q Memory bandwidth is at premium
q Cache space is a limited resource

n How do we design the caches in a multi-core system?

n Many decisions
q Shared vs. private caches
q How to maximize performance of the entire system?
q How to provide QoS to different threads in a shared cache?
q Should cache management algorithms be aware of threads?
q How should space be allocated to threads in a shared cache?
179
Private vs. Shared Caches
n Private cache: Cache belongs to one core (a shared block can be in
multiple caches)
n Shared cache: Cache is shared by multiple cores

CORE 0 CORE 1 CORE 2 CORE 3 CORE 0 CORE 1 CORE 2 CORE 3

L2 L2 L2 L2
CACHE CACHE CACHE CACHE L2
CACHE

DRAM MEMORY CONTROLLER DRAM MEMORY CONTROLLER

180
Resource Sharing Concept and Advantages
n Idea: Instead of dedicating a hardware resource to a
hardware context, allow multiple contexts to use it
q Example resources: functional units, pipeline, caches, buses,
memory
n Why?

+ Resource sharing improves utilization/efficiency à throughput

q When a resource is left idle by one thread, another thread can
use it; no need to replicate shared data
+ Reduces communication latency
q For example, shared data kept in the same cache in
multithreaded processors
+ Compatible with the shared memory model
181
Resource Sharing Disadvantages
n Resource sharing results in contention for resources
q When the resource is not idle, another thread cannot use it
q If space is occupied by one thread, another thread needs to re-
occupy it

- Sometimes reduces each or some thread’s performance

- Thread performance can be worse than when it is run alone
- Eliminates performance isolation à inconsistent performance
across runs
- Thread performance depends on co-executing threads
- Uncontrolled (free-for-all) sharing degrades QoS
- Causes unfairness, starvation

Need to efficiently and fairly utilize shared resources

182
Private vs. Shared Caches
n Private cache: Cache belongs to one core (a shared block can be in
multiple caches)
n Shared cache: Cache is shared by multiple cores

CORE 0 CORE 1 CORE 2 CORE 3 CORE 0 CORE 1 CORE 2 CORE 3

L2 L2 L2 L2
CACHE CACHE CACHE CACHE L2
CACHE

DRAM MEMORY CONTROLLER DRAM MEMORY CONTROLLER

183
Shared Caches Between Cores
n Advantages:
q High effective capacity
q Dynamic partitioning of available cache space
n No fragmentation due to static partitioning
q Easier to maintain coherence (a cache block is in a single location)
q Shared data and locks do not ping pong between caches

n Disadvantages
q Slower access
q Cores incur conflict misses due to other cores’ accesses
n Misses due to inter-core interference
n Some cores can destroy the hit rate of other cores
q Guaranteeing a minimum level of service (or fairness) to each core is harder
(how much space, how much bandwidth?)

184
Shared Caches: How to Share?
n Free-for-all sharing
q Placement/replacement policies are the same as a single core
system (usually LRU or pseudo-LRU)
q Not thread/application aware
q An incoming block evicts a block regardless of which threads
the blocks belong to

n Problems
q Inefficient utilization of cache: LRU is not the best policy
q A cache-unfriendly application can destroy the performance of
a cache friendly application
q Not all applications benefit equally from the same amount of
cache: free-for-all might prioritize those that do not benefit
q Reduced performance, reduced fairness
185
Example: Utility Based Shared Cache Partitioning
n Goal: Maximize system throughput
n Observation: Not all threads/applications benefit equally from
caching à simple LRU replacement not good for system
throughput
n Idea: Allocate more cache space to applications that obtain the
most benefit from more space

n The high-level idea can be applied to other shared resources as

well.

n Qureshi and Patt, “Utility-Based Cache Partitioning: A Low-

Overhead, High-Performance, Runtime Mechanism to Partition
Shared Caches,” MICRO 2006.
n Suh et al., “A New Memory Monitoring Scheme for Memory-
Aware Scheduling and Partitioning,” HPCA 2002.
186
The Multi-Core System: A Shared Resource View
Shared Memory

Shared Shared
Memory Shared L3 Cache Memory
Shared Control Control
Interconnect
Core 1 Core 2 Core 3
Shared Shared Shared
Shared L3 Cache

Shared L3 Cache
Shared Memory

Shared Memory
L2 Cache L2 Cache L2 Cache

Core 4 Core 5 Core 6

Shared Shared Shared
L2 Cache L2 Cache L2 Cache

Core 7 Core 8 Core 9

Shared Shared Shared Shared
L2 Cache L2 Cache L2 Cache Storage
Shared Shared
Memory Shared L3 Cache Memory
Control Control

Shared Memory

187
Need for QoS and Shared Resource Mgmt.
n Why is unpredictable performance (or lack of QoS) bad?

n Makes programmer’s life difficult

q An optimized program can get low performance (and
performance varies widely depending on co-runners)

n Causes discomfort to user

q An important program can starve
q Examples from shared software resources

n Makes system management difficult

q How do we enforce a Service Level Agreement when hardware
resources are sharing is uncontrollable?
188
Resource Sharing vs. Partitioning
n Sharing improves throughput
q Better utilization of space

n Partitioning provides performance isolation (predictable

performance)
q Dedicated space

n Can we get the benefits of both?

n Idea: Design shared resources such that they are efficiently

utilized, controllable and partitionable
q No wasted resource + QoS mechanisms for threads

189
Shared Hardware Resources
n Memory subsystem (in both multithreaded and multi-core
systems)
q Non-private caches
q Interconnects
q Memory controllers, buses, banks

n I/O subsystem (in both multithreaded and multi-core

systems)
q I/O, DMA controllers
q Ethernet controllers

n Processor (in multithreaded systems)

q Pipeline resources
q L1 caches
190
Computer Architecture
Lecture 2: Fundamentals,
Memory Hierarchy, Caches

Prof. Onur Mutlu

ETH Zurich
Fall 2017
21 September 2017