1. CIS-550 Computer Architecture Lecture 1: Introduction and Basics
4/13/2018
CIS-550 Computer Architecture Lecture 1: Introduction and Basics
Dr. Muhammad Abid
DCIS, PIEAS
Spring 2016 1

2. Your Introduction Please
Your Name
Basic Degree
Name of University
Hometown

3. About ME Dr. Muhammad Abid PhD from Tsinghua University, P. R. China
Research Interests:
Big Data Analytics, Data Science
High Performance Computing
Room No: B-210
Visit time: Welcome at any time

4. Computer Architecture is boring

5. Computer Architecture is boring
Hope we will enjoy this course

6. Course Materials I follow Professor Onur Mutlu lectures:
4/13/2018
Course Materials
I follow Professor Onur Mutlu lectures:
Computer Architecture: A Quantitative Approach, 5th Edition, Hennessy &Patterson
Computer Organization and Design, 4th Edition, Hennessy &Patterson
Lectures/ Books, etc. are available at \\
Go to ‘Muhammad Abid Mughal Dr.’ folder 6

7. How Will You Be Evaluated?
4/13/2018
How Will You Be Evaluated?
Sessional 01: 15 marks
Sessional 02: 15 marks
Assignments + Readings: 10 marks
Surprise Quizzes: 10 marks
Final Exam: 50 marks 7

8. 4/13/2018
What Will You Learn
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.
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 8

9. Major High-Level Goals of This Course
4/13/2018
Major High-Level Goals of This Course
Understand the principles
Understand the precedents
Based on such understanding:
Enable you to evaluate tradeoffs of different designs and ideas
Enable you to develop principled designs
Enable you to develop novel, out-of-the-box designs
The focus is on:
Principles, precedents, and how to use them for new designs 9

10. Role of the (Computer) Architect
4/13/2018
Role of the (Computer) Architect
from Yale Patt’s lecture notes

11. Role of The (Computer) Architect
4/13/2018
Role of The (Computer) Architect
Look backward (to the past)
Understand tradeoffs and designs, upsides/downsides, past workloads. Analyze and evaluate the past.
Look forward (to the future)
Be the dreamer and create new designs. Listen to dreamers.
Push the state of the art. Evaluate new design choices.
Look up (towards problems in the computing stack)
Understand important problems and their nature.
Develop architectures and ideas to solve important problems.
Look down (towards device/circuit technology)
Understand the capabilities of the underlying technology.
Predict and adapt to the future of technology (you are designing for N years ahead). Enable the future technology. 11

12. Takeaways Being an architect is not easy
4/13/2018
Takeaways
Being an architect is not easy
You need to consider many things in designing a new system + have good intuition/insight into ideas/tradeoffs
But, it is fun and can be very technically rewarding
And, enables a great future
E.g., many scientific and everyday-life innovations would not have been possible without architectural innovation that enabled very high performance systems
E.g., your mobile phones
This course will teach you how to become a good computer architect
Art---the expression or application of human creative skill and imagination
Science---Science is the concerted human effort to understand, or to understand better, the history of the natural world and how the natural world works, with observable physical evidence as the basis of that understanding. It is done through observation of natural phenomena, and/or through experimentation that tries to simulate natural processes under controlled conditions 12

13. So, I Hope You Are Here for This
4/13/2018
So, I Hope You Are Here for This
“C” as a model of computation
Programming Model
Programmer’s view of how
a computer system works
How does an assembly program end up executing as digital logic?
What happens in-between?
How is a computer designed using logic gates and wires to satisfy specific goals?
Architect/microarchitect’s view:
How to design a computer that
meets system design goals.
Choices critically affect both
the SW programmer and
the HW designer
How is the HW/SW interface designed
HW designer’s view of how
a computer system works
Digital Logic
Digital logic as a
model of computation 13 13

