Tackling Algorithmic Skeleton’s Inversion of Control

Gustavo PabonGlobal Business Services, IBM Chile,Av. Providencia 655, Santiago, Chile.

gpabon@cl.ibm.com

Mario LeytonNIC Chile Research Labs, Universidad de Chile,

Miraflores 222, Piso 14, 832-0198, Santiago, Chile.mleyton@niclabs.cl

Abstract

Algorithmic Skeletons are a high-level parallel program-ming model which suffers from inversion of control. This pa-per argues that extending Algorithmic Skeletons with Event-Driven Programming (EDP) can reduce the negative sideeffects produced by the inversion of control by: i) provid-ing online information about the runtime execution withoutlowering the skeleton’s high-level abstraction, and ii) fur-ther improve the separation between functional code (mus-cles) and non-functional concerns. The proposed approachis used to implement a logger and an online performancemonitoring tool, and it is shown that the proposed exten-sion incurs a small performance overhead.

1 Introduction

Algorithmic Skeletons[9] (skeletons for short) are ahigh-level programming model for parallel and distributedcomputing, introduced by Cole [4]. Skeletons take advan-tage of recurrent parallel programming patterns to hide thecomplexity of parallel and distributed applications. Start-ing from a basic set of patterns (skeletons), more complexpatterns can be built by nesting the basic ones.

Event-driven Programming (EDP) is a programmingmodel where the program flow is determined by events.EDP has been mainly used on interactive applications, likegraphical user interfaces, and has been successfully usedon real-time and embedded systems [12, 7] thanks to itslightweight implementation and its signal (event) process-ing nature.

This paper proposes a combination of both programmingmodels: Event-Driven Programming (EDP) and skele-tons, with two objectives: i) provide online informationabout the runtime execution without lowering the skele-ton’s high-level of abstraction and ii) improve the separationof concerns between functional code (muscles) and non-functional concerns, in a high-level and efficient manner.

Skeletons use inversion of control [8] where the ac-tual parallel execution flows are hidden from programmersyielding a batch-like processing. Working with intermedi-ate results and information about execution, to implementnon-functional concerns, lowers the programming model’shigh-level abstraction. This paper propose that by trigger-ing events during skeleton execution, intermediate resultsand runtime information can be sent to implement non-functional concerns using event listeners.

Aspect Oriented Programming (AOP) [10] is the pre-ferred and widely used programming model for the designof a clear separation of concerns. This paper shows howAOP concepts are introduced into Algorithmic Skeletonsusing EDP. Both AOP and EDP allow the addition of cus-tom code (advice code in AOP and event handlers in EDP)in specific points on the control flow of a program (joinpoints in AOP and event hooks in EDP). We have chosento apply AOP concepts using EDP: i) because there is noneed to weave non-functional code as we can statically cre-ate event hooks as part of the Skeleton Framework; ii) inorder to minimize programmer conceptual disruption (oneof the principles presented by Cole in its manifesto [5]), byavoiding the necessity of adding another framework, and insome cases another language.

Separation of concerns is essentially software engineer-ing matter. The proposed separation of concerns recognizesthree different roles: i) skeleton provider: whose job it isto materialize parallelism patterns into skeletons, ii) non-functional provider: who implements other, non-parallel,non-functional features, and iii) business programmer:who uses both skeleton patterns and non-functional featuresto implement the final business application.

We have implemented our proposal in Skandium [13,11]. Skandium is a Java based Algorithmic Skeleton libraryfor high-level parallel programming of multicore architec-tures. Skandium provides basic nestable parallelism pat-terns, which can be composed to program more complexapplications.

This paper is organized as follows. In Section 2 relatedwork is presented. Section 3 discusses algorithmic skele-

ton’s inversion of control. The proposed approach is pre-sented in Section 4. Results are presented in section 5 witha logger and an online performance monitor, including anoverhead analysis. The paper finally concludes in section 6.

2 Related Work

In [1], Aldinucci et al, introduce muskel, a full Javalibrary providing a skeleton based parallel-and-distributedprogramming environment implemented exploiting macrodata flow (MDF) technology, rather than implementationtemplates. The predefined skeleton set in Muskel is com-posed by farm and pipeline skeletons. Aldinucci et al pro-pose annotations and AOP, to extend the possibility forusers to control some non-functional features in a high-levelway. The non-functional concerns discussed includes auto-nomic managers (optimization), portability, security, paral-lelism exploitation properties, and expandability.

