1 of 77

Rust School @ SNU SNU

�Jeehoon Kang (KAIST)

2023/02/08 - 2023/02/10

1

2 of 77

Logistics

  • Instructor: Jeehoon Kang (강지훈)
    • Assistant Professor, KAIST
    • Ph.D., Seoul National University (supervisor: Prof. Chung-Kil Hur)
    • Chief R&D Officer, FuriosaAI
  • Date & Place
    • 13:00 - 16:00 pm, 2023/02/08 - 2023/02/10
    • Rm. 105, Bldg., 302, Seoul National University
  • Materials
    • https://github.com/kaist-cp/rust-school
      • Slides and references
      • Q&A (issue tracker)
      • Resource information (e.g., SSH to development server)
    • https://gg.kaist.ac.kr/course/14/
      • Homework & Grading (NOT reported to your supervisor :)

2

3 of 77

Prologue

3

4 of 77

Background

  • Rust is increasingly popular & loved.

4

https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted

5 of 77

But Why?

  • Safety & low-level control
    • vs. C/C++: safety
    • vs. Java/Python: low-level control
  • Modern toolchain
    • Rustup (pyenv, rvm, nvm)
    • Rustfmt & Clippy (clang-format)
    • Cargo (CMake)
    • Rust-analyzer (language server)
    • Crates.io & Docs.rs (central library repository & documentation)

5

This school’s topic

6 of 77

Rust’s Design Goal 1: Safety

  • Strong safety: whatever you write, it’s going to be safe.
    • E.g., Java, OCaml, Haskell, Rust
    • Not e.g., C/C++ (let’s blame the programmer!)�
  • If the program is (potentially) buggy, the compiler will tell you so.

6

7 of 77

Wait, Why C/C++ is Unsafe?

  • Undefined behaviors
    • “the result of executing a program whose behavior is prescribed to be unpredictable, in the language specification to which the computer code adheres” (Wikipedia)
    • In short, it’s “programmer’s fault.”�
  • C11 has 193 cases of undefined behaviors.
    • C11: ISO/IEC 9899:2011
    • J.2 is a (non-comprehensive) list of undefined behaviors.
    • Only “language lawyers” can interpret the document…�
  • Ideally, the compiler should detect all safety errors.
    • Quiz: but why not, C/C++?

7

8 of 77

Rust’s Design Goal 2: Low-Level Control

  • Ability to manipulate low-level resources in an arbitrary manner
    • E.g., virtual memory, physical memory, interrupt, CPU, GPU, …
    • You probably cannot write OS page tables in Java.

8

https://en.wikipedia.org/wiki/Page_table

9 of 77

Organization

  • Why it’s hard to ensure safety of low-level control? (day 1)
    • “Shared mutable states”
    • Existing approaches to (automatically) ensure safety�
  • What’s the key idea of Rust? (day 1, 2)
    • Static verification
    • “Static”: compile-time (automatic, no runtime overhead)�
  • How to apply the key idea to programming features? (day 3)
    • Smart pointers & hybrid (static + runtime) verification of safety
    • First-class functions
    • Parallel programming

9

10 of 77

Interaction

  • Please feel free to ask questions any time.
    • Question-driven lecture
    • If you don’t understand something, probably the same for everyone else.
  • If your question involves nontrivial code, use issue tracker.
    • For more efficient communication
    • Say “Please answer to the issue #42”.
  • Though I assume you already know basic programming skills.
    • … And did homework: https://gg.kaist.ac.kr/course/14/
  • You should do programming assignments.
    • To cultivate your programming skills
    • You’re encouraged to use ChatGPT :)

10

11 of 77

Assignment (Day 1)

11

12 of 77

Why so many assignments…?

12

13 of 77

The Danger of Shared Mutable States

13

14 of 77