14. Levels of Transformation
4/13/2018
Levels of Transformation
“The purpose of computing is insight” (Richard Hamming)
We gain and generate insight by solving problems
How do we ensure problems are solved by electrons?
Problem
Algorithm
Program/Lang
Runtime System
(VM, OS)
ISA(Architecture)
ISA is the interface between hardware and software… It is a contract that the hardware promises to satisfy.
Algorithm: step by step procedure where each step is effectively computable (by a computer), is definite (precisely defined) – “do until fast” is not definite, and terminates
Hamming distance: number of locations in which the corresponding symbols of two equal-length strings is different
Hamming, Richard W. (1950), "Error detecting and error correcting codes", Bell System Technical Journal 29 (2): 147–160
Hamming codes
Micro-arch
Logic
Circuits
Electrons 14 14

15. The Power of Abstraction
4/13/2018
The Power of Abstraction
Levels of transformation create abstractions
Abstraction: A higher level only needs to know about the interface to the lower level, not how the lower level is implemented
E.g., high-level language programmer does not really need to know what the ISA is and how a computer executes instructions
Abstraction improves productivity
No need to worry about decisions made in underlying levels
E.g., programming in Java vs. C vs. assembly vs. binary vs. by specifying control signals of each transistor every cycle
Then, why would you want to know what goes on underneath or above? 15

16. Crossing the Abstraction Layers
4/13/2018
Crossing the Abstraction Layers
As long as everything goes well, not knowing what happens in the underlying level (or above) is not a problem.
What if
The program you wrote is running slow?
The program you wrote does not run correctly?
The program you wrote consumes too much energy?
The hardware you designed is too hard to program?
The hardware you designed is too slow because it does not provide the right primitives to the software?
You want to design a much more efficient and higher performance system? 16

17. Crossing the Abstraction Layers
4/13/2018
Crossing the Abstraction Layers
Two key goals of this course are
to understand how a processor works underneath the software layer and how decisions made in hardware affect the software/programmer
to enable you to be comfortable in making design and optimization decisions that cross the boundaries of different layers and system components 17

18. An Example: Multi-Core Systems
4/13/2018
An Example: Multi-Core Systems
Multi-Core
Chip
CORE 0
L2 CACHE 0
L2 CACHE 1
CORE 1
SHARED L3 CACHE
DRAM INTERFACE
DRAM MEMORY CONTROLLER
DRAM BANKS
CORE 2
L2 CACHE 2
L2 CACHE 3
CORE 3
*Die photo credit: AMD Barcelona 18 18

19. Unexpected Slowdowns in Multi-Core
4/13/2018
Unexpected Slowdowns in Multi-Core
High priority
Memory Performance Hog
Low priority
What kind of performance do we expect when we run two applications on a multi-core system? To answer this question, we performed an experiment. We took two applications we cared about, ran them together on different cores in a dual-core system, and measured their slowdown compared to when each is run alone on the same system. This graph shows the slowdown each app experienced. (DATA explanation…)
Why do we get such a large disparity in the slowdowns?
Is it the priorities? No. We went back and gave high priority to gcc and low priority to matlab. The slowdowns did not change at all. Neither the software or the hardware enforced the priorities.
Is it the contention in the disk? We checked for this possibility, but found that these applications did not have any disk accesses in the steady state. They both fit in the physical memory and therefore did not interfere in the disk.
What is it then? Why do we get such large disparity in slowdowns in a dual core system?
I will call such an application a “memory performance hog”
Now, let me tell you why this disparity in slowdowns happens.
Is it that there are other applications or the OS interfering with gcc, stealing its time quantums? No.
(Core 0)
(Core 1)
Moscibroda and Mutlu, “Memory performance attacks: Denial of memory service
in multi-core systems,” USENIX Security 2007. 19 19

20. 4/13/2018
A Question or Two
Can you figure out why there is a disparity in slowdowns if you do not know how the system executes the programs?
Can you fix the problem without knowing what is happening “underneath”? 20

