under the supervision of christian pérez insa de rennes

Ph.D. Defense by Julien Bigot, December 6th 2010

Generic Support of Composition Operators in

Software Component Models,Application to Scientific Computing

Under the supervision of Christian Pérez

INSA de RennesINRIA Team-Projects PARIS(IRISA) / GRAAL(LIP)

2

Context: Scientific Applications

• Complex applications Coupling of independent

codes→ Developed by distinct teams

Long life-cycle→ longer than hardware

• Computational intensive (HPC),

=> requires complex hardware Supercomputers

Computing clusters

Computing grids

Clouds

Thermal

Optics

Dynamics

Structural Mechanics

SAN SAN

ClusterLAN

WAN

Supercomputer

GridSupercomputer

Cluster

Satellite modeling ? programmingmodels

3

Context:Parallel/Distributed Computing Paradigms

• Shared memory Implementations

→ OS (node level)→ kDDM (cluster level)→ Juxmem (grid level)→ …

DSM

4



→ OS (node level)→ kDDM (cluster level)→ Juxmem (grid level)

• Message passing Implementations

→ MPI→ PVM→ Charm++→ …

Variations→ Collective operations

• Barrier• Broadcast• Scatter• …

5





→ MPI→ PVM→ Charm++


• Remote procedure/methods calls Implementations

→ ONC RPC→ Corba→ Java RMI→ …

Variations→ Parallel procedure call (PaCO++)→ Master / worker (GridRPC)

6





→ MPI→ PVM→ Charm++


• Increased abstraction level Easier programming

Various implementations for various hardware

• Centered on communication medium Application architecture not dealt with

Makes reuse difficult

• Remote procedure/methods calls Implementations

→ ONC RPC→ Corba→ Java RMI

Variations→ Parallel procedure call (Paco++)→ Master / worker (GridRPC)

7

Context:Composition-Based Programming

• Components Black boxes

Interactions through well defined interaction points

• Application Component instance assembly

High level view of architecture

• Implementation Primitive: C++, Fortran, Java

Composite (Assembly)

• Dimension Spatial (classical models)

→ CCA, CCM, Fractal, SCA

Temporal (workflow/dataflow)→ Kepler, Triana

C3

C2 C1

T1 T2

e

cd

a

b

f

8

Context:Composition-Based Programming

• Algorithmic skeletons Predefined set of composition patterns

→ Farm (master/worker)→ Pipeline→ Map→ Reduce→ …

Focus: decoupling→ User:

application related concerns (what)→ Skeleton developer:

hardware related concerns (how)

Implementations→ Multiple libraries→ P3L→ Assist→ …

Farm

9

Context:Components for Parallel Computing

• Parallel/distributed programming paradigms

Hidden architecture

Reuse complex

Hardware resource abstraction

Efficiency on various hardware

• Composition-based models

High-level view of architecture

Eased reuse

Hardware specific assemblies

Parallelism-oriented composition-based model

10

Context:Components for Parallel Computing

• Memory sharing between components CCA & CCM Extensions

• Parallel components CCA, SCIRun2, GridCCM

• Collective communications CCM Extension

• Parallel method calls SCIRun2, GridCCM

• Master / worker support CCA & CCM Extensions

• Some algorithmic skeletons in assemblies STKM

• Two type of features Component implementations

→ ≈ skeletons

Component interactions

11

Context:Existing Models Limitations

• Limited set of features in each model => Combination in a single model

• Unlimited set of features (including application specific) => Extensibility of composition patterns

Thermal

Structural Mechanics

Dynamics

Optics

CollComm

CollComm

12

Context:Problematic

• Goals for an extensible component model

User code reuse

Reusable composition patterns

Reusable inter-component interactions

Efficiency on various hardware

• Required concepts

Components

User-definable skeletons

User-definable connectors

Multiple implementations with hardware-dependant choice

• Problems How to support user-defined skeleton implementations ?

How will all the concepts behave when combined ?

13

Outline

• Context of the Study

• Software Skeletons as Generic Composites

• HLCM: a Model Extensible with Composition Patterns

• HLCM in Practice

• Conclusion

14

Software Skeletons with Components:Motivating Example

coord pixel

• Goal Generating pictures of the

Mandelbrot set

• Embarrassingly parallel problem C = (x,y)

Z0 = 0, Zn+1 = Zn² + C→ Bounded → black→ Unbounded → blue

• Hardware Quad-core processor

• Task farm 4 workers

Input: coordinate

Output: pixel color

15

Software Skeletons with Components:A Component Based Farm

Coord Pixel

CoordDisp

PixColl

MandelWorker

MandelWorker

MandelWorker

MandelWorker

MandelbrotFarm

16

Software Skeletons with Components:Limitations of Component Based Farm

• Hard Coded in the composite Type of the worker

Type of the interfaces

