functional functional programm programming
play

Functional Functional Programm Programming ing XP XP The - PowerPoint PPT Presentation

Functional Functional Programm Programming ing XP XP The Industrial Experience 2013-02-21 vers 1 1 Kar Karol ol Ostrovsk Ostrovsk M.Sc. Comenius University, Bratislava Ph.D. Chalmers Post-doc Chalmers System


  1. Functional Functional Programm Programming ing XP XP The Industrial Experience 2013-02-21 vers 1 1

  2. Kar Karol ol Ostrovsk Ostrovský • M.Sc. – Comenius University, Bratislava • Ph.D. – Chalmers • Post-doc – Chalmers • System Designer – Dfind IT  On assignment for Ericsson  Operations & Maintenance Subsystem 2

  3. The Chalmers Years The Chalmers Years • Research in static analysis of concurrent programming languages  Type systems  Protocol analysis • Main course responsible  Concurrent Programming Course – TDA381  Developed the course between 2005 and 2010 3

  4. The Langua The Language & Para ge & Paradigm Nerd digm Nerd • Language skills  Basic Ocaml  LaTeX  Pascal  VAX assembler  C/C++  Trilogy   Scheme Ada   SmallTalk Agda   Java Some of my own   JR (MPD)  Haskell  Erlang 4

  5. What is Program What is Programming? ming? • Manipulation of Structures 5

  6. Compositions Compositions • Functions map reduce/fold 6

  7. Str Structures uctures • Types [B] C 7

  8. My Fa My Favourite Slide vourite Slide The Message from this Course • Should you forget everything from this course, please, remember at least this saying: Use the right tool for the job. PPVT10 – Introduction 3 8

  9. Mobile Mobile Telecom Network Telecom Network 9

  10. Packet Core Packet Core Network Network • 3GPP  Defines standards (mostly protocols)  Interoperability is essential • SGSN-MME  Servicing GPRS Support Node (2G/3G)  Mobility Management Entity (4G)  Control signalling − Admission control, Authentication − Mobility, roaming  Payload transport (not in 4G) 10

  11. SGSN SGSN-MME MME MkVI MkVI • 3 sub-racks • 21 blades (2+19) • 2 core PowerPC • ~ 114 simultaneously running processes • Backplane: 1Gbps • Capacity: 3MSAU 11

  12. SGSN SGSN-MME MME MkVI MkVIII II • 3 sub-racks • 14 blades (2+12) • 6 core Intel x86  12 SMT threads total • ~ 432 simultaneously running processes • Backplane: 1 or 10Gbps • Capacity: 10MSAU 12

  13. SGSN SGSN-MME MME – Archite Architecture cture Sketch Sketch NCB NCB FSB FSB ...... AP AP AP ... DP DP DP 13

  14. SGSN SGSN-MME MME – Use Use The Right Tool The Right Tool • Control Plane  Erlang − concurrency − distribution − fault-tolerance  DSL − frameworks for protocol implementation • User Plane  C  time-critical 14

  15. Erlang Erlang – The Functional Advantage The Functional Advantage • Protocol Programming  3GPP standards  Domain experts not software engineers • DSL  A “library” of abstractions − Possible in any language − Often easier in a functional language  A set of combinator “glues” − Considerably more powerful in a functional language 15

  16. Typical Concurrency Typical Concurrency Patterns Patterns • One mobile – one process (replicated worker)  Isolation  Synchronisation only with resources • Central resources  Resource allocator  Master/coordinator – slave/worker  Transaction handler 16

  17. Distribution Distribution • One mobile – one process  Evenly distribute all phones over all blades  Replicate data for fault-tolerance • Central resources  Run on the master-blade  Replicate to all the slaves  Can we survive without a master? 17

  18. Fault Fault-tolerance tolerance • SGSN-MME requirement: 99.999% availability • Hardware  Faulty blades are automatically taken out of service  Mobile phones redistributed • Software  Fail fast – offensive programming  Recovery strategy 18

  19. Fault Fault-tolerance tolerance – Softw Software are • Phone process crash should never affect others  Automatic memory handling  Process monitoring • Recovery Strategy – escalate  Restart the phone process  Restart the whole blade  Restart the whole node 19

  20. Sieve Sieve of Er of Eratos atosthenes thenes Architecture • N+1 pipeline channels nums • One shared output channel filter1 filter2 filterN output print eat PPVT10 – Message Passing 46 20

  21. Pipeli Pipeline o ne of Proc f Processes esses NCB AP_1 AP_2 AP_N LOG logging 21

  22. Hask Haskell ell Patterns Patterns – Monads Monads • Good  Keeps pure and side-effecting computations apart − Good separation of concerns − Improved compositionality − Possible performance gain  Gather writes together and write to DB once – amortise the cost of transactions: − 1 item write costs 10 − 10 items write is not 100 but only 20! 22

  23. Hask Haskell ell Patterns Patterns – Monads Monads • Bad  In rapid prototyping it can present a big hurdle to jump over  So, it is good that Erlang does not have static types  Lazy evaluation is more complicated in the presence of side-effects especially inter-process communication 23

  24. OO OO-Design P Design Patterns atterns • Factory method  Improve memory sharing • Object pool  Bounded parallelisation of algorithms – thread pool  Overload protection 24

  25. What they do not teach you What they do not teach you • Software lives long  Especially telecom systems (decades)  Banking systems live even longer (think C OBOL ) • People change • Organisations change • Hardware changes • Requirements change • Documentation often does not change 25

  26. Softw Software are Maintenance Maintenance • The developer’s challenge  Write simple (readable) and efficient code: Write a straightforward and working solution first 1. Optimise later (or even better skip this step) 2. • Think smart but do not over-optimise  Optimisations complicate maintenance • The code is often the only reliable document  Types can be very good documentation 26

  27. Synthesis Synthesis and Analysis and Analysis • Emphasis on synthesis in education  Software development from scratch • Industrial systems often have a legacy  Software development by further iteration − Refactoring − Code review − Software maintenance  Need for both analytical and synthesizing thinking 27

  28. Synthesis Synthesis and Analysis and Analysis • Roughly 30% of manpower is spent on testing  Analytical work  Do you like to break a system? • But testing can also be “synthesizing”  Testing frameworks − Quickcheck − SGSN-MME has its own  Would you like to formally prove the system correct? 28

  29. Erlang in Pra Erlang in Practic ctice e – Pros Pros • Well suited for  Control handling of telecom traffic  Application layer (OSI model) applications − Web servers, etc.  Domain Specific Language – framework − Test scripting • Reasonably high-level (as compared to for example C)  Good for software maintenance 29

  30. Erlang in Pra Erlang in Practic ctice e – Pros Pros • Dynamic typing  Aids rapid prototyping • OTP – includes useful building blocks  Supervisor  Generic server  Finite state machine 30

  31. Erlang in Pra Erlang in Practic ctice e – Cons Cons • Hard to find good Erlang programmers (?)  Management b......t  Long live Chalmers • A bit too low-level language  Given current HW limitations one must sometimes optimise to the point where the code is not portable (with the same performance)  Raise the abstraction and provide a customisable compiler, VM (Elixir?) 31

  32. Erlang in Pra Erlang in Practic ctice e – Cons Cons • Where is the type system?  A static type system of Haskell-nature would probably be a hindrance  But good static analysis tools are desperately needed  Types are an excellent form of documentation 32

  33. More T More Than True han True Sayings • The greatest performance improvement of all is when a system goes from not-working to working • The only thing worse than a problem that happens all the time is a problem that doesn't happen all the time PPVT10 – Introduction 54 33

  34. Functional P Functional Progra rogramming mming • Widespread use  Embedded (cars, satellites, etc.), web-apps, games, banks, big- data, … • Abstractions and compositionality • Productivity gains 34

  35. The Industria The Industrial l Experienc Experience • It is more difficult that you expect, but  Usually not in complexity but size • Good methodical approach helps • Lateral thinking is an asset  Learn many programming paradigms  Learn many programming languages 35

Recommend


More recommend