T.J Brown, I. Spence, P. Kilpatrick, C. Gillan, N. S. Scott

School of Electronics, Electrical Engineering and Computer Science,

Queen’s University of Belfast

Software Product LineEngineering

High Performance Computing

Feature Modelling:An Informal

RequirementsModelling Notation

Feature ModellingFor HPC

Short Term aim

Provide a graphical means of documenting the feature structure of HPC algorithms and their possible mapping to multiple (possibly heterogeneous) computing platforms

Longer Term aim

Extend the notation to allow automated performance comparisons between alternative mappings to the same platform, or between mappings to alternative platforms

Feature Modelling: Basic concepts

Originated in early 90’s as an informal modelling notation for families of related software systems (Product Lines)

Designed to allow capture of commonality and variability within the family of systems

Features can be :- Mandatory (required in all family members) Optional (supported in some, but not all members) Alternative (one of several alternatives supported) OR (one or more alternatives supported)

Feature Modelling: Basic Concepts

Features can be subject to Constraints Mutual exclusion - inclusion of feature A excludes feature B and vice versa Feature Dependency

- inclusion of feature A requires inclusion of feature B as well

Feature model forms a top-down hierarchy Use to model any family of products e.g. cars

Feature Modelling: Developments

Many refinements / developments proposed Our Modelling schema is motivated by the needs of embedded system families and has:

Bi-directional modelling - a conventional top-down tree displays software features

- a bottom-up tree has hardware /OS related features Relationships between features in the two trees features can have properties (or attributes) features can have attached behaviour

- modelled using UCM (Use Case Maps) a feature (and its sub-tree) can be replicated

Capturing Behaviour with Use Case Maps An abstract notation for expressing behaviour Inspired by the needs of telecoms software Now a ITU-T Standard Behaviour represented by a causal path from a single starting point to one or more end points

- Path can have: loops, forks and joins, synchronisation points read/write operations, responsibility points etc.

- Other element types pools – abstract representation of a data store stubs – ‘holes’ in a path into which another path can plug

Using feature modelling in HPC

multi-core (many-core) chips accelerators (FPGAs) GPUs - heterogeneous/reconfigurable platforms Use FM as a modelling/analysis tool to:

capture the feature structure of HPC algorithms explore how an HPC code might be implemented on multiple platforms

Inverted tree models the computing platform Use Top-Down tree to model algorithm features Capture mapping of algorithm features to Processing Elements

Performance Comparison/Estimation

Current notation provides some support use properties to define platform characteristics

number of PEs on GPU absolute performance of PE (FLOPS)

Replicated feature sub-trees expose possible SIMD parallelism AND fork within a feature’s UCM path exposes possible MIMD parallelism

What do we need ?

short term: fully populate features with behavioural detail annotate UCM paths with basic performance information - expected iterations of a loop - expected branching pattern at a fork - Floating point operations at a responsibility point - access time for read/write

What do we need ?

longer term fuller description of Processors

- cache organisation, times for local/main memory access etc specification of processor groups

- e.g. pipelines specification of alternative mappings of algorithm features with associated conditions

- important in context of dynamic load balancing handling of time and temporal ordering

- only partially managed at present handling of memory

The end !