CS 213: Introduction to Computer Systems - Understanding the Reality Beyond Abstractions, Slides of Software Engineering

Download CS 213: Introduction to Computer Systems - Understanding the Reality Beyond Abstractions and more Slides Software Engineering in PDF only on Docsity!

CS 213

Introduction to

Computer Systems

Randal E. Bryant

August 25, 1998

Topics:

• Theme
• Five great realities of computer systems
• How this fits within CS curriculum

Course Theme

Abstraction is good, but don’t forget reality!

Courses to date 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
  • Compilers, Operating Systems, Networks, Computer Architecture

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

• Need to understand which abstractions apply in which contexts!
• Important issues for compiler writers and serious application programmers

Great Reality

You’ve got to know assembly

Chances are, you’ll never write program in assembly

• Compilers are much better at this 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

Memory Referencing Bug Example

main () { long int a[2]; double d = 3.14; a[2] = 1073741824; / Out of bounds reference / printf("d = %.15g\n", d); exit(0); }

main () { long int a[2]; double d = 3.14; a[2] = 1073741824; / Out of bounds reference / printf("d = %.15g\n", d); exit(0); }

Alpha MIPS Sun -g 5.30498947741318e-315 3.1399998664856 3. -O 3.14 3.14 3.

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 system and compiler dependent
• Action at a distance
  • Corrupted object logically unrelated to one being accessed
  • Effect of bug may occur long after it occurs

How can I with this?

• Program in Java, Lisp, or ML
• Understand what possible interactions may occur
• Use or develop tools to detect referencing errors
  • E.g., Purify

0

20

40

60

80

100

120

140

160

matrix size (n)

ijk ikj jik jki kij kji

Matmult Performance (Alpha 21164)

Too big for L1 Cache Too big for L2 Cache

Blocked matmult perf (Alpha 21164)

0

20

40

60

80

100

120

140

160

50 75 100 125 150 175 200 225 250 275 300 325 350 375 400 425 450 475 500 matrix size (n)

bijk bikj ijk ikj

Tuning of BDD Packages

• Bwolen Yang, in cooperation with researchers from Colorado, Synopsys, CMU, and T.U. Eindhoven.

Application

• Symbolic model checking
• Analyze systems consisting of interacting state machines
  • Shared memory parallel computer systems
  • Air traffic collision avoidance systems
• Regularly deal with systems having 10^20 states or more
  • Cannot possibly represent state space as explicit state graph
  • Instead represent symbolically with “Binary Decision Diagrams”

Procedure

• Generated set of benchmark traces
  • Operation sequences that could be run using different packages and under varying conditions
• Identify strengths and weaknesses of 6 different packages and tune accordingly

Effect of Optimization

Compare pre- vs. post-optimized results for 96 runs

• 6 different BDD packages
• 16 benchmark traces each
• Limit each run to maximum of 8 CPU hours and 900 MB
• Measure speedup = Told / Tnew or:
  • New: Failed before but now succeeds
  • Fail: Fail both times
  • Bad: Succeeded before, but now fails

Results

• Overall speedup = 4.
  • Total time: 6.4 days --> 1.5 days
  • 6 cases achieve > 100X speedup
• 13 New
• 6 Fail
• 1 Bad

Optimization Results Summary

• speedup = Told / Tnew
• New: » Failed before but now succeeds
• Fail: » Fail both times
• Bad: » Succeeded before, but now fails

Time Comparison

10

100

1000

10000

100000

1000000

10 100 1000 10000 100000 current results (sec)

initial results (sec)

new failed bad rest

100x 10x 1x

n/a

n/a

Great Reality

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