21. Why the Disparity in Slowdowns?
4/13/2018
Why the Disparity in Slowdowns?
Multi-Core
Chip
CORE 1
matlab
CORE 2
gcc L2
CACHE L2
CACHE
unfairness
INTERCONNECT
Shared DRAM
Memory System
DRAM MEMORY CONTROLLER
-In a multi-core chip, different cores share some hardware resources. In particular, they share the DRAM memory system. The shared memory system consists of this and that.
When we run matlab on one core, and gcc on another core, both cores generate memory requests to access the DRAM banks. When these requests arrive at the DRAM controller, the controller favors matlab’s requests over gcc’s requests. As a result, matlab can make progress and continues generating memory requests. These requests are again favored by the DRAM controller over gcc’s requests. Therefore, gcc starves waiting for its requests to be serviced in DRAM whereas matlab makes very quick progress as if it were running alone.
Why does this happen? This is because the algorithms employed by the DRAM controller are unfair.
But, why are these algorithms unfair? Why do they unfairly prioritize matlab accesses?
To understand this, we need to understand how a DRAM bank operates.
Almost all systems today contain multi-core chips
Multi-core systems consist of multiple on-chip cores and caches
Cores share the DRAM memory system
DRAM memory system consists of
DRAM banks that store data (multiple banks to allow parallel accesses)
DRAM memory controller that mediates between cores and DRAM memory
It schedules memory operations generated by cores to DRAM
This talk is about exploiting the unfair algorithms in the memory controllers to perform denial of service to running threads
To understand how this happens, we need to know about how each DRAM bank operates
DRAM
Bank 0
DRAM
Bank 1
DRAM
Bank 2
DRAM
Bank 3 21 21

22. DRAM Bank Operation Access Address: (Row 0, Column 0) Columns
4/13/2018
DRAM Bank Operation
Access Address:
(Row 0, Column 0)
Columns
(Row 0, Column 1)
(Row 0, Column 85)
(Row 1, Column 0)
Row address 0
Row address 1
Row decoder
Rows
Row 0
Empty
Row 1
Row Buffer
CONFLICT !
HIT
HIT
Column address 0
Column address 1
Column address 85
Column address 0
Column mux
Data 22

23. 4/13/2018
DRAM Controllers
A row-conflict memory access takes significantly longer than a row-hit access
Current controllers take advantage of the row buffer
Commonly used scheduling policy:
(1) Row-hit first: Service row-hit memory accesses first
(2) Oldest-first: Then service older accesses first
This scheduling policy aims to maximize DRAM throughput 23 23

24. The Problem Multiple applications share the DRAM controller
4/13/2018
The Problem
Multiple applications share the DRAM controller
DRAM controllers designed to maximize DRAM data throughput
DRAM scheduling policies are unfair to some applications
Row-hit first: unfairly prioritizes apps with high row buffer locality
Threads that keep on accessing the same row
Oldest-first: unfairly prioritizes memory-intensive applications
DRAM controller vulnerable to denial of service attacks
Can write programs to exploit unfairness 24 24

25. A Memory Performance Hog
4/13/2018
A Memory Performance Hog
// initialize large arrays A, B
for (j=0; j<N; j++) {
index = j*linesize;
A[index] = B[index]; … }
// initialize large arrays A, B
for (j=0; j<N; j++) {
index = rand();
A[index] = B[index]; … }
streaming
random
STREAM
RANDOM
Sequential memory access
Very high row buffer locality (96% hit rate)
Memory intensive
Random memory access
Very low row buffer locality (3% hit rate)
Similarly memory intensive
Streaming through memory by performing operations on two 1D arrays.
Sequential memory access
Each access is a cache miss (elements of array larger than a cache line size)  hence, very memory intensive
Link to the real code…
Moscibroda and Mutlu, “Memory Performance Attacks,” USENIX Security 2007. 25 25

26. What Does the Memory Hog Do?
4/13/2018
What Does the Memory Hog Do?
Row decoder
T0: Row 0
T0: Row 0
T0: Row 0
T0: Row 0
T0: Row 0
T0: Row 0
T0: Row 0
T1: Row 5
T1: Row 111
T0: Row 0
T1: Row 16
T0: Row 0
Memory Request Buffer
Row 0
Row 0
Row Buffer
Pictorially demonstrate how stream denies memory service to rdarray
Stream continuously accesses columns in row 0 in a streaming manner (streams through a row after opening it)
In other words almost all its requests are row-hits
RDarray’s requests are row-conflicts (no locality)
The DRAM controller reorders streams requests to the open row over other requests (even older ones) to maximize DRAM throughput
Hence, rdarray’s requests do not get serviced as long as stream is issuing requests at a fast-enough rate
In this example, the red thread’s request to another row will not get serviced until stream stops issuing a request to row 0
With those parameters, 128 requests of stream would be serviced before 1 from rdarray
As row-buffer size increases, which is the industry trend, this problem will become more severe
This is not the worst case, but it is easy to construct and understand
Stream falls off the row buffer at some point
I leave it to the listeners to construct a case worse than this (it is possible)
Row size: 8KB, cache block size: 64B
128 (8KB/64B) requests of T0 serviced before T1
Column mux
T0: STREAM
T1: RANDOM
Data
Moscibroda and Mutlu, “Memory Performance Attacks,” USENIX Security 2007. 26 26