Number of workers

• Limited reuse For a distinct calculation

For distinct hardware

Coord Pixel

CoordDisp

PixColl

MandelWorker

MandelWorker

MandelWorker

MandelWorker

MandelbrotFarm

17

Software Skeletons with Components:A Component Based Farm

Coord Pixel

CoordDisp

PixColl

MandelWorker

MandelWorker

MandelWorker

MandelWorker

MandelbrotFarm

18

Software Skeletons with Components:Introducing Parameters

Coord Pixel

CoordDisp

PixColl

W

W

W

W

Farm<W>

19


I O

Disp Coll<O>

W

W

W

W

Farm<W, I, O>

20


Disp Coll<O>

W

W

W

Farm<W, I, O, N>

.

.

.N timesGeneric

ityI O

21

Software Skeletons with Components:Concepts for Genericity

• Generic artifacts Accept 2nd order parameters

Use the values of parameters in their implementation

public class GenClass<T> {private T _val;public T getVal() {

return _v;}…

}

template<typename T>T increment (T val) {

T result = val;result += 1;

return result;}

Java

C++

GenCmp<C>

C CmpA

22

MyComposite

Software Skeletons with Components:Concepts for Genericity

• Specializations Use of generic artifacts

Arguments bind parameters to actual values

GenClass<String> gs = new GenClass<String>();

String s = gs.getVal();GenClass<Integer> gi = new GenClass<Integer>();…

int i = 42;i = increment<int>(i);

float f = 35.69;f = increment<double>(f);…

Java

C++

GenCmp<MyCmp>

MyCmp

AnotherMyCmp CmpA

23

Software Skeletons with Components:Metamodel-based Transformation

GenericCMMeta-Model

S:GenericCMsource files

D:CM

source filesS Model D Model

CMMeta-Model CM:

Non-generic Supported

GenericCM: Generic Unsupported

component App { content { composite { decl { Decrement_Composite D; Viewer v; Decrement d1; d1.h_log_port -- v.v_log_port; D.h_log_port -- v.v_log_port; d1.dp_dec_port -- D.du_dec_port; d1.du_dec_port -- D.dp_dec_port; set d1.Number 3; } service run { seq { exec d1.export; exec D; } } } }}

component App { content { composite { decl { Decrement_Composite D; Viewer v; Decrement d1; d1.h_log_port -- v.v_log_port; D.h_log_port -- v.v_log_port; d1.dp_dec_port -- D.du_dec_port; d1.du_dec_port -- D.dp_dec_port; set d1.Number 3; } service run { seq { exec d1.export; exec D; } } } }}

Semantically equivalent

GenericCMMeta-ModelParsing Transformation Dump

A

TB<T>

B<A>C

A

AB_0

D

B<D>

B_0C

B_1

DB_1

D

24

Software Skeletons with Components:Deriving a Metamodel with Genericity

• Example Generic artifact

→ ComponentType

Artifact usable as parameter→ PortType

• Additional modifications Default values for parameters

Constraints on parameter values

Explicit specializations

Meta-programming

Port

PortTypeParam

PortTypeArgComponentType

PortType

ComponentInstance

25

Software Skeletons with Components:Transformation

• Specialized compilation C++ approach

Makes template meta-programming possible

• Algorithm Copy non generic elements

For each generic reference→ Create a context

(parameter value)→ Copy the generic element in that

context

A

TB<T>B<A>

C

A AB_0

D B<D>

B_0C

B_1

DB_1D

26

Software Skeletons with Components:Summary

• Defined genericity for component models Straight-forward meta-model extension

Independent of the component model→ SCA (100 class) GenericSCA (+20 class)→ ULCM (71 class) GULCM (+24 class)

• Proposed an approach for genericity execution support Transformation

→ generic model non-generic, executable equivalent

Relies on model-driven engineering approach→ Implemented using Eclipse Modeling Framework (EMF)

• Make skeleton implementation possible Implemented skeletons: task farm (pixel, tile), …

→ Computed pictures of the Mandelbrot set

27

Outline





• Conclusion

28

Combining All Concepts in HLCM:Aims & Approach

• Aims Support user-defined extensions

Hierarchy Genericity→ Interactions: connectors→ Adaptation to hardware: implementation choice

Maximize reuse→ Existing user code => component models

• Approach Abstract model: primitive concepts taken from backend model

→ HLCM Specializations (HLCM + CCM => HLCM/CCM)

Deployment time transformation→ Hardware resources taken into account→ Fall back to backend

→ Skeletons:

29

Combining All Concepts in HLCM:Component Implementation Choice

• Distinguish component type & component implementation

Component type→ Generic→ List of ports

Component implementation→ Generic→ Implemented component type

specialization→ Content description

• Primitive• Composite

• Choice at deployment time Match used specialization &

implemented specialization

Choose amongst possible

