1 / 17

Towards a Bi-directional Feature Modelling Schema for HPC

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. Towards a Bi-directional Feature Modelling Schema for HPC. Software Product Line Engineering. High Performance Computing.

mona-deleon
Download Presentation

Towards a Bi-directional Feature Modelling Schema for HPC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Towards a Bi-directional Feature Modelling Schema for HPC

  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

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

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

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

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

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

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

  12. The end !

More Related