Under the supervision of Christian Pérez insa de Rennes

Generic Support of Composition Operators in Software Component Models, Application to Scientific Computing

• Under the supervision of Christian Pérez

• INSA de Rennes

• INRIA Team-Projects PARIS(IRISA) / GRAAL(LIP)

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

Context: Parallel/Distributed Computing Paradigms

• Shared memory

• Implementations
• OS (node level)
• kDDM (cluster level)
• Juxmem (grid level)
• …

Context: Parallel/Distributed Computing Paradigms

• Shared memory

• Implementations
• OS (node level)
• kDDM (cluster level)
• Juxmem (grid level)

• Message passing

• Implementations
• MPI
• PVM
• Charm++
• …
• Variations
• Collective operations
• Barrier
• Broadcast
• Scatter
• …

Context: Parallel/Distributed Computing Paradigms

• Shared memory

• Implementations
• OS (node level)
• kDDM (cluster level)
• Juxmem (grid level)

• Message passing

• Implementations
• MPI
• PVM
• Charm++
• Variations
• Collective operations

Context: Parallel/Distributed Computing Paradigms

• Shared memory

• Implementations
• OS (node level)
• kDDM (cluster level)
• Juxmem (grid level)

• Message passing

• Implementations
• MPI
• PVM
• Charm++
• Variations
• Collective operations

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

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
• …

Context: Components for Parallel Computing

• Parallel/distributed programming paradigms

•  Hidden architecture
•  Reuse complex
•  Hardware resource abstraction
•  Efficiency on various hardware

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

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

Context: Problematic

• Goals for an extensible component model

• User code reuse
• Reusable composition patterns
• Reusable inter-component interactions
• Efficiency on various hardware

Outline

• Context of the Study

• Software Skeletons as Generic Composites

• HLCM: a Model Extensible with Composition Patterns

• HLCM in Practice

• Conclusion

Software Skeletons with Components: Motivating Example

• 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

Software Skeletons with Components: A Component Based Farm

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

Software Skeletons with Components: A Component Based Farm

Software Skeletons with Components: Introducing Parameters

Software Skeletons with Components: Introducing Parameters

Software Skeletons with Components: Introducing Parameters

Software Skeletons with Components: Concepts for Genericity

• Generic artifacts

• Accept 2nd order parameters
• Use the values of parameters in their implementation

Software Skeletons with Components: Concepts for Genericity

• Specializations

• Use of generic artifacts
• Arguments bind parameters to actual values

Software Skeletons with Components: Metamodel-based Transformation

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

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

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

Outline

• Context of the Study

• Software Skeletons as Generic Composites

• HLCM: a Model Extensible with Composition Patterns

• HLCM in Practice

• Conclusion

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

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

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

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

Combining All Concepts in HLCM: Concepts Interactions

Combining All Concepts in HLCM: Concepts Interactions

Combining All Concepts in HLCM: Concepts Interactions

Combining All Concepts in HLCM: Introducing Open Connections

Combining All Concepts in HLCM: Introducing Open Connections

• 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

Combining All Concepts in HLCM: Introducing Open Connections

Combining All Concepts in HLCM: Connection Adaptors & Bundles

• 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: 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

Outline

• Context of the Study

• Software Skeletons as Generic Composites

• HLCM: a Model Extensible with Composition Patterns

• HLCM in Practice

• Conclusion

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

Experimental Validation: Implementing shared memory

Experimental Validation: Implementing shared memory

Experimental Validation: Implementing shared memory

Experimental Validation: Parallel Method Calls Server

• component ServiceProvider exposes

• {

• UseProvide
  }> s;

• }

• bundletype ParallelFacetinterface I>

• {

• each(i:[1..N])

• {

• UseProvide
  }>

• part[i];

• }

• }

• composite ParallelServiceProvider

• implements ServiceProvider

• {

• each(i:[1..N])

• {

• PartialServiceProvider p[i];

• }

• this.s.provider += ParallelServiceFacet

• {

• each(i:[1..N])

• {

• part[i] = providerPart[i].s;

• }

• }

• }

Experimental Validation: Parallel Method Calls Result

Experimental Validation: Parallel Method Calls Performance

• Comparison

• HLCM/CCM
• Paco++

• Single cluster

• 1Gb Ethernet

• Parallelism

• 3 clients
• 4 servers

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

Outline

• Context of the Study

• Software Skeletons as Generic Composites

• HLCM: a Model Extensible with Composition Patterns

• HLCM in Practice

• Conclusion

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: HLCMi
• Used for synthetic example implementations
• memory sharing
• parallel method calls

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)

Experimental Validation: A Framework for HLCM Implementation

Software Skeletons with Components: Transformation Algorithm

• Transform( e:ModelElement, c:Context)

• If e is not related to genericity
• Recursively apply the algorithm to the content of e

Software Skeletons with Components: Transformation Algorithm

• Transform( e:ModelElement, c:Context)

• If e is a reference to a generic concept
• Create a new context with the arguments in e
• Transform the generic concept in this context

Software Skeletons with Components: Transformation Algorithm

• Transform( e:ModelElement, c:Context)

• If e is a generic concept
• Choose the right explicit specialization or the default one
• Recursively apply the algorithm to its content

Software Skeletons with Components: Transformation Algorithm

• Transform( e:ModelElement, c:Context)

• If e is a reference to a parameter
• Replace it by the value of the parameter in c

Software Skeletons with Components: Concepts for Genericity (3/3)

• Explicit specializations

• Distinct implementation for a range of specializations
• When some constraints are fulfilled
• Makes template meta-programming possible