CmpA<T>

A2

A1 A3<X>

T=XT=BT=C

CmpA

A3

T=B

component CmpA<component T> exposes {provide<Itf> p;

}

primitive A1implements CmpA{ …}

composite A3<component X>implements CmpA<X>{ …}

30

UP

Combining All Concepts in HLCM:Introducing Connectors from ADLs

• Without connectors Direct connection between ports

Predefined set of supported interactions

• Connectors A concept from ADLs

Connectors reify interaction types→ A Name→ Set of named roles

Instance are called connections→ Each role fulfilled by a set of ports

Fisrt class entity

CmpA CmpB

CmpC CmpD

CmpA CmpB

CmpC CmpDEvent

ports

roles

user provider

31

Combining All Concepts in HLCM:Generators

• Generator = connector implementation

• 1 connector multiple generators

Distinct constraints→ Port types→ Component placement

• Two kinds of generators Primitive

User-defined→ Composite

• Intrinsically generic Type of ports fulfilling roles

generic parameters

UP

interface = UT interface = PT

When PT subtype of UT &&user.host == provider.host

UP

connector UP < role user, role provider >;

generator IPC < interface UT, interface PT >implements UP<user={UT}, provider={PT}>when UT super PT && user.host == provider.host{ Stub<UT> stub; Skel<PT> skel; …}

Skel<PT>UP Stub

<UT>Unix

socket

user provider

IPC

32

SharedData

Combining All Concepts in HLCM:Concepts Interactions

SeqBSeqASeqA SeqB

33

SharedData

Combining All Concepts in HLCM: Concepts Interactions

C0

ParallelA ParallelB

.

.

.

M times

MPI

MPI

.

.

.

N times

C1

CM

D0

D1

DN

Adapt Adapt

0

1

M

0

1

N

C

C

C

D

D

D

34

Shared

Data

Combining All Concepts in HLCM: Concepts Interactions

ParallelA ParallelB

.

.

.

MPI

MPI

.

.

.M times N times

C0

C1

CM

D0

D1

DN

0

1

M

0

1

N

C

C

C

D

D

D

35

Combining All Concepts in HLCM:Introducing Open Connections

ParallelA ParallelB

.

.

.M times

.

.

.N times

SharedData

SharedData

SharedData

SharedData

SharedData

Merge

SharedData

SharedData

SharedData

C

C

C

Merge

Merge

Merge

Merge

Merge

Merge

MPI

MPI

MPI

MPI

MPI

MPI

D

D

D

SharedData

Shared

Data

36


• Connection: Connector

Mapping: role -> set(ports)

• Merge({ ConnA, ConnB }) Pre: ConnectorA == ConnectorB

Each ( role r )→ Mapping: r -> set(Port)A union set(Port)B

• Component Expose named connection

→ Open connection

Composite→ Expose internal connection

Primitive→ Fill exposed connections roles UP

UPUP

merge

UPUP

merge

UP

37


ParallelA ParallelB

.

.

.M times

.

.

.N times

UP

UP

UP

MPI

MPI

MPI

MPI

MPI

MPI

UP

UP

UP

UP UP

User:multiply<MatrixBlock>

User:multiply<Matrix>

Provider:multiply<Matrix>

Provider:multiply<MatrixLine>

38

UP

• Bundle Regroup multiple open connections to fulfill a

role

• Connection adaptor Supports open connection polymorphism

→ Supported connection→ Behavior definition

Two views→ A connection implementation→ An open-connection exposer

Implemented by an assembly Used only if necessary

Combining All Concepts in HLCM:Connection Adaptors & Bundles

adaptor PushPull supports UseProvide < user={Receptacle<Push>}, provider={} > //< supported as UseProvide < user={}, provider={Facet<Pull>} > //< this{ BufferComponent buffer; merge({ buffer.pushSide, supported }); merge({ this, buffer.pullSide });}

Receptable<Push> Facet<Pull >

UPUP UPQ

UP UPQ

Receptable<Push> Facet<Pull >

39

Combining All Concepts in HLCM:Summary

• Approach Abstract model: primitive elements from backend

→ E.g. HLCM + CCM HLCM/CCM

Transformation: HLCM specialization backend→ E.g. HLCM/CCM pure CCM

• Source model (PIM) Four main concepts

→ Hierarchy, genericity, implementation choice, connectors

Additional concepts→ Open connections, merge, connection adaptors, bundles

• Transformation Merge connections (use adaptors if required)

Choose implementation

Expose composite content

• Destination model (PSM) Direct map to backend

Core: 127 Ecore classes

CCM specialization: 3 Ecore classes

41 Ecore classes

40

Outline





• Conclusion

41

Experimental Validation:A Framework for HLCM Implementation

• Model-transformation based Eclipse Modeling Tools