What is Shared Mutable States?

  • Shared: multiple accessors at the same time
    • An object is shared among multiple variables.�auto a = (int *) malloc(sizeof(int));�auto b = a;
    • An object is shared among multiple threads.�std::thread t([=](){� auto b = b; // capture�});
  • Mutable: supporting read & write
    • auto x = *a;�*b = 666;�
  • Primary example: (virtual) memory
    • We will use it as running example.

14

15 of 77

Low-level Resources are Shared Mutable States

  • Physical memory
    • In OS, physical memory is a shared mutable state used by virtual memory manager (page table).
  • CPU
    • In OS, CPU is a shared mutable state used by a scheduler.
  • HTTP/API/DBMS connections
    • “Connection pool”�
  • HAL (Hardware Abstraction Layer)
    • Understanding low-level resources as shared mutable states
    • The first step towards systems programming

15

16 of 77

Shared Mutable States are Source of Errors (1/2)

    • auto a = (int *) malloc(sizeof(int));�*a = 42;�auto b = a;�std::thread t([=](){ *b = 666; });
  • Data race
    • auto x = *a; // 42? 666? unconstrained non-determinism
  • Use-after-free
    • free(a);
  • Double free
    • auto c = a;�std::thread t([=](){ free(c); });�free(a);

16

17 of 77

Shared Mutable States are Source of Errors (2/2)

  • Quiz: which error it incurs?
    • #include <bits/stdc++.h>�using namespace std;�int main() {� vector<int> v = { 1, 5, 10, 15, 20 };� for (auto it = v.begin(); it != v.end(); it++)� if ((*it) == 5)� v.push_back(-1);� for (auto it = v.begin(); it != v.end(); it++)� cout << (*it) << " ";� return 0;�}
  • Lesson: shared mutable states are sometimes extremely subtle.

17

“Iterator invalidation”

18 of 77

Why? Shared Mutable States break Modularity!

  • You shouldn’t need to understand everything to comprehend a part
    • “닭 잡는데 소 잡는 칼 쓰지 마라". But it’s not always the case…
    • #include <bits/stdc++.h>�using namespace std;�vector<int> v = { 1, 5, 10, 15, 20 };�int main() {� for (auto it = v.begin(); it != v.end(); it++)� f(it); // possibly iterator invalidation� for (auto it = v.begin(); it != v.end(); it++)� cout << (*it) << " ";� return 0;�}
    • Should understand the spawned thread to comprehend the main thread…�
  • [Mutation far away] on [shared data] affects my view on the data.

18

19 of 77

Personal Experience of Shared Mutable States

  • SNU 4190.409 Compilers, 2012 (Prof. Jaejin Lee)
    • Construction of a mini-C-to-Armv7 compiler
    • From scratch (no skeleton code given)
    • Performance competition in FaCSim
    • About 150 hours of efforts
    • 15K LOC in C++�
  • Lack of modularity: bugs are manifested in far-away code!
    • Majority of efforts for fixing segmentation faults…

19

20 of 77

Microsoft’s Experience of Shared Mutable States

  • Matt Miller (Microsoft), Black Hat 2017
    • around 70 percent of all Microsoft patches were fixes for memory safety bugs. The reason for this high percentage is because Windows has been written mostly in C and C++, two "memory-unsafe" programming languages that allow developers fine-grained control of the memory addresses where their code can be executed.

20

21 of 77

Lessons Learned

  • Low-level resources are shared mutable states.�
  • Shared mutable states break modularity.
    • Too many things are intertwined in shared mutable states.
    • Often far-away and even inaccessible code (e.g., library) is involved.�
  • Lack of modularity hinders construction of large software.
    • Human simply cannot think of everything all at once.�
  • Reasoning principle for shared mutable states is necessary.
    • We want to achieve modularity.
    • Human probably cannot achieve this without automated tools.

21

22 of 77

Reasoning Shared Mutable States,

Previously

22

23 of 77

A Wisdom on Shared Mutable States

  • Linus Torvalds (2006, https://lwn.net/Articles/193245/)
    • I will, in fact, claim that the difference between a bad programmer and a good one is whether [s/]he considers [her/]his code or [her/]his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

23

State

“Invariant”

24 of 77

Invariant Enables Modular Reasoning

24

Invariant: assume/guarantee conditions that “divides” complex systems

25 of 77

Invariant Examples

  • How a state’s components relates among each other? (spatial)
  • How a state evolves over time? (temporal)�
  • E.g., Immutability
    • This object should be 42 always.
    • const auto x = 42;
  • E.g., No sharing
    • This object is referenced only by this variable.
    • auto x = 42; // 42�x = 666; // 666�x = 37; // 37
  • More complex invariants for larger objects
    • x is the head of a sorted linked list whose nodes are …

25

26 of 77

Invariant-based Modular Reasoning

  • No shared mutable states
    • Immutability�const auto x = 42;�…�x; // must be 42
    • No sharing�auto x = 42;�… // x is not shared and I didn’t change x�x; // must be 42
  • Tamed shared mutable states
    • Concurrent sorted linked list: I can safely traverse to the next node�because each node’s next pointer is valid.

26

27 of 77

Immutability (Invariant)

  • Shared Immutable States
    • Unconstrained sharing
    • Often accompanied with garbage collection
      • A tracking of (unconstrained) sharing is necessary
  • Best fit for functional languages
    • Immutability by default
    • E.g., OCaml, Haskell
  • Good fit for parallel & distributed systems
    • Immutability for performance (less cache invalidation & synchronization)
    • E.g., Immutable & functional data structures

27

28 of 77

Immutability Example: SSA (POPL 1988)

  • “Static Single Assignment”
    • Compiler optimization technique
    • Invariant: “a variable is assigned only once in a program.”
  • Benefits

28

29 of 77

Immutability Example: RDD (NSDI 2012)

  • “Resilient Distributed Dataset”
    • Immutable by definition
  • Benefits
    • simple programming model��
    • that achieves high performance

29

30 of 77

But Not Everything is Immutable

  • Iterator invalidation (again): we want to mutate the vector.
    • #include <bits/stdc++.h>�using namespace std;�int main() {� vector<int> v = { 1, 5, 10, 15, 20 };� for (auto it = v.begin(); it != v.end(); it++)� if ((*it) == 5)� v.push_back(-1);� for (auto it = v.begin(); it != v.end(); it++)� cout << (*it) << " ";� return 0;�}
  • In general, we want mutate states to make visible effects.

30

31 of 77

No Sharing (Invariant)

  • Example
    • auto x = 42;�… // x is not shared and I didn’t change x�x; // must be 42�
  • Why important?
    • Typical cache hit ratio > 99% → most data are exclusively accessed
    • Exclusive access → modular understanding & more optimizations

31

32 of 77

No Sharing Example: Alias Analysis

  • Two pointers are aliased?
    • Exactly? Overlapped?
    • Always? Possibly?
  • Basis for optimizations
    • Constant propagation
    • Value numbering
    • Redundancy elimination
    • Code motion
  • Basis for understanding
    • No interference from the other functions or threads (possibly unknown)!�
  • … but sharing happens in the real-world programs.

32

33 of 77

Principled Sharing Example: Reference Counting

  • Each object has a counter for incoming references.
    • It’s incremented/decremented when a reference is created/destroyed.
    • Once it reaches zero, the object can be reclaimed.
  • Runtime overhead due to…
    • Counting
    • “Detached group” (yet unreclaimed)

33

https://plumbr.io/handbook/what-is-garbage-collection/automated-memory-management/reference-counting

34 of 77

But Not All Programs Can Admit RC

  • Reference counting is slow.

34

Blackburn and McKinley. Ulterior reference counting: fast garbage collection without a long wait. OOPSLA 2003.

35 of 77

Principled Sharing Example: Garbage Collection

  • Automatically cleaning up no-longer-used memory locations
    • Tracing (which locations are reachable?)
    • Sweeping (let’s reclaim unreachable objects.)
    • Compacting (let’s move objects to reserve contiguous memory region.)
  • Safety & Impressive throughput
    • Sometime outperforming C/C++�(5-instruction allocation!)
    • With strong safety guarantee
  • Limitations
    • Not precise control of reclamation
    • Higher memory usage
    • Unpredictable-ish pause

35

https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html

36 of 77

Wisdom: if GC works for you, just use it.

36

OOPSLA 2005

37 of 77

But Not All Programs Can Admit GC

  • Time-space tradeoff (Hertz and Berger, OOPSLA 2005)
    • [W]ith five times as much memory, an Appel-style generational collector with a non-copying mature space matches the performance of reachability-based explicit memory management.
    • With only three times as much memory, the collector runs on average 17% slower than explicit memory management.
    • However, with only twice as much memory, garbage collection degrades performance by nearly 70%.
    • When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.
  • GC (relatively) lacks precise control over non-memory resources
    • “Systems programming”

37

38 of 77

Lessons Learned

  • We want invariant that tames shared mutable states.
    • To achieve modularity automatically�
  • Both of immutability & no/principled sharing are great invariants.
    • Huge impact on real-world products & a lot of research papers
    • Though each misses some crucial use cases.�
  • How to more precisely reason about shared mutable states?
    • Automatically
    • More time/space-efficiently than RC and GC

38

39 of 77

Assignment (Day 2)

39

40 of 77

Reasoning Shared Mutable States,�Efficiently & Precisely

40

Type checking

(automatically w/o runtime overhead)

Invariant

Focus on memory

41 of 77

Review: Memory

  • Memory: map from location to value
    • a primary example of shared mutable states
    • Each location is a shared mutable state
  • Stack and heap regions
    • Stack: automatically allocated/freed when a function is started/finished
    • Heap: manually allocated/freed
  • Pointer: general accessor to locations
    • Load, store, free
    • A location object may be shared among multiple pointers�
  • Goal: reasoning about the safety of each pointer access

41

42 of 77

Review: Memory Safety

    • auto a = (int *) malloc(sizeof(int));�*a = 42;�auto b = a;�std::thread t([=](){ *b = 666; });
  • Data race
    • auto x = *a; // 42? 666? unconstrained non-determinism
  • Use-after-free
    • free(a);
  • Double free
    • auto c = a;�std::thread t([=](){ free(c); });�free(a);

42

Focus on UAF

43 of 77

Type-Checking Memory Safety in C/C++ (Fail)

  • Attempt 1
    • void foo(int *p) {� *p; // Potentially unsafe: maybe NULL�}
    • Lesson: we need to enrich pointer types with an invariant.
  • Attempt 2
    • void foo(int &p) {� p; // Potentially unsafe: (int *) ~= (int &) in C/C++�}
    • Lesson: we need to escape C.
  • Attempt 3
    • void foo(unique_ptr<int> p) { // unique_ptr: implying uniqueness of p� *p; // Potentially unsafe: “auto q = std::unique_ptr<int>{p.get()};”�}
    • Lesson: we need to escape C++ and embrace a more strict type checker.

43

44 of 77

Type-Checking Memory Safety in New Language

  • An early attempt: Cyclone (PLDI 2002)
    • Not widely adopted, though
    • Huge influence to Rust

44

45 of 77

Type-Checking Memory Safety in Rust

  • Necessary for types to represent the “live pointer” invariant
  • Multiple such invariants
    • w/ different conditions on mutability & sharing
    • fn foo(p: Box<i32>) { // assume: p "owns" an object� *p; // guarantee: always safe�}
    • fn foo(p: &i32) { // assume: p "borrows" an object� *p; // guarantee: always safe�}
    • fn foo(p: &mut i32) { // assume: p "mutably borrows" an object� *p; // guarantee: always safe�}

45

46 of 77

Owned Type (Mutable & No Sharing)

  • Example: Box
    • fn foo(p: Box<i32>) { // assume: p "owns" an object� *p; // guarantee: always safe�}
  • Transferable & automatically reclaimed (even for heap)
    • fn qux() {� let p = Box::new(42i32);� let q = p; // object’s ownership transferred to “q”; “p” invalidated�} // “q” reclaimed
    • fn bar() {� let p = Box::new(42i32);� foo(p); // object’s ownership transferred to “foo”; “p” is invalidated�} // quiz: “p” is reclaimed where?

46

47 of 77

Borrowed Type (Immutable & Full Sharing, 1/3)

  • Example: reference
    • fn main() {� let s1 = String::from("hello"); // ownership� let len = calculate_length(&s1); // borrow� println!("The length of '{}' is {}.", s1, len);�}�fn calculate_length(s: &String) -> usize {� s.len() // Why safe?�}
    • Safe because “s” is dereferenced while “s1” is valid (not yet reclaimed).
    • Vocabulary: reference “s” immutably borrows from object “s1”.
  • No constraints on the degree of sharing

47

48 of 77

Borrowed Type (Immutable & Full Sharing, 2/3)

  • Type checking: ensuring pointer validity
    • fn main() {� let p = Box::new(42i32);� let x = &p;� drop(p);� *x; // ERROR: use-after-free�}
    • fn main() {� let reference_to_nothing = dangle();�}�fn dangle() -> &String {� let s = String::from("hello");� &s�} // ERROR: s is dropped, return is dangling!

48

49 of 77

Borrowed Type (Immutable & Full Sharing, 3/3)

  • Algorithm: ensuring pointer validity with lifetime analysis
    • If a borrower lives longer than its owner, REJECT!�

49

https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html

50 of 77

Mutably Borrowed Type (Mutable & Sharing, 1/3)

  • Motivation: we want to modify data w/ borrows.
    • fn main() {� let s = String::from("hello");� let s = change(s); // OK, but cumbersome…�}�fn change(mut some_string: String) -> String {� some_string.push_str(", world");� Some_string�}
    • fn main() {� let s = String::from("hello");� change(&s);�}�fn change(some_string: &String) {� some_string.push_str(", world"); // ERROR! Breaking immutability�}

50

51 of 77

Mutably Borrowed Type (Mutable & Sharing, 2/3)

  • Example: mutable reference
    • fn main() {� let mut s = String::from("hello");� change(&mut s);�}�fn change(some_string: &mut String) {� some_string.push_str(", world"); // OK�}
  • Benefits
    • More readable than ownership transfer version
    • More efficient: no data transfer; only pointer transfer

51

52 of 77

Mutably Borrowed Type (Mutable & Sharing, 3/3)

  • Type checking: preventing concurrent mutation
    • Recall: shared mutable state is the evil.
    • Data race, iterator invalidation, …
  • Algorithm: enforcing A⊕M Principle
    • “Alias (borrow) XOR mutation”
    • If an object is borrowed, it cannot be mutated.�fn calculate_length(s: &String) -> usize {� s.push_str("covfefe"); // Compile error: cannot mutate &String�}
    • If an object is not borrowed, it can be mutated.�fn main() {� let mut s1 = String::from("hello");� s1.push_str("covfefe"); // OK�}

52

53 of 77

Summary of Pointer Types in Rust (1/2)

  • Owned (mutable & no sharing)
    • Exclusive permission to access an object
    • Transferable, immutably & mutably borrowable�
  • Immutably borrowed (immutable & full sharing)
    • Immutably borrowable (“reborrow”)�
  • Mutably borrowed (mutable & constrained sharing)
    • Immutably & mutably borrowable (“reborrow”)

53

54 of 77

Summary of Pointer Types in Rust (2/2)

  • Automatically ensuring pointer safety (valid & A⊕M)
    • Lifetime analysis: ensuring pointer validity of borrows
    • A⊕M analysis: ensuring no concurrent mutable borrows�
  • Preventing memory safety errors
    • Data race: write requires [ownership or mutable borrow] (exclusive)
    • Double free: free requires ownership (exclusive)�
  • Representing “flow-sensitive” invariant
    • The same pointer have different types in different program points
    • Ownership → mutable borrow → borrow → ownership → …

54

55 of 77

Remaining Question: How Much Applicable?

  • Applicable to more programming features?
    • Slices and structs
    • Smart pointers
    • first-class functions
    • Parallel programming
    • …�
  • Spoiler: We’ll need hybrid (static + runtime) verification…
    • “Unsafe Rust”

55

56 of 77

Whirlwind Tour of Rust Type System

56

57 of 77

Summary

  • Motivation: learning how to “communicate” with the Rust type checker
  • References
  • Key points (focus on examples)
    • “Ownership Rules”
    • “Variables and Data Interacting with Move / Clone”
    • “Stack-Only Data: Copy”
    • “Return Values and Scope”
    • “Dangling References”
    • “The Rules of References”
    • “The Slice Type” (slice)
    • “Validating References with Lifetimes” (struct)

57

Essential for assignment

58 of 77

Assignment (Day 3)

58

59 of 77

Reasoning Shared Mutable States

In Functions

59

60 of 77

Review: First-Class Function

  • Definition: function as a value
    • let expensive_closure = |num: u32| -> u32 {� println!("calculating slowly...");� thread::sleep(Duration::from_secs(2));� Num�};
  • Capturing variables
    • fn main() {� let list = vec![1, 2, 3];� println!("Before defining closure: {:?}", list);� thread::spawn(move || println!("From thread: {:?}", list)).join().unwrap();�}

60

61 of 77

Question: What If a Function Captures Pointer?

  • First-class function may capture pointers…
    • let list = vec![1, 2, 3];�let only_borrows = || println!("From closure: {:?}", list);�println!("Before calling closure: {:?}", list);�only_borrows();�println!("After calling closure: {:?}", list);
  • The same rule as pointer-capturing structs
    • struct User<'a> {� active: bool,� username: &'a str,� email: &'a str,� sign_in_count: u64,�}
    • Ownership transfer, immutable borrow, or mutable borrow
  • Reference (focus on examples)

61

62 of 77

Reasoning Shared Mutable States

With Smart Pointers

62

63 of 77

What is Smart Pointer?

  • Data structures that act like a pointer
    • Box: heap allocation (unique_ptr in C++)
    • Rc: reference counter (sequential)
    • Arc: reference counter (multi-threaded, A for “atomic”)
    • RefCell: runtime borrows (e.g., try_borrow(), try_borrow_mut())
  • Beyond the scope of Rust’s static verification (valid & A⊕M)
    • Box: dereferences an internal raw pointer
    • Arc: mutates the reference counter concurrently by multiple threads
    • Rc: mutates the reference counter even in the presence of other refs
    • RefCell: effectively promotes “&” to “&mut”

63

64 of 77

Smart Pointer’s Runtime Verification

  • Runtime verification for pointer safety (valid & A⊕M)
    • Box: ownership → exclusive permission to a live pointer in heap
    • Rc/Arc: counter > 0 → safe to dereference
    • RefCell: runtime verification of A⊕M Principle�
  • Rust Book (focus on examples)

64

65 of 77

Supporting Runtime Verification w/ Unsafe Rust

  • Question: how to implement smart pointers in Rust?
    • At the first place, they don’t pass Rust’s static verification!�
  • Answer: “unsafe” escape hatch
    • Raw pointer arithmetic & dereference
    • Unchecked pointer access (e.g., unchecked array indexing)
    • unsafe { very_unsafe_op(); }
    • Example (RefCell): https://doc.rust-lang.org/src/core/cell.rs.html#994-996�
  • … Then what’s the difference from C/C++?

65

66 of 77

Improving Modularity w/ Interior Mutability

  • Interior mutability: enveloping potential unsafety within safe API
    • Impl of RefCell::try_borrow(): converting “&” to “&mut” (unsafe Rust)
    • API: “as if” the client doesn’t mutate RefCell (safe Rust)
    • Obligation: library designer’s manual reasoning (as a comment)
    • Reference: https://doc.rust-lang.org/book/ch15-05-interior-mutability.html�
  • Better modularity
    • Clients don’t need to care potentially unsafe impl (“far-away” mutations)
    • C/C++ lacks such modular reasoning support for potential unsafety

66

67 of 77

Hybriding Static and Runtime Verification

  • Runtime verification
    • (Reference counter == 1) → safe to get “&mut”
  • Static verification
    • From “&mut”, we can get multiple “&”
  • Smooth composition of static + runtime verification
    • fn foo(p: &mut i32) { // static verification� let q = &*p;� let r = &*p;�}�fn main() {� let mut x = Rc::new(42i32);� let p = Rc::get_mut(&mut x).unwrap(); { // runtime verification� foo(p);�}
    • Reason: “&mut” serves as the invariant enabling modular reasoning

67

68 of 77

Reasoning Shared Mutable States

In Parallel Programming

68

69 of 77

Concurrency API (1/3)

  • Thread spawn
    • Reference: https://doc.rust-lang.org/std/thread/fn.spawn.html������
    • ‘static: shouldn’t pass immortal references
    • Send: multi-thread safe

69

70 of 77

Concurrency API (2/3)

  • Send
    • “ownership of values of the type implementing Send can be transferred between threads.” [link]
    • Examples: Box, Mutex, Arc, RefCell, …
    • Non-examples: Rc [link]
  • Sync
    • “any type T is Sync if &T (an immutable reference to T) is Send, meaning the reference can be sent safely to another thread.” [link]
    • Examples: Box, Mutex, Arc
    • Non-exmaples: Rc, RefCell [link]

70

71 of 77

Concurrency API (3/3)

  • Channel
    • Reference [link]����
    • Wait, T must be Send, right? (Not exactly, but close…)

71

72 of 77

Parallelism API

72

73 of 77

Epilogue

73

74 of 77

Recall: Organization

  • Why it’s hard to ensure safety of low-level control? (day 1)
    • “Shared mutable states”
    • Existing approaches to (automatically) ensure safety�
  • What’s the key idea of Rust? (day 1, 2)
    • Static verification
    • “Static”: compile-time (automatic, no runtime overhead)�
  • How to apply the key idea to programming features? (day 3)
    • Smart pointers & hybrid (static + runtime) verification of safety
    • First-class functions
    • Parallel programming

74

75 of 77

Rust in FuriosaAI

  • NPU chip startup @ Seoul
    • https://furiosa.ai
    • First chip Warboy available in Q1 2023�
  • Rust is widely used in the software stack
    • From 2017
    • Compiler, serving system, program visualizer, profiler, …
    • Huge productivity gain thanks to Rust’s type checker�
  • Client API in Rust

75

76 of 77

Rust in KAIST

  • Concurrency and Parallelism Laboratory
    • https://cp.kaist.ac.kr
    • CS220: Programming Principles [link]
    • CS420: Compiler Design [link]
    • CS431: Concurrent Programming [link]
    • Hardware description language (ASPLOS 2023)
    • Garbage collectors (PLDI 2020, submitted)
    • Persistent data structures (submitted)
    • NPU serving systems (submitted)
  • Computer Architecture and Systems Laboratory
    • http://casys.kaist.ac.kr/
    • CS492: Virtualization
    • Isolation of system software components using Rust (submitted)

76

77 of 77

Rust in SNU?

  • I wish you’ll also enjoy huge productivity gain of Rust.
    • The most loved language (Stack Overflow survey)
    • The only programming language I can speak�
  • I’m widely open to collaboration.

77

Thank you!