27. Now That We Know What Happens Underneath
4/13/2018
Now That We Know What Happens Underneath
How would you solve the problem?
What is the right place to solve the problem?
Programmer?
System software?
Compiler?
Hardware (Memory controller)?
Hardware (DRAM)?
Circuits?
Two other goals of this course:
Enable you to think critically
Enable you to think broadly
Problem
Algorithm
Program/Language
Runtime System
(VM, OS, MM)
ISA (Architecture)
Microarchitecture
Logic
Circuits
Electrons 27

28. A Note on Hardware vs. Software
4/13/2018
A Note on Hardware vs. Software
This course is classified under “Computer Hardware”
However, you will be much more capable if you master both hardware and software (and the interface between them)
Can develop better software if you understand the underlying hardware
Can design better hardware if you understand what software it will execute
Can design a better computing system if you understand both
This course covers the HW/SW interface and microarchitecture
We will focus on tradeoffs and how they affect software 28

29. Course Topics ISA Pipelining caches virtual memory in-order processor
4/13/2018
Course Topics
ISA
Pipelining
caches
virtual memory
in-order processor
out-of-order processor
Static vs Dynamic Scheduling
ILP
Speculative execution
Thread-level parallelism
Multicore Processor/ Multiprocessor
Cache coherence protocols
GPUs and so on 29

30. What Do I Expect From You?
4/13/2018
What Do I Expect From You?
Required background: digital logic, RTL implementation, Verilog, assembly
Learn the material thoroughly
attend lectures, do the readings, do the homeworks
Do the work & work hard
Ask questions, take notes, participate
Perform the assigned readings
Come to class on time 30

31. Required Readings for This Week
4/13/2018
Required Readings for This Week
Patt, “Requirements, Bottlenecks, and Good Fortune: Agents for Microprocessor Evolution,” Proceedings of the IEEE 2001. 31

32. Computer Architecture in Levels of Transformation
4/13/2018
Computer Architecture in Levels of Transformation
Read: Patt, “Requirements, Bottlenecks, and Good Fortune: Agents for Microprocessor Evolution,” Proceedings of the IEEE 2001.
Problem
Algorithm
Program/Language
Runtime System
(VM, OS, MM)
ISA (Architecture)
Microarchitecture
Logic
Circuits
Electrons 32

33. Levels of Transformation, Revisited
4/13/2018
Levels of Transformation, Revisited
A user-centric view: computer designed for users
The entire stack should be optimized for user
Problem
Algorithm
Program/Language
User
Runtime System
(VM, OS, MM)
ISA
Microarchitecture
ISA is the interface between hardware and software… It is a contract that the hardware promises to satisfy.
Logic
Circuits
Electrons 33 33

34. Recap: Some Goals of this course
4/13/2018
Recap: Some Goals of this course
Teach/enable/empower you to:
Understand how a computing platform (processor + memory + interconnect) works
Implement a simple platform (with not so simple parts), with a focus on the processor and memory
Understand how decisions made in hardware affect the software/programmer as well as hardware designer
Think critically (in solving problems)
Think broadly across the levels of transformation
Understand how to analyze and make tradeoffs in design 34

35. Review: Major High-Level Goals of This Course
4/13/2018
Review: Major High-Level Goals of This Course
Understand the principles
Understand the precedents
Based on such understanding:
Enable you to evaluate tradeoffs of different designs and ideas
Enable you to develop principled designs
Enable you to develop novel, out-of-the-box designs
The focus is on:
Principles, precedents, and how to use them for new designs
In Computer Architecture 35