The approach we present in this paper considers a widerrange of skeleton patterns and does not require the intro-duction of another programming framework, like AspectJ,which could potentially introduce conceptual disruption tothe programmer while we still apply the main concepts ofAOP.

Another Skeleton Framework that incorporates AOP isSBASCO [6]. SBASCO includes the notion of aspect inconjunction with the original paradigms. Aspects are im-plemented as components and connectors, achieving inthis way an homogeneous and clean implementation sinceskeletons are based on the same model. In the proposedapproach, however, we provide a Skeleton pattern specificbased extension rather than a tertiary generic abstraction.

In [3], such as Eden’s Trace Viewer [2], have focusedon post-mortem performance analysis and visualisation ofthe skeleton’s execution. The approach presented in this pa-per provides a high-level way of achieving online executionanalysis instead of a post-mortem one, as detailed in Sec-tion 5.

3 Inversion of Control Problem

Inversion of control is a design pattern [8] where the“main” code does not control the program’s execution flow.Instead the framework (caller) receives the business code asparameter and decides when and where it is executed. Thisallows common and reusable code being developed inde-pendently from problem-specific code, producing valuableabstraction layers.

Algorithmic Skeleton Frameworks use these abstractionlayers to provide high-level parallelism exploitation pat-terns, hiding the primitives and explicit scheduling of paral-lel and distributed applications.

The cost of this high-level parallel programming abstrac-tion is paid in control over the execution flow. This pro-duces batch-like processing where intermediate results andinformation about execution are hidden from programmers,which can make handling non-functional concerns difficult.

Listing 1 shows an example of a common Skandium pro-gram. Once execution starts there is no mechanism to getinformation of the current execution or to get partial results.

// Skeleton definitionDaC<P,R> skeleton = new DaC<P,R>(

new SpecificCondition(...),new SpecificSplit(...),new SpecificExec(...),new SpecificMerge(...));

// Input parametersFuture<R> future = skeleton.input(new P(...));

// do something else ...

// Wait for resultsR result = future.get();

Listing 1. Batch-like Skeleton Processing

4 Events for Algorithmic Skeletons

This section describes the proposed events extension foralgorithmic skeletons. We begin by describing the sup-ported Event Listener types, then we present the EventHooks where events listeners can be registered and finallywe describe how events are implemented in the execution-level instructions.

4.1 Event Listeners

Programmers must implement any of the following in-terfaces to create a new Event Listener. Each listener typeprovides a different set of information, lowering the abstrac-tion level on a need-to-know basis.

• SimpleListener<P> is the most high-level lis-tener which specifies a guard/handler receiving a pa-rameter P passed between skeletons and muscles atsome point in the computation.

• TraceListener<P> additionally specifies aSkeleton[] trace containing as its first element theroot skeleton of a nested skeleton composition, and asits last element the currently executed element. Thisis useful when the event listener is registered in morethan one part of the skeleton nesting tree.

• IndexListener<P> additionally specifies an inte-ger parameter as a result of context inferred indexessuch as in pipe stages; or map, fork and d&c splits.

Parameters Received Skeletons

Simple Listener

Trace Listener

Index Listener

Condition Listener

Generic Listener

Parameter P All Skeletons

+ Skeleton trace All Skeletons

+ Context inferred indexes

pipe, for, while, map, fork, d&c

+ Condition result if, while, d&c

+ Event hook identifiers (when and where) All Skeletons

Tabla 1. Versión 1

Friday, November 18, 2011

Table 1. Comparison of Listener’s type

• ConditionListener<P> additionally specifies aboolean parameter as a result of Condition muscles inif, while and d&c skeletons

Table 1, listener’s type comparison, shows the differentparameters sent by type and shows the Skeletons supportedby each type.

Listing 2 provides an example of how a programmer mayimplement an Event Listener using the given interfaces.

class MyListener implements TraceListener<Integer>, ComparableListener{

@Overridepublic int compareTo(SkandiumListener l) {

// do somethingreturn 0;

}

@Overridepublic boolean guard(Integer param, Skeleton[]

strace) {if(...) { return true;}return false;

}

@Overridepublic Integer handler(Integer param, Skeleton

[] strace) {// do somethingreturn param;

}}

Listing 2. Example of Event Listenerimplementation

Programmers also have the possibility of registering/re-moving Generic Listeners. A Generic Listener can be regis-tered in any Event Hook, and can be used to create commonfunctionality for several events, just like point cuts in AOP,at the price of sacrificing type verification. Where the lis-tener is applied on all nested skeletons, registered/removedon all the event hooks that respect filter settings defined bythe following parameters:

