15-213
“The Class That Gives CMU Its Zip!”
Introduction to
Computer Systems
Randal E. Bryant
January 15, 2008
Topics:



class01a.ppt
Theme
Five great realities of computer systems
How this fits within CS curriculum
15-213 S ‘08
Course Theme

Abstraction is good, but don’t forget reality!
Most CS courses emphasize abstraction


Abstract data types
Asymptotic analysis
These abstractions have limits


Especially in the presence of bugs
Need to understand underlying implementations
Useful outcomes

Become more effective programmers
 Able to find and eliminate bugs efficiently
 Able to tune program performance

Prepare for later “systems” classes in CS & ECE
 Compilers, Operating Systems, Networks, Computer
–2–
Architecture, Embedded Systems
15-213, S ‘08
Great Reality #1
Int’s are not Integers, Float’s are not Reals
Examples

Is x2 ≥ 0?
 Float’s:
Yes!
 Int’s:
» 40000 * 40000 --> 1600000000
» 50000 * 50000 --> ??

Is (x + y) + z = x + (y + z)?
 Unsigned & Signed Int’s:
Yes!
 Float’s:
» (1e20 + -1e20) + 3.14 --> 3.14
» 1e20 + (-1e20 + 3.14) --> ??
–3–
15-213, S ‘08
Computer Arithmetic
Does not generate random values

Arithmetic operations have important mathematical
properties
Cannot assume “usual” properties


Due to finiteness of representations
Integer operations satisfy “ring” properties
 Commutativity, associativity, distributivity

Floating point operations satisfy “ordering” properties
 Monotonicity, values of signs
Observation


–4–
Need to understand which abstractions apply in which
contexts
Important issues for compiler writers and serious application
programmers
15-213, S ‘08
Great Reality #2
You’ve got to know assembly
Chances are, you’ll never write program in assembly

Compilers are much better & more patient than you are
Understanding assembly key to machine-level
execution model

Behavior of programs in presence of bugs
 High-level language model breaks down

Tuning program performance
 Understanding sources of program inefficiency

Implementing system software
 Compiler has machine code as target
 Operating systems must manage process state

–5–
Creating / fighting malware
 x86 assembly is the language of choice!
15-213, S ‘08
Assembly Code Example
Time Stamp Counter



Special 64-bit register in Intel-compatible machines
Incremented every clock cycle
Read with rdtsc instruction
Application

Measure time required by procedure
 In units of clock cycles
double t;
start_counter();
P();
t = get_counter();
printf("P required %f clock cycles\n", t);
–6–
15-213, S ‘08
Code to Read Counter


Write small amount of assembly code using GCC’s asm
facility
Inserts assembly code into machine code generated by
compiler
static unsigned cyc_hi = 0;
static unsigned cyc_lo = 0;
/* Set *hi and *lo to the high and low order bits
of the cycle counter.
*/
void access_counter(unsigned *hi, unsigned *lo)
{
asm("rdtsc; movl %%edx,%0; movl %%eax,%1"
: "=r" (*hi), "=r" (*lo)
:
: "%edx", "%eax");
}
–7–
15-213, S ‘08
Great Reality #3
Memory Matters:
Random Access Memory is an
un-physical abstraction
Memory is not unbounded


It must be allocated and managed
Many applications are memory dominated
Memory referencing bugs especially pernicious

Effects are distant in both time and space
Memory performance is not uniform


–8–
Cache and virtual memory effects can greatly affect program
performance
Adapting program to characteristics of memory system can
lead to major speed improvements
15-213, S ‘08
Memory Referencing Bug Example
double fun(int i)
{
volatile double d[1] = {3.14};
volatile long int a[2];
a[i] = 1073741824; /* Possibly out of bounds */
return d[0];
}
fun(0)
fun(1)
fun(2)
fun(3)
fun(4)
–9–
–>
–>
–>
–>
–>
3.14
3.14
3.1399998664856
2.00000061035156
3.14, then segmentation fault
15-213, S ‘08
Referencing Bug Explanation


– 10 –
Saved State
4
d7 … d4
3
d3 … d0
2
a[1]
1
a[0]
0
Location accessed
by fun(i)
C does not implement bounds checking
Out of range write can affect other parts of program state
15-213, S ‘08
Memory Referencing Errors
C and C++ do not provide any memory protection



Out of bounds array references
Invalid pointer values
Abuses of malloc/free
Can lead to nasty bugs


Whether or not bug has any effect depends on system and
compiler
Action at a distance
 Corrupted object logically unrelated to one being accessed
 Effect of bug may be first observed long after it is generated
How can I deal with this?


– 11 –

