190 likes | 209 Vues
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
E N D
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 • Components can be combined in various ways to execute different applications • Each component can execute simultaneously*
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
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
Test Benchmark JPEG Encoding Components needed to convert a bitmap into a JPEG
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….
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>
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
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
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)
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*
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>
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
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