Hierarchical Heterogeneous Asynchronous Tasking

Welcome to the wiki pages for the Hierarchical Heterogeneous Asynchronous Tasking effort. The short form of this is HiHAT, pronounced high-hat, like the musical instrument. The name HiHAT is suggestive of a top-down gathering of requirements to assure an effective and pervasively-used result, and a bottom-up effort, driven by vendors, to offer common access to many platforms. Being able to wear many hats is suggestive of the many user-facing interfaces.

See [Mini-Summit Overview] for a presentation that offers context and goals.

We are currently in the first phase of the development of this framework, in which we are

• Revealing a striking commonality of interests
• Building momentum toward a production-quality, retargetable framework for broad community use
• Gathering usage models and requirements in the form of user stories with acceptance criteria
• Identifying representative and influential applications that serve as poster children for HiHAT, and developers who are ready to invest in good software engineering to produce an effective, durable, scalable and retargetable result

Meeting Logistics

You can SIGN UP here for the meeting series.

MINUTES are kept HERE.

Go here for Presentations given at the monthly review.

If you want to have edit access to the Wiki select the "Request Account" link on the left.

Join us for HiHAT First Mini-Summit May 9 2017, 9-12am at San Jose Convention Center Hilton, where we'll review some usage requirements and design progress. Click for details.

About this Wiki

This wiki presently serves to inform the development of a HiHAT framework in seven ways:

1. Glossary and References
2. Usage models
   • prosaic descriptions of how HiHAT would be used
   • Examples: static vs. dynamic, C++ features, task graph vs. imperative interfaces, multiple files vs. one source file
   • purpose: get a deeper appreciation of new usages, see commonalities and patterns across multiple usages
3. User stories
   • formulaic, succinct and more rigorous descriptions of what is wanted out of HiHAT
   • As a <role>, I want <function> so that <benefit>, such that <acceptance criteria>
   • purpose: get more rigorous about what is needed
4. Applications
   • Brief description of app and its business importance
   • Brief description of app domain
   • Qualitative or quantitative analysis of where and how it would benefit from HiHAT
   • Expected time table for delivery of a solution (e.g. readiness for the arrival of a new supercomputer at a USG lab), and resources available to implement it with HiHAT
   • purpose: identify apps that could lead vehicles that drive the development of an open source project and that would be a poster child that would build confidence for others to follow
5. Runtime Clients
   • Language or tasking runtimes that are clients on top of the HiHAT user and common layers
   • Descriptions, key characteristics
6. Implementation Modules
   • Implementations of HiHAT user and common layer functionality, provided by vendors or third parties
7. Reference
   • pointers to other related work that could be of interest to this community that doesn't fit into the above categories

Some key points about this wiki and what gets posted here

• All contributions of ideas and code examples here are considered public. There are no implied restrictions on the reuse of intellectual property or code, in open source or proprietary contexts.
• This is a community effort. It is expected that the whole community will benefit from the considerable efforts of many generous and conscientious people who are working for the common good. Thanks for your investment!

For a HiHAT framework to be viable, it needs to support several targets, provide common building blocks, services and transformations in an open architecture, and enable a variety of different applications and frameworks to be built on top. The diagram below suggests one possible arrangement.

Please refer to the HiHAT SW Stack page for a discussion of how various SW components might interact.

If the middle layers are modular, implementations can be created, plugged in, and iteratively refined. They may be freely shared or premium versions could be offered commercially.