Program in Java or ML
Understand what possible interactions may occur
Use or develop tools to detect referencing errors
15-213, S ‘08
Memory System Performance
Example
void copyij(int
int
{
int i,j;
for (i = 0; i
for (j = 0;
dst[i][j]
}
src[2048][2048],
dst[2048][2048])
< 2048; i++)
j < 2048; j++)
= src[i][j];
59,393,288 clock cycles
void copyji(int
int
{
int i,j;
for (j = 0; j
for (i = 0;
dst[i][j]
}

< 2048; j++)
i < 2048; i++)
= src[i][j];
1,277,877,876 clock cycles
21.5 times slower!

src[2048][2048],
dst[2048][2048])
(Measured on 2GHz
Intel Pentium 4)
Hierarchical memory organization
Performance depends on access patterns
 Including how step through multi-dimensional array
– 12 –
15-213, S ‘08
The Memory Mountain
Read throughput (MB/s)
1200
Pentium III Xeon
550 MHz
16 KB on-chip L1 d-cache
16 KB on-chip L1 i-cache
512 KB off-chip unified
L2 cache
copyij
1000
L1
800
copyji
600
400
xe
L2
200
– 13 –
2k
8k
32k
128k
512k
2m
8m
s15
s13
s9
s11
Stride (words)
Mem
s7
s5
s3
s1
0
Working set size (bytes)
15-213, S ‘08
Great Reality #4
There’s more to performance than asymptotic
complexity
Constant factors matter too!


Easily see 10:1 performance range depending on how code
written
Must optimize at multiple levels: algorithm, data
representations, procedures, and loops
Must understand system to optimize performance



– 14 –
How programs compiled and executed
How to measure program performance and identify
bottlenecks
How to improve performance without destroying code
modularity and generality
15-213, S ‘08
Code Performance Example
/* Compute product of array elements */
double product(double d[], int n)
{
double result = 1;
int i;
for (i = 0; i < n; i++)
result = result * d[i];
return result;
}
Multiply all elements of array
 Performance on class machines: ~7.0 clock cycles
per element

 Latency of floating-point multiplier
– 15 –
15-213, S ‘08
Loop Unrollings
/* Unroll by 2. Assume n is even */
double product_u2(double d[], int n)
{
double result = 1;
int i;
for (i = 0; i < n; i+=2)
result = (result * d[i]) * d[i+1];
return result;
}

/* Unroll by 2. Assume n is even */
double product_u2r(double d[], int n)
{
double result = 1;
int i;
for (i = 0; i < n; i+=2)
result = result * (d[i] * d[i+1]);
return result;
}
Do two loop elements per iteration
 Reduces overhead

Cycles per element:
 u2: 7.0
 u2r: 3.6
– 16 –
15-213, S ‘08
1 d0
*
u2: Serial Computation
d1
*
Computation (length=12)
d2
*
((((((((((((1 * d[0]) *
d[1]) * d[2]) * d[3]) *
d[4]) * d[5]) * d[6]) *
d[7]) * d[8]) * d[9]) *
d[10]) * d[11])
d3
*
d4
*
d5
*
Performance
d6
*
d7
*
N
elements, D cycles/operation
 N*D cycles
d8
*
result = (result * d[i]) * d[i+1];
d9
*
d10
*
– 17 –
d11
*
15-213, S ‘08
u2r: Reassociated Computation
Performance
N
elements, D cycles/operation
 (N/2+1)*D cycles
d0 d1
1
* d2 d3
*
* d4 d5
*
result = result * (d[i] * d[i+1]);
* d6 d7
*
* d8 d9
*
* d10 d11
*
*
*
– 18 –
15-213, S ‘08
Great Reality #5
Computers do more than execute programs
They need to get data in and out

I/O system critical to program reliability and performance
They communicate with each other over networks

Many system-level issues arise in presence of network
 Concurrent operations by autonomous processes
 Coping with unreliable media
 Cross platform compatibility
 Complex performance issues
– 19 –
15-213, S ‘08
Role within Curriculum
CS 412
OS Practicum
CS 415
Databases
CS 441
Networks
Network
Protocols
CS 410
Operating
Systems
CS 411
Compilers
Processes Machine Code
Mem. Mgmt
Data Reps.
Memory Model
CS 213
Systems
CS 462
Graphics
ECE 447
Architecture
Arithmetic
Exec. Model
Memory System
ECE 349
Embedded
Systems
Foundation of Computer
Systems

CS 123
C Programming
– 20 –
Underlying principles for
hardware, software, and
networking
15-213, S ‘08
Course Perspective
Most Systems Courses are Builder-Centric

Computer Architecture
 Design pipelined processor in Verilog

Operating Systems
 Implement large portions of operating system

Compilers
 Write compiler for simple language

Networking
 Implement and simulate network protocols
– 21 –
15-213, S ‘08
Course Perspective (Cont.)
Our Course is Programmer-Centric


Purpose is to show how by knowing more about the
underlying system, one can be more effective as a
programmer
Enable you to
 Write programs that are more reliable and efficient
 Incorporate features that require hooks into OS
» E.g., concurrency, signal handlers

Not just a course for dedicated hackers
 We bring out the hidden hacker in everyone

– 22 –
Cover material in this course that you won’t see elsewhere
15-213, S ‘08