1. 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

2. Software Product Line Engineering High Performance Computing Feature Modelling: An Informal Requirements Modelling Notation Feature Modelling For HPC

3.  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

4. 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)

5. 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

8. 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

9. 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

11. 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

14. 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

15. 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

16. 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

17. The end !