1 / 8

Think Join An extension to Think for programming parallel streaming applications

Think Join An extension to Think for programming parallel streaming applications. Fr éderic Mayot, Matthieu Leclercq, Erdem Özcan. Streaming applications on MPSoC. Functional considerations Enabling more parallelism Mastering the distribution Supporting different execution models

morton
Download Presentation

Think Join An extension to Think for programming parallel streaming applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Think JoinAn extension to Think for programming parallel streaming applications Fréderic Mayot, Matthieu Leclercq, Erdem Özcan

  2. Streaming applications on MPSoC • Functional considerations • Enabling more parallelism • Mastering the distribution • Supporting different execution models • Software engineering considerations • Easier programming models • Separation of concerns • Improved the reuse and mastered evolution • Management of software assets

  3. Decoded I image Synchronization Image I Decoder I Decoded video stream Encoded videao Stream Image I décodée Dispatcher Display Decoder P Image P Decoded P image Streaming strategies void dispatch() { while (Buffer.NotFull) Buffer.push(imgI); } ImageI getImgDecI() { return Dispatcher.getImgI(); } Buffer void decodeP() { while (Buffer.NotEmpty) { imgI = Buffer.pull(); Buffer2.push(Dec(imgI)); } } ImageI getImg() { return DecI.getImgDecI(); } • Programming flows: approaches • The “pull” way • Strong coupling • Too many synchronizations for good parallelism • The “push” way : Filters pipelining through buffers • Weak coupling • Difficult to deal with many asynchronous events. • Proposition • Mastering the asynchronous push model • Join Calculus based synchronization language

  4. Décodeur I Dispatcher Afficheur Décodeur P Computation model • Synchronization via join patterns Set of messages received  reaction invocation • Language ThinkJoin void pushImgI(ImageI img) & void pushImgP(ImageP img) { /* decode */ } Message Rule ift1.pushImgI (img1) & itf2.pushImgP (img2) => itf3.decode (img1, img2); ift1.pushImgI (img1) & itf4.synch () => itf5.display (img1); Pattern Reaction

  5. <definition name=“functional”> <interface name="itf3" role="server" /> <content class="reaction" language=“thinkMC" /> </functional> ADL functional.c <definition name=“controller”> <interface name="itf1" role="server" /> <interface name="itf2" role="server" /> <interface name="itf3" role="client" /> <content class="rules" language="join" /> </definition> ADL Implémentation controller.rules <definition name="cmp"> <interface name="itf1" role="server" /> <interface name="itf2" role="server" /> <component name=“functional” … > </component> <component name=“controller” … > </component > <binding client="this.itf1" server="ctl.itf1" /> <binding client="this.itf2" server="ctl.itf2" /> <binding client=“ctrl.react" server=“fn.reeact" /> </definition> Controler Functional ADL Integration into Fractal ADL void pushImgI (img); void decode (img1, img2); void pushImgP (img); Automatically generated by the compiler from the rule : ift1.pushImgI (img1) & itf2.pushImgP (img2) => itf3.decode (img1, img2);

  6. i2 i1 FSM i3 i4 B B F F D A D C C E How does-it work ? i1.A() & i3.E() => ir.r1(); i1.B() & i2.C() => ir.r2(); i2.D() & i4.F() => ir.r3(); public interfaceI2 { voidC (); void D (); } • FSM execution example • Think-v3 ADL compiler extension • Computation model inspired by Join calculus (cf. Fournet et al.) • Tightly modified to have FIFO order within bindings • Implementation • Formalization by Finite State Machines (cf. Maranget et al.) • Encoding and pattern matching with bit masks to have linear complexity • Using circularbuffers and synchronization primitives public interfaceI1 { voidA (); void B (); } public interfaceI3 { voidE (); } public interfaceI4 { voidF (); } i2 i4 i1 i3

  7. pushI(img2) pushI(img2) pushP(img1) pushP(img1) … … 10 {img1, img2} FSM  … … 7 {decode, 10} Execution models • Various execution types • Synchronous • Asynchronous • Threads pool • Only one parameter to switch • Depends on each component i2 decode(img1, img2) FSM i1 i3 Réactions match execute({decode, 10}) i1.pushP(img1) & i2.pushI(img2) => i3.decode(img1, img2); Scheduler register(FSM, {decode, 10})

  8. MC Y Motion Comp. MC U MC V Picture Dec Framestore Header Dec Adder Exporter IDCT Evaluation on a MPEG2 decoder idct_mb_type.intra_mb() & idct_mb.push_mb(mb_data) => r.add(mb_data); idct_mb_type.non_intra_mb() & idct_mb.push_mb(mb_data) & mc_y.prediction_finished() & mc_u.prediction_finished() & mc_v.prediction_finished() => r.add(mb_data); Over cost (FSM, scheduling, serialization) Objectives reached Architecture Collaboration Repartition Next: more formal language, better efficiency Perf. Threads

More Related