Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Heather Miller

1,372 views

Published on

FuncBY

Published in: Technology
  • Be the first to comment

Heather Miller

  1. 1. Function-Passing Style Typed, Distributed Functional Programming Heather Miller @heathercmiller Philipp Haller @philippkhaller EPFL Typesafe
  2. 2. …been working on Language support for distributed system builders. Serialization That happens mostly at compile time, so it’s performant. Type classes to allow users to serialize to different formats (binary, JSON, etc) 1.
  3. 3. …been working on Language support for distributed system builders. Spores Portable (serializable) closures. Type constraints to restrict what they capture 2.
  4. 4. In this talk… A programming model. Builds on the basis of serializable functions to provide a substrate that distributed systems can be built upon
  5. 5. In this talk… A programming model. The result… the model greatly simplifies the design and implementation of mechanisms for: Fault-tolerance In-memory caching Debugging(i.e., pushing types into more layers of the stack) IN A CLEAN & FUNCTIONAL WAY. (STATELESS!)
  6. 6. Note: Currently a research project. Thus, all aspects of it are under development + publication in the works. (Thanks, )
  7. 7. FUNDAMENTAL IDEA:
  8. 8. FUNDAMENTAL IDEA: Inversion of the actor model. Can be thought of as a dual to actors.
  9. 9. FUNDAMENTAL IDEA: Inversion of the actor model. Can be thought of as a dual to actors. A DUAL WHICH NICELY COMPLEMENTS ACTORS!
  10. 10. Um, HOW?
  11. 11. Actors… Encapsulate state and behavior. Are stationary. Actors exchange data/commands through asynchronous messaging.
  12. 12. Function-passing… Stateless. Built on persistent data structures. Keep the data stationary. Functions are exchanged through asynchronous messaging.
  13. 13. Function-passing… Stateless. Built on persistent data structures. Keep the data stationary. Functions are exchanged through asynchronous messaging. Of note: This is a model for programming with data and not a new model of concurrent processes like actors. ! Instead, we provide a new means of working with distributed data in a functional way.
  14. 14. A Note on Distributed Computing Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall Sun Microsystems Laboratories 2550 Garcia Avenue Mountain View, CA 94043 1 Introduction Much of the current work in distributed, object-oriented systems is based on the assumption that objects form a sin-gle ontological class. This class consists of all entities that can be fully described by the specification of the set of interfaces supported by the object and the semantics of the operations in those interfaces. The class includes objects that share a single address space, objects that are in sepa-rate address spaces on the same machine, and objects that are in separate address spaces on different machines (with, perhaps, different architectures). On the view that all 1.1 Terminology In what follows, we will talk about local and distributed computing. By local computing (local object invocation, etc.), we mean programs that are confined to a single address space. In contrast, we will use the term distributed computing (remote object invocation, etc.) to refer to pro-grams that make calls to other address spaces, possibly on another machine. In the case of distributed computing, nothing is known about the recipient of the call (other than that it supports a particular interface). For example, the client of such a distributed object does not know the hard-ware architecture on which the recipient of the call is run-ning,
  15. 15. A Note on Distributed Computing Differences in latency, memory access, partial failure, and Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall concurrency make merging of the computational models of local and distributed computing Sun Microsystems both unwise Laboratories to attempt and unable to succeed. 2550 Garcia Avenue Mountain View, CA 94043 1 Introduction Much of the current work in distributed, object-oriented systems is based on the assumption that objects form a sin-gle ontological class. This class consists of all entities that can be fully described by the specification of the set of interfaces supported by the object and the semantics of the operations in those interfaces. The class includes objects that share a single address space, objects that are in sepa-rate address spaces on the same machine, and objects that are in separate address spaces on different machines (with, perhaps, different architectures). On the view that all 1.1 Terminology In what follows, we will talk about local and distributed computing. By local computing (local object invocation, etc.), we mean programs that are confined to a single address space. In contrast, we will use the term distributed computing (remote object invocation, etc.) to refer to pro-grams that make calls to other address spaces, possibly on another machine. In the case of distributed computing, nothing is known about the recipient of the call (other than that it supports a particular interface). For example, the client of such a distributed object does not know the hard-ware architecture on which the recipient of the call is run-ning, “ ”
  16. 16. A Note on Distributed Computing Differences in latency, memory access, partial failure, and Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall concurrency make merging of the computational models of local and distributed computing Sun Microsystems both unwise Laboratories to attempt and unable to succeed. 2550 Garcia Avenue Mountain View, CA 94043 A better approach is to accept that there are irreconcilable differences between local and distributed computing, and to be conscious of those differences at all stages of the design and implementation of distributed applications. Rather than trying to merge local and remote objects, engineers need to be constantly reminded of the differences between the two, and know when it is appropriate to use each kind of object. 1 Introduction Much of the current work in distributed, object-oriented systems is based on the assumption that objects form a sin-gle ontological class. This class consists of all entities that can be fully described by the specification of the set of interfaces supported by the object and the semantics of the operations in those interfaces. The class includes objects that share a single address space, objects that are in sepa-rate address spaces on the same machine, and objects that are in separate address spaces on different machines (with, perhaps, different architectures). On the view that all 1.1 Terminology In what follows, we will talk about local and distributed computing. By local computing (local object invocation, etc.), we mean programs that are confined to a single address space. In contrast, we will use the term distributed computing (remote object invocation, etc.) to refer to pro-grams that make calls to other address spaces, possibly on another machine. In the case of distributed computing, nothing is known about the recipient of the call (other than that it supports a particular interface). For example, the client of such a distributed object does not know the hard-ware architecture on which the recipient of the call is run-ning, “ ” “ ”
  17. 17. So, WHAT DOES IT LOOKLIKE?
  18. 18. Function-Passing Model the (illustrated)
  19. 19. Function-Passing Model the Two concepts: (illustrated)
  20. 20. Function-Passing Model the Two concepts: (illustrated) 1. Stationary, immutable data.
  21. 21. Function-Passing Model the Two concepts: (illustrated) 1. Stationary, immutable data. Portable functions – move the functionality to the data. 2.
  22. 22. Function-Passing Model the Two concepts: (illustrated) 1. Stationary, immutable data. Silos Portable functions – move the functionality to the data. 2.
  23. 23. Function-Passing Model the Two concepts: (illustrated) 1. Stationary, immutable data. Silos (for a lack of a better name) Portable functions – move the functionality to the data. 2.
  24. 24. Function-Passing Model the Two concepts: (illustrated) 1. Stationary, immutable data. Silos (for a lack of a better name) Portable functions – move the functionality to the data. 2. Spores
  25. 25. Function-Passing Two concepts: (illustrated) Model the 1. Stationary, immutable data. Silos (for a lack of a better name) Portable functions – move the functionality to the data. 2. Spores
  26. 26. Function-Passing Model the (illustrated) Silo[T] T Silos. WHAT ARE THEY? SiloRef[T] def apply def send
  27. 27. Function-Passing Model the (illustrated) Silo[T] T Silos. WHAT ARE THEY? SiloRef[T] def apply def send The handle to a Silo. (The workhorse.)
  28. 28. Function-Passing Model the (illustrated) Silo[T] T Silos. WHAT ARE THEY? SiloRef[T] def apply def send The handle to a Silo. def apply(s1: Spore, s2: Spore): SiloRef[T]
  29. 29. Function-Passing Model the (illustrated) Silo[T] T Silos. WHAT ARE THEY? SiloRef[T] def apply def send The handle to a Silo. def apply(s1: Spore, s2: Spore): SiloRef[T] Ta k e s t w o s p o r e s : LAZY! framework logic (combinator), e.g. map user/application-provided argument function Defers application of fn to silo, returns SiloRef with info for later materialization of silo.
  30. 30. Function-Passing Model the (illustrated) Silo[T] T Silos. WHAT ARE THEY? SiloRef[T] def apply def send The handle to a Silo. def apply(s1: Spore, s2: Spore): SiloRef[T] def send(): Future[T]
  31. 31. Function-Passing Model the (illustrated) Silo[T] T Silos. WHAT ARE THEY? SiloRef[T] def apply def send The handle to a Silo. def apply(s1: Spore, s2: Spore): SiloRef[T] Sends info for function application and silo materialization to remote node EAGER! def send(): Future[T] Asynchronous/nonblocking data transfer to local machine (via Future)
  32. 32. Function-Passing Model the Silo[T] (illustrated) SiloRef[T] T Machine 1 Machine 2
  33. 33. Function-Passing Model the Silo[T] (illustrated) SiloRef[T] λ T T⇒S Machine 1 Machine 2
  34. 34. Function-Passing Model the Silo[T] (illustrated) SiloRef[T] λ T ) SiloRef[S] Machine 1 Machine 2
  35. 35. Function-Passing Model the Silo[T] (illustrated) SiloRef[T] λ T ) SiloRef[S] Silo[S] ) S Machine 1 Machine 2
  36. 36. Function-Passing Silo Model the (illustrated)
  37. 37. Function-Passing Silo Model the Silo Silo Machine 1 (illustrated)
  38. 38. Function-Passing Silo Model the Silo Silo Machine 1 (illustrated) Silo Silo Silo Machine 2
  39. 39. Function-Passing Model the Two concepts: (illustrated) 1. Stationary, immutable data. Silos (for a lack of a better name) Portable functions – move the functionality to the data. 2. Spores
  40. 40. What do spores look like? Basic usage: val s = spore { val h = helper (x: Int) => { val result = x + " " + h.toString println("The result is: " + result) } } a sequence of local value (val) declarations only (the “spore header”), and 1 THE BODY OF A SPORE CONSISTS OF 2 PARTS 2 a closure http://docs.scala-lang.org/sips/pending/spores.html
  41. 41. A Spore Guarantees... (vsclosures) 1. All captured variables are declared in the spore header, or using capture 2. The initializers of captured variables are executed once, upon creation of the spore 3. References to captured variables do not change during the spore’s execution http://docs.scala-lang.org/sips/pending/spores.html
  42. 42. Spores& Closures Evaluation semantics: Remove the spore marker, and the code behaves as before spores & closures are related: You can write a full function literal and pass it to something that expects a spore. (Of course, only if the function literal satisfies the spore rules.) http://docs.scala-lang.org/sips/pending/spores.html
  43. 43. Function-Passing Model the (illustrated) Spores. Benefits: environment (captured variables) is declared explicitly, and fixed at spore creation time. can statically ensure that everything captured is serializable
  44. 44. Function-Passing Model the (illustrated) 14 Spores. Benefits: 6SRUHV $ 7SH%DVHG )RXQGDWLRQ IRU ORVXUHV LQ WKH $JH RI RQFXUUHQF DQG 'LVWULEXWLRQ +HDWKHU 0LOOHU 3KLOLSS +DOOHU1 DQG 0DUWLQ 2GHUVN (3)/ DQG 7SHVDIH ,QF1 environment (captured ’Š‹Ž‹’’ŜŠƒŽŽ‡”ɒ–›’‡•ƒˆ‡Ŝ…‘variables) 1 DQG is declared ƇŠ‡ƒ–Š‡”Ŝ‹ŽŽ‡”ř ƒ”–‹Ŝ‘†‡”•›ƈɒ‡’ˆŽŜ…Š explicitly, and fixed at spore creation time. can statically ensure that everything captured is serializable $EVWUDFW )XQFWLRQDO SURJUDPPLQJ )3
  45. 45. LV UHJXODUO WRXWHG DV WKH ZD IRUZDUG IRU EULQJLQJ SDUDOOHO FRQFXUUHQW DQG GLVWULEXWHG SURJUDPPLQJ WR WKH PDLQVWUHDP 7KH SRSXODULW RI WKH UDWLRQDOH EHKLQG WKLV YLHZSRLQW KDV HYHQ OHG WR D QXPEHU RI REMHFWRULHQWHG 22
  46. 46. SURJUDPPLQJ ODQJXDJHV RXWVLGH WKH 6PDOOWDON WUDGLWLRQ DGRSW LQJ IXQFWLRQDO IHDWXUHV VXFK DV ODPEGDV DQG WKHUHE IXQFWLRQ FORVXUHV +RZHYHU GHVSLWH WKLV HVWDEOLVKHG YLHZSRLQW RI )3 DV DQ HQDEOHU UHOLDEO GLVWULEXWLQJ IXQF WLRQ FORVXUHV RYHU D QHWZRUN RU XVLQJ WKHP LQ FRQFXUUHQW HQYLURQPHQWV QRQHWKH OHVV UHPDLQV D FKDOOHQJH DFURVV )3 DQG 22 ODQJXDJHV 7KLV SDSHU WDNHV D VWHS WR ZDUGV PRUH SULQFLSOHG GLVWULEXWHG DQG FRQFXUUHQW SURJUDPPLQJ E LQWURGXFLQJ D QHZ FORVXUHOLNH DEVWUDFWLRQ DQG WSH VVWHP FDOOHG VSRUHV WKDW FDQ JXDUDQWHH FOR VXUHV WR EH VHULDOL]DEOH WKUHDGVDIH RU HYHQ KDYH FXVWRP XVHUGHILQHG SURSHUWLHV UXFLDOO RXU VVWHP LV EDVHG RQ WKH SULQFLSOH RI HQFRGLQJ WSH LQIRUPDWLRQ FRU UHVSRQGLQJ WR FDSWXUHG YDULDEOHV LQ WKH WSH RI D VSRUH :H SURYH RXU WSH VVWHP VRXQG LPSOHPHQW RXU DSSURDFK IRU 6FDOD HYDOXDWH LWV SUDFWLFDOLW WKURXJK D VPDOO HPSLULFDO VWXG DQG VKRZ WKH SRZHU RI WKHVH JXDUDQWHHV WKURXJK D FDVH DQDOVLV RI UHDOZRUOG GLVWULEXWHG DQG FRQFXUUHQW IUDPHZRUNV WKDW WKLV VDIH IRXQGDWLRQ IRU FORVXUHV IDFLOLWDWHV .HZRUGV FORVXUHV IXQFWLRQV GLVWULEXWHG SURJUDPPLQJ FRQFXUUHQW SURJUDP PLQJ WSH VVWHPV ECOOP’ A SIP: http://docs.scala-lang.org/sips/pending/spores.html
  47. 47. Ok, EXAMPLE, PLEASE.
  48. 48. Function-Passing Model the (illustrated) EXAMPLE: Distributed List with operations map and reduce. (This is what would be happening under the hood) SiloRef[List[Int]]
  49. 49. Function-Passing Model the (illustrated) EXAMPLE: Distributed List with operations map and reduce. (This is what would be happening under the hood) (Spores) SiloRef[List[Int]]
  50. 50. Function-Passing Model the (illustrated) EXAMPLE: Distributed List with operations map and reduce. (This is what would be happening under the hood) SiloRef[List[Int]] .apply
  51. 51. Function-Passing Model the (illustrated) EXAMPLE: Distributed List with operations map and reduce. (This is what would be happening under the hood) SiloRef[List[Int]] SiloRef[List[Int]] .apply
  52. 52. Function-Passing EXAMPLE: Distributed List with operations map and reduce. (This is what would be happening under the hood) .apply Model the (illustrated) SiloRef[List[Int]] SiloRef[List[Int]] .apply
  53. 53. Function-Passing EXAMPLE: Distributed List with operations map and reduce. (This is what would be happening under the hood) map f .apply Model the (illustrated) SiloRef[List[Int]] SiloRef[List[Int]] .apply
  54. 54. Function-Passing Distributed List with operations map and reduce. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply Model SiloRef[List[Int]] map (_*2) the (illustrated) reduce (_+_) EXAMPLE: (This is what would be happening under the hood) .apply .apply
  55. 55. Function-Passing Distributed List with operations map and reduce. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply Model SiloRef[List[Int]] map (_*2) the (illustrated) reduce (_+_) EXAMPLE: (This is what would be happening under the hood) .apply .apply .send()
  56. 56. Function-Passing Model the (illustrated) EXAMPLE: Distributed List with operations map and reduce. (This is what would be happening under the hood) SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_)
  57. 57. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_)
  58. 58. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_) Machine 1
  59. 59. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_) Machine 1 List[Int] Silo[List[Int]] Machine 2
  60. 60. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_) Machine 1 List[Int] Silo[List[Int]] Machine 2
  61. 61. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_) Machine 1 List[Int] Silo[List[Int]] Machine 2 λ
  62. 62. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_) Machine 1 List[Int] Silo[List[Int]] Machine 2 Int Silo[Int] List[Int] Silo[List[Int]] List[Int] Silo[List[Int]]
  63. 63. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int] map f .apply SiloRef[List[Int]] .apply .send() map (_*2) reduce (_+_) Machine 1 List[Int] Silo[List[Int]] Machine 2 Int Silo[Int] List[Int] Silo[List[Int]] List[Int] Silo[List[Int]] Int
  64. 64. Ok, HOW DOES THISHELP WITH FAULT TOLERANCE?
  65. 65. Data in silos easily reconstructed: Silos and SiloRefs relate to each other by means of a persistent data structure The persistent data structure is based on the chain of operations to derive the data of each silo. Thus, traversing the silo data structures yields the complete lineage of a silo. Since the lineage is composed of spores, it’s serialized. This means it can be persisted or transferred to other machine.
  66. 66. in SUMMARY, Data (Silos) managed using persistent data structure. All operations, including operations provided by system builders, are spores – so, serializable! Taken together: A lot simpler to build mechanisms for fault tolerance!
  67. 67. Can’t I just… Send spores within messages between actors/processes? Granted, that’s already quite powerful. :-) However, spores + silos additionally provides a lot of benefits that actors + spores alone do not provide out-of-the-box: Benefits: deferred evaluation (laziness) enables optimizations to reduce intermediate results. statelessness + lineages simplifies the implementation of mechanisms for fault tolerance for certain applications (think dist. collections)
  68. 68. Looking for feedback, demanding use cases, contributors. Get involved! function-passing@googlegroups.com Thank you!

×