Below you can find links to the INTERTWinE project deliverables produced by the technical work packages.
The technical work packages are:
- WP3: Programming Model Interoperability
- WP4: Resource Management and Runtime Interoperability
- WP5: Applications and Kernels
This initial requirements analysis informed the direction of work at the project outset. It describes the status of the programming models addressed by the project, with particular attention to known interoperability issues already identified by the relevant standards bodies and/or developer teams. It then provides details of known pairwise interoperability issues between programming models, and identifies for each case any areas which INTERTWinE is capable of addressing.
This report contains the current state of API recommendations presented to the standard bodies. These recommendations, concerning interoperability, extension proposals and their implementations, have been collected from all of the technical work packages of the INTERTWinE project. The report describes the prioritised API combinations and co-design approach, reports on discussions held with the standard bodies, provides details on the effect on the APIs of the prioritised API combinations, and lists the recommendations presented to the standard bodies.
Within the context of INTERTWinE, the Resource Manager will play a key role in enabling interoperability between the APIs and libraries involved in the project and beyond, by ensuring coordinated usage of hardware resources. This document presents a survey of the current resource usage patterns of the project runtime systems and libraries. It presents some relevant use cases, details potential issues that may arise from such use cases, and lists requirements from the Resource Manager to address or mitigate these issues.
One of the tasks defined in the INTERTWinE project is the definition of a common, generic API for a Directory/Cache service for task-based runtime systems (such as OmpSs, StarPU and PaRSEC). The main goal is to achieve a programming model that hides most of the complexities associated with distributed systems, but also enables an efficient utilisation of remote compute and memory resources. The present document proposes an API for a Directory/Cache (a kind of virtual memory manager) that is sufficiently abstract and generic, promoting one-sided, asynchronous communication and providing automatic caching.
This deliverable defines the Resource Manager component being developed in INTERTWinE. The Resource Manager aims to coordinate resource allocation (also known as ownership), and to establish the means to dynamically share resources among multiple task-based runtime systems and additional support software which may execute within the same process. The main goal the Resource Manager pursues is to improve the composability of parallel libraries, the integration of task-based runtime systems and communication APIs, and to avoid negative performance effects of inappropriate use of the underlying resources by eliminating both oversubscription and undersubscription cases.
This document presents a first plan of the applications/kernels in combination with their initial evaluation and benchmark suite releases for use by WP3 and WP4. These initial releases of applications/kernels will be key to evaluating new or enhanced interoperability features that are made available in the respective runtime implementations. For each application/kernel, the document gives a brief introduction, describes the current state for the use case from the point of view of API combination, confirms the ambition plans with respect to API combination within the scope of INTERTWinE, and reviews the benchmarks and evaluation plans. There is also a summary of software (benchmark) release plans, focusing on the API combinations.
This document presents a list of API combinations prioritised by the project, provides highlights of the co-design aspects, and outlines the findings and lessons learnt from the API combination development on the partners’ applications/kernels: Ludwig, iPIC3D, TAU, BAR, Graph-BLAS and PLASMA. For each one of these, the document: 1) outlines a given application/kernel; 2) justifies the API combinations choice; 3) summarises the key implementation details, clearly stating the parts of applications being modified; 4) describes the preliminary performance results for the use case from the point of view of API combination; 5) provides analysis of the performance results with respect to the evaluation criteria; 6) discusses interoperability opportunities/issues, further improvements, and collaboration with the other technical work packages.