Week 1.a
CS3650
01/08 2024
https://naizhengtan.github.io/24spring/

0. Lecture policies
1. Introduction and goals
2. What is a computer?
3. What is an operating system?
4. Why study systems?
5. How will we study systems?
6. Mechanics and admin
------------------------

0. in-class policies

  -- no laptop (context switch & interrupt)
  -- chocolate & willpower & active learning
  -- lottery

1. Introduction and goals

  -- introduce staff

  --Goals

    a. think as a systems person by learning how systems work

     -- a systems person
     [what is a systems person? see handout.
      also check out: https://www.usenix.org/system/files/1311_05-08_mickens.pdf ]

    b. learn abstractions and concepts in operating systems
    which are useful beyond OSes

    c. learn a set of skills and tools that are useful for
    developing systems (such as vim/emacs, gdb, shell)

    d. "no pain no gain". this course is supposed to be heavy-loaded

  --Non-goals

    a. not a programming class
       (though you will learn C)

    b. not a teamwork class
       --face challenges by your own
       --go deep instead of wide

  --Assumptions

    a. know how to program: have used some programming languages
    (e.g., Python, Java)

    b. understand basic algorithms and data structures

    c. feel comfortable with C and Linux (you will get a sense from lab1)

    d. willing to learn (by yourself); willing to challenge yourself

    [Ask questions:
      --how many have used Linux? C? git? vim/emacs?
      --how many heard of registers (as in CPU)? cr3?
      --have you heard of int? float? do you know how they look like on raw memory?
    ]

  -- this course:
     computer organization + OS

     ^
     |
     +---------+
     |impl     | => CS6640
     |details  |
     +---------+-------- +
     |core OS  |advanced | => CS5600
     |concepts |topics   |
     +---------------------->
        ||
        \/
      CS3650

2. What is a computer?

  [draw picture of hardware
    (memory, CPU, disk, NIC, GPU), OS, user-level programs]

  A. Hardware
   show what hardware looks like
    [offer real hardware for students to touch]

  B. software: everything is 0s and 1s

  - some backgrounds:
    -- bits and bytes
    -- binary, decimal, and hex numbers

    -- hexadecimal numbers (or hex numbers)
      -- integer with base of 16
      -- an example: 0x123456789abcdef
      -- other examples: 0xdeadbeef, 0xbebeebee

    -- binary vs. hex
       -- 0000 == 0x0
       -- 1111 == 0xf

    -- why "0x" for hex?
      --short answer: a convention, an arbitrary choice
      [see: https://stackoverflow.com/questions/2670639/why-are-hexadecimal-numbers-prefixed-with-0x]

  - a program = instructions + data

    Examples:
    -- how about text file?
       [take a look at hello.txt]
    -- how about pictures?
       [take a look at a png picture]

3. What is an operating system?

  [OS includes OS services: processes, virtual memory, file system
  (file contents, directories and file names), security, networking,
  inter-process communication, time, terminals, etc.]

  --Purpose of OS: provide services to user-level programs

  --Definition: An operating system creates, for processes, a machine
  that is easier to program than the raw hardware would be.

  --this software is classically described as doing two things:

  a. managing the resources of the machine 

    --example: scheduling: give every process some of the CPU

    --example: virtual memory: give every process some physical memory

    --resource management means that one bad program doesn't
    screw up another. OS does:
        --multiplexing
        --sharing
        --isolation, protection

  b. abstracting the hardware 

    --hide details of hardware (OS gets dirty; programmers don't)
      --hardware is nasty to program directly!
      --consider what is involved in getting things to the disk
        this provides essential convenience and portability.

    --you really don't want applications to have to program
    the bare hardware

      --would lead to lots of repeated code

      --unclear how to run more than one application at once,
      particularly more than one that are mutually distrustful.

      --hide details:

        --"All problems in computer science can be solved by another
        level of indirection [abstraction]."  --Butler Lampson

        --why? abstraction allows the operating system to make
        changes to the underlying hardware without impacting applications.

        --example: switching between WiFi and cellular networks.

        --example: switching between heterogeneous CPU/GPU cores
        for saving energy.

4. Why study computer systems?

    "My Future Is In Deep Learning!"

      --TensorFlow is published on OSDI'16
      --10x speedup by understanding the GPUs
      --vLLM outperforms vanilla LLMs by by 2-4x
        [paper: https://arxiv.org/pdf/2309.06180.pdf]
      --PowerInfer allows 11x faster LLM inference on RTX 4090
        [https://arxiv.org/pdf/2312.12456.pdf]

    "Doing systems means being at ease with the machine" --Brad Karp

    a. It's essential to know "how things work."

    --doesn't matter what types of programs you work on,
    knowing what is happening under the hood is essential to
    debugging and improving performance.
        --Java programmers, understanding GC will be helpful.
          (an example of two sigma)
        --phone applications, understanding what is going on in the OS
          helpful with improving performance and battery life.
        -- DNNs (deep neural networks), some of the concerns from
          OSes impact how you batch things, how you schedule, etc.

    b. The ideas are everywhere: resource management and abstraction,
    for example.

    c. There are design trade-offs that are fundamental

      --code must be efficient (so low-level?) ...
      --...but abstract/portable (so high-level?)

      --code must be powerful (so many features?)
      --...but simple (thus a few composable building blocks?)

      --another trade-off: between security and convenience

    d. new challenges that will affect you

      --OS security and privacy remains a problem area.

      --multicore and manycore: yes, the operating systems run,
      but there's an argument that perhaps the abstractions
      should be different
      (interaction between caches and address space abstractions)

    e. Skills building

      --have a holistic view of a system
      --have the confidence to address hard problems

[skipped]
5. How will we study (operating) systems?

    a. Learn how stuff works
      --sometimes through case studies

    b. Learn specific techniques
      --time-tested solutions to hard problems
      --avoid "hacks"
          --examples: concurrent programming

    c. Learn how to approach problems
      --fundamental issues
      --concept of a design space
        --design choices vs. implementation details

    d. this class:
      --focus on "science" part (as in "computer science") for systems
      --lots of discussion of OS/HW boundary and process/OS boundary
      (interfaces). Less attention to detailed implementation of OS.
      --not a priority: details of deployed OSes (e.g., details of
        Linux), but we may sometimes use these as examples

6. Mechanics and admin

    a. communication

      us-to-you:
        -- for message broadcast:
          --homepage, announcements: check regularly
          --piazza
        --office hours
        --your NEU email (seldom)

      you-to-us:
        --piazza: questions that are not sensitive
          **No valid C code on Piazza**
        --staff email list for admin/sensitive things
        --office hours

    b. components of the course:
      --lectures
      --assignments
      --labs
      --exams
      --reading

    c. labs:

      --key piece of the course

      --labs could/should actually be fun 

      --often: not much code to write (relatively speaking),
          but lots to learn!

      --"Start early"
        "When is early?"
        "Earlier than you think"

      --Regardless, you need to allocate time. 

      --I'm expecting you to feel challenged by the labs. The concept
      of "no pain, no gain" applies to learning. let's dive into
      that...

        --The building of systems cannot be learned by lecture or
        reading a textbook, nor by reading others' code.

        --Indeed, programming is where the real learning happens,
        that's the whole point

        --Independent effort is essential

        --Debugging is hard and time-consuming, but it's an
        essential skill

        --Only by producing working solution code yourself (without
        looking at others’ solution code) will you learn to build
        systems that solve problems you haven't seen before
          (the blind alleys may feel like wasted time, but they
          are teaching you how to avoid problems in the future,
          how to be independent)

        --Don't think of labs as having a grade.

          (people sometimes think that they need to get all the points,
          they get frustrated with the staff and TAs for not telling
          them how to get the points. But that misunderstands
          the purpose.)

          The purpose is to cause you to learn.
            [compare to exams: personal growth rare on an exam]

     --we expect you think through, then ask
       --"Here is my code. It doesn't work. Please debug." won't work.
       --If you get a reply from a TA, and then send email 20 minutes later
         asking a closely related question, that’s probably not great too.

    [continue from here next time]