• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Are High Level Programming Languages for Multicore and Safety Critical Converging? af Bent Thomsen, CISS/AAU
 

Are High Level Programming Languages for Multicore and Safety Critical Converging? af Bent Thomsen, CISS/AAU

on

  • 944 views

Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Højniveausprog til Indlejrede Systemer den 2. oktober 2013. Læs mere om interessegruppen her: ...

Oplægget blev holdt ved et seminar i InfinIT-interessegruppen Højniveausprog til Indlejrede Systemer den 2. oktober 2013. Læs mere om interessegruppen her: http://infinit.dk/dk/interessegrupper/hoejniveau_sprog_til_indlejrede_systemer/hoejniveau_sprog_til_indlejrede_systemer.htm

Statistics

Views

Total Views
944
Views on SlideShare
822
Embed Views
122

Actions

Likes
0
Downloads
2
Comments
0

2 Embeds 122

http://infinit.dk 88
http://www.infinit.dk 34

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Are High Level Programming Languages for Multicore and Safety Critical Converging? af Bent Thomsen, CISS/AAU Are High Level Programming Languages for Multicore and Safety Critical Converging? af Bent Thomsen, CISS/AAU Presentation Transcript

    • Are High Level Programming Languages for Multicore and Safety Critical Converging?  Bent Thomsen  Aalborg University InfinIT interest group on  high level languages in embedded systems  Meeting on 2.9.2013
    • Computers in the good old days 2
    • … in the beginning of time 3
    • Computers for a long while looked like this “Computers are grey boxes full of black smoke. When the black smoke escapes The computer doesn’t work anymore” - Anonymous computer science student 4
    • Computers nowadays … 5
    • And where did they all go ?
    • A programmer’s view of computers This model was pretty accurate in 1985. Processors (386, ARM, MIPS, SPARC) all ran at 1–10MHz clock speed and could access external memory in 1 cycle; and most instructions took 1 cycle. Indeed the C language was as expressively time-accurate as a language could be: almost all C operators took one or two cycles. But this model is no longer accurate! 7
    • A modern view of memory timings So what happened? On-chip computation (clock-speed) sped up faster (1985–2005) than offchip communication (with memory) as feature sizes shrank. The gap was filled by spending transistor budget on caches which (statistically) filled the mismatch until 2005 or so. Techniques like caches, deep pipelining with bypasses, and superscalar instruction issue burned power to preserve our illusions. 2005 or so was crunch point as faster, hotter, single-CPU Pentiums were scrapped. These techniques had delayed the inevitable. 8
    • The Current Mainstream Processor Will scale to 2, 4 maybe 8 processors. But ultimately shared memory becomes the bottleneck (1024 processors?!?). 9 … introduce NUMA (Non Uniform Memory Access) …
    • Hardware is getting more diverse • Cell – Multi-core with 1 PPC + 8(6) SPE (SIMD) – 3 level memory hierarchy – broadcast communication • GPU – 256 SIMD HW treads – Data parallel memory 10
    • SpiNNaker • 1 million core machine • Globally Asynchronous Locally Synchronous (GALS) • Project lead: Steven Furber, Manchester U. 11
    • The IT industry wakeup call “Multicore: This is the one which will have the biggest impact on us. We have never had a problem to solve like this. A breakthrough is needed in how applications are done on multicore devices.” – Bill Gates, Microsoft Faculty Summit in 2008 • The super computing community discovered the change in hardware first – Already in the mid-late 80’ies • Mainstream of the computing industry is frantically working on the problem • Embedded systems: – Some have started to worry 12
    • Consequences of the changing HW • To use the new hardware efficiently: – Algorithms should do most work on local data !! – Programmers need to • • • • make decisions on parallel execution know what is local and what is not need to deal with communication Know on which core to run – Programmers have to exploit: • Data Parallelism and memory parallelism • Task parallelism and instruction parallelism – Programmers need to make decisions on resources: • changing the clock speed, energy aware, money aware 13
    • But how can the poor programmer ensure this? • The programmer can struggle on using C/C++ with a bewildering set of libraries and variants: – POSIX threads, OpenMPI, OpenMP, CUDA, … ALTERNATIVELY • New programming model(s) reflecting the new world are called for • New programming language constructs are needed • New analysis tools to help programmers are needed • (New development methods are needed) 14
    • Three Trends • Declarative programming languages in vogue again – Especially functional • Dynamic programming languages are gaining momentum • Concurrent programming languages are back on the agenda 15
    • Declarative Programming • Lots of talk about declarative languages: – Haskell – Scheme, Lisp, Clojure – F#, O’Caml, SML – Scala, Fortress • Lots of talk about declarative constructs in traditional languages – C# (and Java and C++) 16
    • What do we mean by declarative/functional? • Say what you want, without saying how Or as Anders Heilsberg, Inventor of C#, puts it: ”programmers need to talk less about how to do things and more about what they want done and have computers reason it out." 17
    • Quicksort in C 18
    • Quicksort in Haskell qsort [] = [] qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs) 19
    • What do we mean by declarative/functional? • Say what you want, without saying how • • • • • • Functions as first class entities Lazy or(/and) eager evaluation Pure vs. impure Value oriented (vs. state oriented) Pattern matching Generics (or parametric polymorphism) 20
    • Mainstream programming is going declarative In 2005 Anders Heilsberg (designer of C#) said: ``Generally speaking, it's interesting to think about more declarative styles of programming vs. imperative styles. ... Functional programming languages and queries are actually a more declarative style of programming''. ``programmers have to unlearn .. and to learn to trust that when they're just stating the ``what'' The machine is smart enough to do the ``how'' the way they want it done, or the most efficient way''. - Anders Hejlsberg http://www.microsoft-watch.com/content/operating_systems/the_father_of_c_on_the_past_present_and_future_of_programming.html 21
    • C# 3.0 Features – – – – – – – – – – – Implicitly Typed Local Variables Lambda Expressions Anonymous Types Expression Trees Query Expressions Extension Methods Object Initializers Collection Initializers Iterators Lazy streams Nullable value types – C# 2.0 already has: • Generics • Structured Value Types • First class anonymous functions (called delegates) 22
    • F# • A .NET language (developed by Don Syme) – Functional language with .Net OO model – Connects with all Microsoft foundation technologies – 3rd official MS language shipped with VisualStudio since VS2010 • Aims to combine the best of Lisp, ML, Scheme, Haskell, in the context of .NET – Actually based on O’Caml • Functional, math-oriented, scalable • Aimed particularly at the "Symbolic Programming" niche at Microsoft 23
    • Java Future • Since its launch in 1995 Java has been the darling of Industry and Academia • Java is now almost 20 years old • Pace of language innovation slowing down – Java 6 SE released Dec. 2006 – Java 6 EE released Dec. 2009 • Java 7 SE / JDK 7 – Work started in 2006 – Forecast Feb. 2010 – Released July 28th, 2011 • Java 8 was expected in October 2012 24
    • Java 7 Features • • • • • • • Strings in switch Automatic resource management in try-statement Improved type inference for generic instance creation Simplified varargs method invocation Binary integer literals Allowing underscores in numeric literals Catching multiple exception types and rethrowing exceptions with improved type checking • Lambda expressions postponed to Java 8 !! 25
    • Beyond Java "A Conversation With Guy Steele Jr." Dr. Dobb's Journal (04/05) Vol. 30, No. 4, P. 17; Woehr, Jack J. Guy Steele theorizes that programming languages are finite, and argues that the time is right for a successor to Java, which has another two decades of life left. Sun is investigating whether aligning programming languages more closely to traditional mathematical notation can reduce the burden for scientific programmers Guy Steele co-wrote the original Java specifications and in 1996 was awarded the ACM SIGPLAN Programming Language Achievement Award. Steele is a distinguished engineer and principal investigator at Sun Microsystems Laboratories, where he heads the company's Programming Language Research Group. 26
    • Fortress • One of the three languages DARPA spent 1BN$ on – Actually SUN only got 49.7M$ (IBM and CRAY got the rest) • • • • First class higher order functions Type inference Immutable and mutable variables Traits – Like Java interfaces with code, classes without fields • Objects – Consist of fields and methods • Designed to be parallel unless explicit sequential – For loops and generators, tuples – Transactional Memory – PGAS (Partitioned Global Address Space) • Runs on top of the JVM 27
    • Scala • Scala is an object-oriented and functional language which is completely interoperable with Java – Developed by Martin Odersky, EPFL, Lausanne, Switzerland • Uniform object model – – – – • • • Everything is an object Class based, single inheritance Mixins and traits Singleton objects defined directly Higher Order and Anonymous functions with Pattern matching Genericity Extendible – All operators are overloadable, function symbols can be pre-, post- or infix – New control structures can be defined without using macros 28
    • Clojure • Concurrent Lisp like language on JVM – Developed by Rich Hickey • Functions are first-class values • Everything is an expression, except: – Symbols – Operations (op ...) – Special operations: • def if fn let loop recur do new . throw try set! quote var • Code is expressed in data structures – Clojure is homoiconic homoiconicity is a property of some programming languages, in which the primary representation of programs is also a data structure in a primitive type of 29 the language itself - Wikipedia
    • Dynamic Programming • Lots of talk about dynamic languages – – – – – – – PhP, Perl, Ruby JavaScript Lisp/Scheme Erlang Groovy Clojure Python • jPython for JVM and IronPyhon for .Net • Real-programmers don’t need types 30
    • 31
    • Dynamic Language characteristics • (Perceived) to be less verbose – Comes with good libraries/frameworks • • • • Interpreted or JIT to bytecode Eval: string -> code REPL style programming Embeddable in larger applications as scripting language • Supports Higher Order Function! • Object oriented – JavaScript, Ruby and Python – Based on Self resp. SmallTalk • Meta Programming made easier 32
    • Dynamic Programming in C# 4.0 – Dynamic Lookup • A new static type called: dynamic • No static typing of operations with dynamic • Exceptions on invalid usage at runtime dynamic d = GetDynamicObject(…); d.M(7); // calling methods d.f= d.P; // getting and settings fields and properties d[“one”] = d[“two”]; // getting and setting thorughindexers Int i= d + 3; // calling operators string s = d(5,7); // invoking as a delegate – Optional and Named Parameters – COM interop features – (Co-and Contra-variance) 33
    • Concurrent Programming • Lots of talk about Erlang • Fortress, X10 and Chapel • Clojure • Actors in Scala • Java.util.concurrency • • • • C omega F# / Axum .Net Parallel Extensions C# 5.0 async 34
    • The problem with Threads • Threads – – – – Program counter Own stack Shared Memory Create, start (stop), yield .. • Locks – Wait, notify, notifyall – manually lock and unlock • or implicit via synchronized – lock ordering is a big problem – Granularity is important – Not compositional 35
    • Several directions • (Software) Transactional Memory – Enclose code in begin/end blocks or atomic blocks – Variations • specify manual abort/retry • specify an alternate path (way of controlling manual abort) – Java STM2 library – Clojure, Fortress, X10, Chapel 36
    • Message Passing/Actors – Erlang – Scala Actors – F#/Axum – GO! – DART 37
    • Theoretical Models • • • • • Actors CSP CCS pi-calculus join-calculus • All tried and tested in many languages over the years, but … 38
    • Problems with Actor like models • • • • Actors (Agents, Process or Threads) are not free Message sending is not free Context switching is not free Still need Lock acquire/release at some level and it is not free • Multiple actor coordination – reinvent transactions? – Actors can still deadlock and starve – Programmer defines granularity by choosing what is an actor 39
    • Async in C# 5.0 40
    • Other concurrency models • Dataflow – Stream Processing Functions • Futures • Tuple Spaces • Stop gap solutions based on parallelised libraries and (embedded) DSLs e.g. for GPU • Lots of R&D (again) in this area!!! 41
    • Other trends worth watching • Development methods – – – – – Away from waterfall, top-down Towards agile/XP/Scrum Refactoring Frameworks, Patterns test-driven-development • Tools – Powerful IDEs with plug-ins – Frameworks – VM and OS integrations • MS PowerShell, v8 in Android 42
    • Other trends worth watching • Semantics is back on the agenda – SOS/Calculi for Fortress, Scala, F# … (java and C#) • Even C/C++ now described using SOS ! – Advanced type systems and type inference • Program Analysis and verification – – – – – – JML and SPEC# (Design by contract) SPIN, Blast ProVerif (Microsoft) JavaPathfinder (NASA, Fujitsu) WALA (IBM), Soot Framework UPPAAL 43
    • Programming multi-core • • • • • Understanding of HW has (again) become necessary New ways of programming is back on the agenda Lots of new constructs in older programming languages Lots of new programming languages No unified approach to concurrency: – Shared memory – Message passing – Hidden in well engineered libraries • Many need to deal with resources – Time, power, money • Worries about correct behaviours is more up-front – Tools are entering mainstream 44
    • Computers nowadays … 45
    • Embedded hard real-time safety-critical systems • Programmers – Spilt the system into a set of handlers – Deal explicitly with concurrency – Need to make decisions on what is local and what is not – Need to deal with synchronizations and priorities – Need to know about hardware – Need to analyse resource use • Time, memory, battery – Need to ensure correct behaviour 46
    • Embedded hard real‐time  safety‐critical systems – Nuclear Power plants, car‐control systems, aeroplanes etc. – Embedded Systems • Limited Processor power • Limited memory • Resources matter! – Hard real‐time systems • Timeliness  – Safety‐critical systems • Functional correctness – Grundfos pumps and SKOV pig farm air conditions – Aalborg Industries (ship boilers) and Gomspace (satellites)
    • Embedded Systems • Over 90% of all microprocessors are used for real‐ time and embedded systems – Market growing 10% year on year • Usually programmed in C or Assembler – Hard, error prone, work – But preferred choice • Close to hardware • No real alternatives – Difficult to find new skilled programmers • Jackson Structured Development (1975) still used • EE Times calling for re‐introducing C programming at US Uni
    • We need to look for other languages • • • • The number of embedded systems is growing Time to market is getting shorter More reliable systems are needed Increase productivity – Software engineering practices (OOA&D) – 10% – Tools (IDEs, analyzers and verifiers) – 10% – New Languages ‐700% • 200%‐300% in embedded systems programming (Atego)
    • Java • Most popular programming language ever ! – In 2005 Sun estimated 4.5 million Java  programmers – In 2010 Oracle estimated 9 million Java  programmers – 61% of all programmers are Java programmers • Originally designed for settop‐boxes • But propelled to popularity by the internet http://jaxenter.com/how‐many‐java‐developers‐are‐there‐10462.html
    • What is the problem with Java? • Unpredictable performance – Memory • Garbage collected heap – Control and data flow • • • • Dynamic class loading Recursion Unbounded loops Dynamic dispatch – Scheduling – Lack high resolution time • JVM – Good for portability – bad for predictability
    • Real‐Time Java Profiles • RTSJ (JSR 001) – – – – • Safety‐Critical Java (draft) (JSR 302) – – – – – • The Real‐Time Specification for Java An attempt to cover everything  too complex and dynamic Not suitable for high integrity systems Subset of RTSJ Focus on simplicity, analysability, and certification No garbage collection: Scoped memory Missions and Handlers (and some threads) Implementation: sub‐classes of RTSJ Predictable Java – Super classes for RTSJ – Simple structure – Inspiration for SCJ
    • Predictable JVM • JOP – Java Optimized Processor – JVM in Hardware (FPGA) • HVM – – – – – targeted at devices with 256 kB flash and 8kB of RAM Interpreted or AOT compilering 1st level interupt handlers in Java supports all Java byte codes, except float and double Runs on ATmega2560, CR16C and x86 • JamaicaVM – Industrial strength real‐time JVM from Aicas – Enroute for Certification for use in Airplanes and Cars 
    • The HVM Java‐to‐C compiler with an embedded interpreter Java look‐and‐feel for low‐end embedded devices Support incremental move from C to Java 55
    • What about Time Analysis? • Traditional approaches to analysis of RT systems are hard and conservative Utilisation-Based Analysis • A simple sufficient but not necessary schedulability test exists U  N  i 1 Ci  N ( 2 1 / N  1) Ti U  0.69 as N   Where C is WCET and T is period 41 Response Time Equation R  R i  C i    i C j j  hp ( i ) T  j Where hp(i) is the set of tasks with priority higher than task i Solve by forming a recurrence relationship: w in  1  C i  0  j  hp ( i ) 1 2  w in   Tj  C  j n The set of values wi , wi , wi ,..., wi ,.. is monotonically non decreasing When win  win 1 the solution to the equation has been found, wi0 must not be greater that Ri (e.g. 0 or Ci ) 42 • Very difficult to use with Java because of JVM (and Object Orientedness)
    • Model based Analysis – TIMES • Model based schedulability tool based on UPPAAL – WCA • WCET analysis for JOP – SARTS • Schedulability on JOP – TetaJ • WCET analysis for SW JVM on Commodity HW – TetaSARTS • Schedulability analysis for SW JVM on Commodity HW and JOP 57
    • TetaJ • WCET analysis tool – taking Java portability into account • • • • Analysis at method level Can be used interactively Takes VM into account Takes HW into account 58
    • 59
    • 60
    • TetaSARTS 61
    • Minepump example 62
    • Minepump example Write once – run whereever possible 63
    • Energy Optimize Applications
    • Trends worth watching • Inspiration from X10 in SCJ lead to better  performance • STM has been put forward • Libraries designed for WCET • Declarative and dynamic language features?
    • What about all the new declarative and dynamic stuff? • Higher Order Programming – Elegant programming styles – Harder to analyse control flow – Usually implies use of GC • Dynamic Programming – Lots of run-time checks – Harder to analyse type violations 66
    • Other trends worth watching • Semantics is back on the agenda – SOS/Calculi for java – Advanced type systems and type inference • Program Analysis and verification – – – – – JML (Design by contract) Key (Aicas) JavaPathfinder (NASA, Fujitsu) WALA (IBM), Soot Framework UPPAAL 67
    • Other trends worth watching • Development methods – – – – – Away from waterfall, top-down Towards agile/XP/Scrum Refactoring Frameworks, Patterns test-driven-development • Tools – Powerful IDEs with plug-ins – Frameworks – VM and OS integrations 68
    • Are Safety Critical and Multicore Converging Trends? • I think the answer is yes • Did I convince you? • Questions – please ! • Thank you for your attention 69
    • Hardware support for CSP on a Java chip multiprocessor Flavius Gruian, Martin Schoeberl, Hardware support for CSP on a Java chip multiprocessor, Microprocessors and Microsystems, Volume 37, Issues 4–5, June–July 2013, Pages 472-481, ISSN 0141-9331, http://dx.doi.org/10.1016/j.micpro.2012.08.004. (http://www.sciencedirect.com/science/article/pii/S0141933112001585) 70