SlideServe
Menu
Préférences
© SlideServe · v2026

Component-Based Programming with Streams

amycjohnson avatar
19 diapositives · 233 Views · Jan 02, 2020

Component-Based Programming with Streams. Philip Garcia University of Wisconsin - Madison Johannes Helander Microsoft Research. Component Based Programming. Program viewed as a collection of autonomous components Each component performs a single task

Component-Based Programming with Streams - slide 1
01 / 19Component-Based Programming with Streams
1 / 17

Télécharger la présentation

Component-Based Programming with Streams
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. Component-Based Programming with Streams Philip Garcia University of Wisconsin - Madison Johannes Helander Microsoft Research

  2. Component Based Programming • Program viewed as a collection of autonomous components • Each component performs a single task • Components can be combined in various ways to execute different applications • Each component can execute simultaneously*

  3. Component-based design Overall system design described in XML Describe individual components Describe Components interconnection Describe application as interconnection of components Components Written in “traditional” languages (C/C++) Interface with buffer streams Stream elements accessed using buffer “windows” System automatically handles concurrency when window is advanced, or changes in size

  4. Example Windows

  5. Data Windows • Virtualize accesses into data buffers that exist between components • Dynamically handles concurrency between components • Allows array-like access into shared buffers • However, accesses must occur within the defined window • Window can expand, shrink, or advance • Windows can not move backward

  6. Example Component

  7. Test Benchmark JPEG Encoding Components needed to convert a bitmap into a JPEG

  8. Application’s XML Description <AppStream xmlns="http://tempuri.org/X-Buffer/0.01"> <Stream> <Component type="COB\CFromPPM.cob" name="Source" init="true"/> <Component type="COB\CColorConv.cob" name=“Conv" init="false"/> <Component type="COB\CFDCT.cob" name=“DCT" init="false"/> <Component type="COB\CQuant.cob" name=“Quant" init="false"/> <Component type="COB\CHuff.cob" name=”Drain" init="false"/> </Stream> <Chain> <link><name>Source</name><Win>0</Win></link> <link><name>Conv</name><Win>1</Win></link> </Chain> contd….

  9. Description continued <Chain> <link><name>Conv</name><Win>0</Win></link> <link><name>DCT</name><Win>1</Win></link> </Chain> <Chain> <link><name>DCT</name><Win>0</Win></link> <link><name>Quant</name><Win>1</Win></link> </Chain> <Chain> <link><name>VQuant</name><Win>0</Win></link> <link><name>Wdrain</name><Win>0</Win></link> </Chain> <Initializer>SestupJPEG</Initializer> </AppStream>

  10. JPEG Profile • Obtained profiling data in Linux using gprof • Baseline ran under windows using MS VS compiler • Windows execution time (256MB input): 7.33s • Linux execution time (256MB input): 4.05s

  11. “Speedup” over baseline

  12. Poor Scaling • MMLite Development environment was not designed for windows • Embedded systems development • Windows support was an afterthought added for debugging • Heavy-weight communication primitives • Compiler Optimizations ? • Need to obtain a good windows profiling tool • Find performance bottlenecks

  13. Multiprocessor Scaling

  14. Thoughts on Application Porting • Using pre-built buffer streams greatly simplified development • Resulting code was much simpler than the original baseline • Additional options can be added by swapping out components (rather than setting flags)

  15. Questions

  16. Specifying Components • Each component implements a standard interface. • Initialization • Execution • XML file describes system • Lists all components used • Describes communication between components • Specifies Initialization routine*

  17. Example <AppStream xmlns="http://tempuri.org/X-Buffer/0.01"> <Stream> <Component type="COB\CFromEP.cob" name="Source" init="true"/> <Component type="COB\Base64Encoder.cob" name="Encode" init="false"/> <Component type="COB\CToEP.cob" name="Drain" init="true"/> </Stream> <Chain> <link><name>Source</name><Win>0</Win></link> <link><name>Encode</name><Win>0</Win></link> </Chain> <Chain> <length>2</length> <link><name>Encode</name><Win>1</Win></link> <link><name>Drain</name><Win>0</Win></link> </Chain> <Initializer>SetupEP</Initializer> </AppStream>

  18. How do we define components? • Each component written in traditional language • Allows reuse of existing routines and algorithms • Programmers are familiar with environment • Currently only support components written in C • Plan to add support for Hardware-based components

  19. System Execution • System compiles XML description into C • Initializes each component • Initializes buffer streams/windows • Can run each component as separate thread • Statically or dynamically schedules threads • Eventual goal is to allow components to be software or hardware