Technology

Functional Programming for Computing Clouds

Description

With the advent of multicore CPUs, cloud computing and Big Data, we are currently observing changes that will eventually lead information technology into a whole new era, and we are need to search for programming language paradigms that match with it. Will Functional Programming languages (FPLs) be the game changer?

3. Functional Programming Languages• Based on the λ-calculus• Declarative• Functions are declared, describe relation between input and output• Functions always evaluate to the same value for a given argument (“free of side effects”).• Variables are assigned once.• Functional PLs that by default exclude destructive modifications (to data structures) are called “pure.” 3

4. λ - calculus• Alonzo Church 1930s• Small Grammar• Grammar can partially be found back in LISP and Haskell syntax• Can express everything that is computable• No state ! 4

5. Pure FPLs• Functions can be composed, curried, etc..• All pure functions can be executed in parallel• Compiler can make it fit for multicore: e.g. re-arrange order of function execution or inline.• Runtime can cache function evaluation.• IO is a beast that disturbs this concepts & needs to be tamed (for example with a monad).• Every Haskell program is a function in the IO monad. 5

7. Vision & requirements of cloud computing• Clouds will need to support scalable programs.• “Any” application scaled through distribution over parallel (multicore) hardware.• Applications with high concurrency are good candidates for parallelization. 7

11. Haskell• Named after Haskell Brooks Curry (1900 - 1982). Combinatory logic (1930s).• Born as Haskell 1.0 standard in 1990 (approximately at the same time than Erlang)• Haskell 98 is most prominent definition yet 11

15. Immutability of Data• The consequences are huge. There is more data than you think. For example a counter: c = c + 1;• Haskell implementation of “counters” depends on what you need to achieve.• Common to use Map and Fold (aka reduce)• Eventually counters represent some sort of state. Use the state monad: Control.Monad.State• Haskell is by default pure. Mutable data structures can be used: Data.IORef, Data.Judy but are seen as “not idiomatic”. 15

16. Immutability of Data (continued)• Data.IORef part of the base package.• The function unsafePerformIO can “subvert” the type system and allows any kind of mutable state.• A large number of Haskell modules make use of it! – Randomness & Encryption, GUIs, …• Is immutability over-emphasized? 16

19. Strong Type System• All monomorphic types are part of the category of Haskell types, “Hask”. Maps between types are the functions in Haskell.• Data types can be tainted. E.g. IO Int, Maybe Int• Type system supports safety and correctness. Haskell code is reasonably easy to test.• At the beginning the type system frequently gets into your way.• Maintainability: I am often positively surprised how many changes to my existing code work at the first compilation (once I get the types right).• Definition of own types and type classes etc. bears the foundation for great flexibility. 19

23. Multi Tenancy: Safe Haskell• Released to public in early 2012.• Vision: tenants upload code (e.g. a worker) that gets compiled and executed as plugin by a Haskell app- engine.• Plugin-concept based on library System.Eval.Haskell• New language extensions to allow secure code only: -XSafe, -XTrustworthy, -Xunsafe• Eventually based on type safety. 23

24. Safe Haskell (continued)• Two routes decide what to be trusted:• -XSafe = trust inferred by the compiler, limiting Haskell to a (small) subset.• In PaaS subsets and restrictions are “normal”. Think Java on the Google App Engine.• -XTrustworthy = trust decided by a person. Not a powerful security concept? 24

25. Issues• There is no obvious way how to match functions to threads.• Threads are more related to sequential programming (with shared memory) than to FP. Think CSP.• Many programs have to parallelize relative small computations with high inter-dependency.• Message passing & actors also no fit to distribute small computations.• Function composition is … sequential execution! 25

26. Issues (continued)• When a computation is moved to a remote node, little is known about cost of transport and state (e.g. load of the remote node). Multi-tenancy!• Cost model required.• (Network)Protocols are the most prominent cost center.• It is extremely unlikely that commercial clouds will use “niche” hardware or proprietary protocols.• Protocol design will need to be simple and light weight.• Protocols in distributed environments will orchestrate and coordinate. Basis for a DS coordination language? 26

27. Amdahl’s Law• Possible to calculate the speed improvement when n% of the code are parallel.• Unknown under what conditions the law holds.• Relatively small influences have huge adversary effects: – code that has a parallel portion of 95% results in a speed improvement of factor six on an 8 core CPU. – code that has a parallel portion of 75% results in a speed improvement of factor three on an 8 core CPU. 27

28. Amdahl’s Law (continued) 28

29. If Amdahl’s law holds, then …We better go on & develop sequential codeBecauseInefficiencies and overhead add up:• Compiler• Runtime• Competition for the cpu cores & resources• By the way: (OS) threads are costly to provision, here elastic may become plastic! 29

33. OOP• “OOP is eliminated entirely from the introductory curriculum [of Carnegie Mellon University], because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum.” (Harper, 2011) 33

Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.