- "C" as a model of computation.
- Programmer's view of a computer system works.
HardWare designer's view of a computer system works.
Digital logic as a model of computation.
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 do we ensure problems are solved by electrons?
- program -> Algorithm -> Program/Language -> Runtime System(VM, OS, MM) -> ISA(Instruction Set Architecture) -> Microarchitecture -> Circuits -> Electrons
- ! ISA which is that interface between the hardware and software.
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 waht the ISA is and how a computer executes instructions.
-
Abstraction improves productivity.
- No need to worry about decisions made in underlying levvels.
- E.g., programming in Java vs. C vs. assembly vs. binary vs. by specifying control signals of each transistor every cycle.
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 correctyl?
- The program you wrote consumes too much energy?
-
What if
- 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?
One goal of this course is to understand how a processor works underneath the software layer and how decisions made in hardware affect the software/programmer
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
- Row-hit first: Service row-hit memory accesses first
- Oldest-first: Then service older accesses first.
This scheduling policy aims to maximize DRAM throughput.
The problem
Multiple threads share the DRAM controller
DRAM controllers designed to maxmize DRAM throughput
-
DRAM scheduling policies are thread-unfair
- Row-hit first: unfairly prioritizes threads with high row buffer locality
- Threads that keep on accessing the same row.
- Oldest-first: unfairly prioritizes memory-intensive threads
- Row-hit first: unfairly prioritizes threads with high row buffer locality
-
DRAM controller vulnerable to denial of service attacks
- Can write programs to exploit unfairness.
A Memory Performance Hog
STREAM
// initialize large aarrays A, B
for (j = 0; j < N; j++) {
index = j * linesizze; // streaming
A[index] = B[index];
...
}
- Sequential memory access
- Very high row buffer locality(96% hit rate)
- Memory intensive
RANDOM
// initialize large arrays A, B
for (j = 0, j < N; j++) {
index = rand(); // random
A[index] = B[index];
...
}
- Random memory access
- Very low row buffer locality (3% hit rate)
- Similarly memory intensive
Goals
- Teach/enable/empower you to:
- Understand how a procesor works
- Implement a simple processor (with not so simple parts)
- 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.