Before After

Skeleton !

farm(!)

pipe(!1,!2)

seq(fe)

if(fc,!true,!false)

while(fc,!)

for(n,!)

map(fs,!,fm)

fork(fs,{!}, fm)

d&c(fc, fs,!, fm)

!: P !: R

!: P !: R

!i: Pi , i !i: Ri , i

fe: P fe: R

fc: P!x: Px , x

fc: P , fc(P)!x: Rx , x

fc: P , index!: P , index

fc: P , fc(P) , index!: R , index

!: P , index !: R , index

fs: P!: Pi , ifm: {Ri}

fs: {Pi}!: Ri , ifm: R

fs: P!i: Pi , ifm: {Ri}

fs: {Pi}!i: Ri , ifm: R

fc: P , indexfs: P , index!: Pi , i , indexfm: {Ri} , index

fc: P , fc(P) , indexfs: {Pi} , index!: Ri , i , indexfm: R , index

Friday, November 18, 2011

Table 2. Event hooks

• pattern filters by the Skeleton dimension (e.g.Map.class, so the listener will be registered/removedon all the Map events), the wild card is Skeleton.class.

• when can take the values before or after, the wild cardis null.

• where filters event hooks related to an specific skeletonelement, for example a condition muscle, split muscle,nested skeleton, etc; the wild card is null.

4.2 Event Hooks

Event Hooks define the skeleton pattern based interest-ing locations where additional code could be integrated.Each pattern provides a different set of hooks, and eachhook applies to a specific set of Event Listener types.

Hooks are presented in a before/after semantics. Forexample, all skeletons provide addBefore(...) andaddAfter(...) hooks for SimpleListener andTraceListener, which are triggered before and afterthe execution of the skeleton.

More specific hooks are also available depend-ing on the pattern. For example, the if skele-ton provides addBeforeCondition(...) andaddAfterCondition(...) hooks before and afterthe execution of a condition. Note however that in thisparticular case only the addAfterCondition(...)hook accepts a ConditionListener<P> hook as theboolean parameter only exists after the condition hasbeen evaluated.

Figure 1. Online Performance Monitor

Hooks for before and after nested skeletons are morespecific on each pattern. For example, pipe has two sub-skeletons while if has two and the hooks definition differaccordingly. However, the only type unsafe hooks corre-spond to pipe’s nested parameter. This could be resolved,however, by extending pipe’s definition from Pipe<P,R>to Pipe<P,X,R> to account for the intermediary type.

The semantics of IndexListener’s index parameterare skeleton sensitive. For example, in the for skeleton theindex corresponds to i-th iteration while in the map skeletonthe index corresponds to the i-th element of split’s result.

Table 2 shows the current set of event hooks imple-mented in Skandium. The second and third columns showswhat parameters are sent for each stage of the skeleton’s ex-ecution. The first row implies that all skeletons has a before-and-after event hook. The parameters P and R correspondsto the inpunt and output of each stage.

5 Results

By means of the event hooks and event listeners pre-sented in section 4, the user has access to runtime executioninformation on the fly, including intermediate results; andnon-functional concerns can be implemented with a clearseparation from the functional code (muscles).

5.1 Logger and Online Performance Mon-itoring

As proof of concept of the approach proposed in this pa-per, a logger and a visual performance monitor have beendeveloped.

The logger is a generic tool that could be activatedand deactivated on the fly during a skeleton’s execution.The logger traces relevant information about the executionwhich could be used to identify performance bottlenecks.

Figure 2. Absolute ovehead processing time.

The visual execution monitor is an extension of our pre-vious work [3] which now provides online performancemonitor rather than post-mortem. As shown in Figure 1, foreach muscle and skeleton, the number of invocations andprocessing time spent is updated continuously.

5.2 Overhead Analysis

In this section we show that the ovehead introduced bythe support of events is negligible.

Overhead analysis was made using a parallel QuickSortalgorithm implemented using one divide and conquer skele-ton. Divide and Conquer skeleton generates a variable num-ber of event hooks that is linearly proportional to the size ofthe input. All tests were run on a dual core processor of2.40GHz with 2GB of RAM.

The analysis compares the execution of the same prob-lem with two different versions of Skandium, the one be-fore the events support, and the one that includes events.This analysis calculates the overhead caused only by the in-clusion of the event instructions (event hooks) during thetransformation and reduction steps. Time presented is anapproximation of CPU time.