• HLCM/CCM source model (PIM) 490 Emfatic lines (130 Ecore classes) 25 000 generated Java lines

2000 utility Java lines

• HLCM destination model (PSM) 160 Emfatic lines (41 Ecore classes) 1500 generated Java lines

800 utility Java lines

• Transformation engine 4000 Java lines

• Already implemented connectors (HLCM/CCM) Shared Data

Collective Communications

Parallel method calls

42

Experimental Validation:Implementing shared memory

C3

C1

C2SharedMem

C3C1

C2

LocalMemoryStore

LocalUseProvide

provider

role user

generator LocalSharedMem<Integer N> implementsSharedMem< access = each(i:[1..N]) { LocalReceptacle<DataAccess> } >{ LocalMemoryStore<N> store; each(i:[1..N]) { store.access[i].user += this.access[i]; }}

43


C3

C1

C2

PosixSharer

PosixSharer

PosixSharer

UseProvide

role user role provider

Locality Constraint«same process»

generator PosixSharedMem<Integer N> implementsSharedMem< access = each(i:[1..N]) { LocalReceptacle<DataAccess> } >when samesystem ( each(i:[1..N]) { this.access[i] } ){ each(i:[1..N]) { PosixSharer node[i]; node[i].access.user += this.access[i]; }}

C3

C1

C2

SharedMem

44

C1

C3


C2

JuxMemManager

JuxMemPeer

JuxMemPeer

JuxMemPeer

UseProvide

generator JuxMem<Integer N> implementsSharedMem < access = each(i:[1..N]) { LocalReceptacle<DataAccess> } >{ JuxMemManager<N> manager; each(i:[1..N]) { JuxMemPeer peer[i]; peer[i].access.user += access[i]; merge ({ peer[i].internal, manager.internal[i] }); }}

C3

C1

C2

SharedMem

45

Experimental Validation:Parallel Method Calls Server

component ServiceProvider exposes{ UseProvide<provider={Facet<Service>}> s;}

bundletype ParallelFacet<Integer N, interface I>{ each(i:[1..N]) { UseProvide<provider={Facet<ServicePart>}> part[i]; }}

composite ParallelServiceProvider<Integer N> implements ServiceProvider { each(i:[1..N]) { PartialServiceProvider p[i]; } this.s.provider += ParallelServiceFacet<N> { each(i:[1..N]) { part[i] = providerPart[i].s; } }}

S2

S1

S0

ParallelServiceProvider<3>

PartialServiceProvider

ProviderPartialServiceFacet

ParallelServiceFacet<N>

provider

PartialServiceUser

C1

ParallelServiceUser<2>

PartialServiceUser

C0Merge

46

Experimental Validation: Parallel Method Calls Result

UsersideRedistributor<2,3>

UsersideRedistributor<2,3>

ServersideRedistributor<2,3>



C0

C1

S0

S1

S2

47

Experimental Validation:Parallel Method Calls Performance

Ban

dwith

par

cal

ler (

Mb/

s)

Message size (Byte)

• Comparison HLCM/CCM

Paco++

• Single cluster 1Gb Ethernet

• Parallelism 3 clients

4 servers

48

Experimental Validation:Conclusion

• HLCM Implementation Developed HLCMi: a framework for HLCM specializations implementations

HLCM/CCM: a CCM based specialization

Other specializations→ Plain Java→ CCM + plain C++→ Charm++

• Validated Good expressiveness

Good performance

No real automated choice yet

49

Outline





• Conclusion

50

Conclusion

• Identified need for an extensible component model User-defined inter-component interactions (composite generators) User-defined parameterized component implementations (skeletons)

• Introduced genericity in component models Supports user-defined skeleton implementation Applicable to existing component models Model transformation approach

• Described an extensible component model: HLCM Abstract model that relies on a backend for primitive concepts Concepts combined in HLCM

→ Hierarchy→ Genericity→ Implementation choice→ Connectors with open connections & connection adaptors

• Implemented & used A model-based implementation framework using EMF: HLCM i

Used for synthetic example implementations→ memory sharing→ parallel method calls

51

Perspectives

• More validation MapReduce ANR project (2010 - 2013)

Domain decomposition, Adaptative Mesh Refinement→ Salome (EDF, CEA) (w. Vincent Pichon)

OpenAtom (Molecular Dynamic)→ Pr Kale @ UIUC (Charm++) → Complex application, 4D/2D interaction

• Introduce the time dimension Usage

→ Change of implementation choices during execution (QoS, Data, …)→ Time related applications description (dataflow, workflow)

Problem→ Keep logical & primitive model in sync

• Study choice algorithms Choice criteria attached to model elements (w. scheduling community)

Interactions with resource management systems (w. Cristian Klein)

under the supervision of christian pérez insa de rennes

Documents

various hardwarecentered

parallel computingmemory

scientific computingunder

julien bigot

single mo