CS 251 Fall 2019 CS 251 Fall 2019 Parallelism and Concurrency in - - PowerPoint PPT Presentation

cs 251 fall 2019 cs 251 fall 2019 parallelism and
SMART_READER_LITE
LIVE PREVIEW

CS 251 Fall 2019 CS 251 Fall 2019 Parallelism and Concurrency in - - PowerPoint PPT Presentation

CS 251 Fall 2019 CS 251 Fall 2019 Parallelism and Concurrency in 251 Principles of Programming Languages Principles of Programming Languages Ben Wood Ben Wood Goal: encounter essence, key concerns Parallelism non-sequential


slide-1
SLIDE 1

CS 251 Fall 2019 Principles of Programming Languages

Ben Wood

λ

CS 251 Fall 2019

Principles of Programming Languages

Ben Wood

λ

https://cs.wellesley.edu/~cs251/f19/

Parallelism

(and Concurrency)

Parallelism 1

Parallelism and Concurrency in 251

  • Goal: encounter

– essence, key concerns – non-sequential thinking – some high-level models – some mid-to-high-level mechanisms

  • Non-goals:

– performance engineering / measurement – deep programming proficiency – exhaustive survey of models and mechanisms

Parallelism 2

Eliminate 1 big assumption:

Evaluation happens as a sequence of ordered steps.

Parallelism 3

Pa Parallelism Co Concu curre rrency cy

data / work data = resources workers = computations workers = resources di divide ded d among sh share Use more resources to complete work faster. Coordinate access to shared resources. Both can be expressed using a variety of primities.

Parallelism 4

slide-2
SLIDE 2

Parallelism via Manticore

  • Extends SML with language features for

parallelism/concurrency.

  • Mix research vehicle / established models.
  • Parallelism patterns:

– data parallelism:

  • parallel arrays
  • parallel tuples

– task parallelism:

  • parallel bindings
  • parallel case expressions
  • Unifying model:

– futures / tasks

  • Mechanism:

– work-stealing

Manticore

Parallelism 5

Parallel Arrays: 'a parray

[| e1, e2, …, en |] [| elo to ehi by estep |] [| e | x in elems |] [| e | x in elems where pred |] parallel mapping comprehensions parallel filtering comprehensions integer ranges literal parray Manticore

Parallelism 6

parallel array comprehensions

[| e1 | x in e2 |] Evaluation rule:

  • 1. Under the current environment, E, evaluate

e2 to a parray v2.

  • 2. For each element vi in v2, wi

with no

  • con
  • nstra

raint

  • n
  • n re

relative timing or

  • rder:
  • 1. Create new environment Ei = x↦vi, E.
  • 2. Under environment Ei, evaluate e1 to a value vi'
  • 3. The result is [| v1', v2', …, vn' |]

Manticore

Parallelism 7

Data Parallelism

many argument data of same type pa parallelize ze ap appli licat cation o

  • f s

same ame o

  • perat

ation to to all data many result data of same type no ordering/ interdependence

Parallelism 8

slide-3
SLIDE 3

Parallel Map / Filter

fun mapP f xs = [| f x | x in xs |]

: ('a -> 'b) -> 'a parray -> 'b parray

fun filterP p xs = [| x | x in xs where p x |]

: ('a -> bool) -> 'a parray -> 'a parray

Manticore

Parallelism 9

Parallel Reduce

fun reduceP f init xs = …

: (('a * 'a) -> 'a) -> 'a -> 'a parray -> 'a

f ( , ) f ( , ) f ( , ) f ( , ) f ( , ) f ( , ) f ( , )

sibling of fold f must be associative … … … … Manticore

Parallelism 10

Task Parallelism

pa parallelize ze appl pplication

  • n
  • f
  • f different ope
  • peration
  • ns

wi within larg rger r computation some ordering/interdependence controlled explicitly

Parallelism 11

Parallel Bindings

fun qsortP (a: int parray) : int parray = if lengthP a <= 1 then a else let val pivot = a ! 0 (* parray indexing *) pval sorted_lt = qsortP (filterP (fn x => x < pivot) a) pval sorted_eq = filterP (fn x => x = pivot) a pval sorted_gt = qsortP (filterP (fn x => x > pivot) a) in concatP (sorted_lt, concatP (sorted_eq, sorted_gt)) end St Start ev evaluating in p in parallel el bu but do don’t wait unt until il need needed ed. Wa Wait until results are ready before using them. sorted_eq sorted_gt pivot concatP sorted_lt Manticore

Parallelism 12

slide-4
SLIDE 4

Parallel Cases

Manticore datatype 'a bintree = Empty | Node of 'a * 'a bintree * 'a bintree fun find_any t e = case t of Empty => NONE | Node (elem, left, right) => if e = elem then SOME t else pcase find_any left e & find_any right e of SOME tree & ? => SOME tree | ? & SOME tree => SOME tree | NONE & NONE => NONE

Ev Eval aluat uate these in n par aral allel.

If If o

  • ne

ne f finis inishes w wit ith S SOME, r , retur urn it n it wi without waiting for r the other. If If b both f finis inish w wit ith N NONE, r , retur urn N n NONE.

Parallelism 13

Futures: unifying model for Manticore parallel features

signature FUTURE = sig type 'a future (* Produce a future for a thunk. Like Promise.delay. *) val future : (unit -> ’a) -> ’a future (* Wait for the future to complete and return the result. Like Promise.force. *) val touch : ’a future -> ’a

(* More advanced features. *) datatype 'a result = VAL of 'a | EXN of exn (* Check if the future is complete and get result if so. *) val poll : ’a future -> ’a result option (* Stop work on a future that won't be needed. *) val cancel : ’a future -> unit

end future = promise speculatively forced in parallel

Parallelism 14

Futures: timeline visualization 1

Parallelism 15

let val f = future (fn () => e) in work … (touch f) … end

time

Futures: timeline visualization 2

Parallelism 16

let val f = future (fn () => e) in work … (touch f) … end

time

slide-5
SLIDE 5

pval as future sugar

let pval x = e in … x … end let val x = future (fn () => e) in … (touch x) … end

*a bit more: implicitly cancel an untouched future

  • nce it becomes clear it won't be touched.

Parallelism 17

Parray ops as futures: rough idea 1

Parallelism 18

[| f x | x in xs |] map touch (map (fn x => future (fn () => f x)) xs)

Suppose we represent parrays as lists* of

  • f elements:

*not the actual implementation

Parray ops as futures: rough idea 2

Parallelism 19

[| f x | x in xs |] map (fn x => future (fn () => f (touch x))) xs

Suppose we represent parrays as lists* of

  • f element futures:

*not the actual implementation

Ke Key semantic difference 1 vs 2?

Odds and ends

  • pcase: not just future sugar

– Choice is a distinct primitive* not offered by futures alone.

  • Where do execution resources from futures

come from? How are they managed?

  • Tasks vs futures:

– function calls vs. val bindings.

  • Forward to concurrency and events…

Parallelism 20

*at least when implemented well.