T.J Brown, I. Spence, P. Kilpatrick, C. Gillan, N. S. Scott School of Electronics, Electrical...
-
Upload
darlene-greer -
Category
Documents
-
view
221 -
download
0
description
Transcript of T.J Brown, I. Spence, P. Kilpatrick, C. Gillan, N. S. Scott School of Electronics, Electrical...
T.J Brown, I. Spence, P. Kilpatrick, C. Gillan, N. S. ScottSchool 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 !