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
Example Windows
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
Example Component
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
Routine
Execution Percentage
Color Conversion
30%
Huffman Encoding
26%
Quantization
26%
Forward DCT
13%
“Speedup” over baseline
1.2
Speedup
1
0.8
0.6
4
2
0.4
1
0.2
0
2K
4K
8K
16K
Buffer Size
32K
64K
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
Speedup over single-cpu execution
Multiprocessor Scaling
100.0%
90.0%
80.0%
70.0%
60.0%
50.0%
40.0%
30.0%
20.0%
10.0%
0.0%
2
4
2K
4K
8K
16K
Buffer Size
32K
64K
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)
Questions
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