1 / 19

Component-Based Programming with Streams

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

amycjohnson
Télécharger la présentation

Component-Based Programming with Streams

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. 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

More Related