Figure 2 shows the result of the analysis; The x-axis cor-responds to the number (in millions) of event hooks, whiley-axis shows the overhead calculated (CPU time with eventsminus CPU time of without events). As result we can seea linear increment with a slope of 19,80 seconds for eachmillion of event hooks created. Therefore the overhead is19,80 microseconds per event hook.

Figure 3 shows the relative overhead processing time. X-axis correspond to the problem size in MB. The light graypart of each bar shows the percentage of total CPU timeused to solve the problem, and the dark gray part corre-sponds to the percentage used to interpret the empty eventhooks.

This is the worst case behaviour expected since DaC isthe skeleton that generates the most event hooks propor-

Figure 3. Relative overhead processing time.

tional to the input size. Furthermore the implementationof events in Skandium is itself an embarrassingly parallelproblem and thus in actual parallel execution this overheadis linearly parallelized with respect to the wallclock over-head time.

6 Conclusions

We have extended Algorithmic Skeletons with Event-Driven Programming (EDP), by means of event hooks andevent listeners to i) provide access to users of runtime ex-ecution information on the fly without lowering the skele-ton’s high-level abstraction, and ii) improve on a clear sep-aration of concerns between the non-functional aspects, im-plemented using event handlers, and functional code (mus-cles).

The proposed approach has been verified by implement-ing a logger and a visual performance tool, and our imple-mentation has been measured to have a negligent perfor-mance overhead.

6.1 Future Work

The proposed approach could be used to implement awide range of non-functional concerns such as:

• Audit, control, and reporting. As well as the logger al-ready implemented another controlling and reportingtools could be built in order to address an online qual-ity goals analysis (e.g. processor speed, memory, diskspace, network bandwidth, etc.)

• Error analysis. A full skeleton debugger could be im-plemented. Building a tracer that increases/decreasestrace level online is possible by using the ability of reg-ister and remove listeners dynamically.

• Security. Using the ability of manipulate intermediateresults, algorithms of encryption/decryption could beused during communication.

References

[1] M. Aldinucci, M. Danelutto, and P. Dazzi. Muskel: an ex-pandable skeleton environment. Scalable Computing: Prac-tice and Experience, 8(4):325–341, Dec. 2007.

[2] J. Berthold and R. Loogen. Visualizing parallel functionalprogram runs: Case studies with the eden trace viewer. InPARCO, volume 15 of Advances in Parallel Computing,pages 121–128. IOS Press, 2007.

[3] D. Caromel and M. Leyton. Fine tuning algorithmic skele-tons. In 13th International Euro-Par Conference: ParallelProcessing, volume 4641 of Lecture Notes in Computer Sci-ence, pages 72–81. Springer-Verlag, 2007.

[4] M. Cole. Algorithmic skeletons: structured management ofparallel computation. MIT Press, Cambridge, MA, USA,1991.

[5] M. Cole. Bringing skeletons out of the closet: a pragmaticmanifesto for skeletal parallel programming. Parallel Com-puting, 30(3):389–406, 2004.

[6] M. Dıaz, S. Romero, B. Rubio, E. Soler, and J. M. Troya.Adding aspect-oriented concepts to the high-performancecomponent model of sbasco. In D. E. Baz, F. Spies, andT. Gross, editors, PDP, pages 21–27. IEEE Computer Soci-ety, 2009.

[7] B. P. Douglass. Doing hard time: developing real-timesystems with UML, objects, frameworks, and patterns.Addison-Wesley Longman Publishing Co., Inc., Boston,MA, USA, 1999.

[8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. DesignPatterns: Elements of Reusable Object-Oriented Software.Addison-Wesley Professional, 1995.

[9] H. Gonzalez-Velez and M. Leyton. A survey of algorith-mic skeleton frameworks: high-level structured parallel pro-gramming enablers. Software: Practice and Experience,40(12):1135–1160, 2010.

[10] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda,C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-orientedprogramming. In M. Aksit and S. Matsuoka, editors,ECOOP’97 — Object-Oriented Programming, volume 1241of Lecture Notes in Computer Science, pages 220–242.Springer Berlin / Heidelberg, 1997. 10.1007/BFb0053381.

[11] M. Leyton and J. M. Piquer. Skandium: Multi-core pro-gramming with algorithmic skeletons. In Proceedings of the18th Euromicro PDP, pages 289–296, Pisa, Italy, Feb. 2010.IEEE CS Press.

[12] M. Samek. Practical UML Statecharts in C/C++, SecondEdition: Event-Driven Programming for Embedded Sys-tems. Newnes, Newton, MA, USA, 2 edition, 2008.

[13] Skandium. http://skandium.niclabs.cl/.