Heterogeneous Hierarchical Asynchronous Tasking

Welcome to the wiki pages for the Heterogeneous Hierarchical Asynchronous Tasking (HHAT) effort.

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 HHAT, and developers who are ready to invest in good software engineering to produce an effective, durable, scalable and retargetable result

Sign up at the [site] to get an invite to regular meetings, whose minutes are kept here.

This wiki presently serves to inform the development of a HHAT framework in four ways:

1. Glossary and References
   1. Tasklet - Non-decomposable task
   2. Task - May be split into one or many tasks.
   3. Data Source - Originator of data communication
   4. Data Sink - Destination for data communication
   5. Directory - Look up service to identify a sink or source in a lower-level communication substrate. It might be wise to externalize a global directory service and make it an optional part of the reference implementation. By so doing, we allow a cottage industry to create competing implementation of such look-up services that serve specific needs of applications, hardware, or the middleware.
2. Usage models
   • prosaic descriptions of how HHAT 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 HHAT
   • 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 HHAT
   • 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 HHAT
   • 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

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!

At this point, HHAT is a descriptive handle, rather than a proper name. For a HHAT 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.

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.

Language Bindings

C

For maximum portability, C offers the most portable ABI that can easily serve other compiled languages as well as interpreters of scripting languages. The only way to break the C ABI is to use more exotic types such as extended precision numbers so we should avoid it.

C++

C++ bindings may get complicated: object structure for one hardware may not make sense on another platform.

MPI deprecated C++ bindings for some time now. What's left are bindings provided by Boost which might be an overkill for some applications.

Fortran

Fortran 2003 seems to be OK with calling C directly. But the actual Fortran module with binding specification. Some C data types might be prohibited.

Lessons learned from the MPI standard: decide whether we use pointers or integer handles. Also, asynchronous interfaces break Fortran's rule of local variables not being changed after a function returns as in:

MPI_Isend(&var);
// 'var' will be changed here
MPI_Wait()
// MPI does not change to 'var' any longer