Khronos is considering an open standardization initiative to unify low-level communication into a simple API with the aim of reducing application complexity, minimizing development costs, and improving time-to-market for high-performance embedded products. If successful, this new standard that could transform the way applications are developed for heterogeneous systems.
Khronos’ methodical Exploratory Group process takes proposals for new open standards and evaluates industry interest before we create a Working Group to develop the standard itself. This process enables us to initiate and focus on standardization efforts that stand an excellent chance of being widely-adopted and having a positive impact on the industry.
As part of this process we are reaching out to the industry and invite you to review the materials below for a potential new standard for Heterogeneous Communications. They outline the problems that this new standard would address and some potential design directions.
Finally, we encourage you to fill out the online survey below to provide us your feedback, and contact us at firstname.lastname@example.org if you would like to discuss getting involved.
Many cross-platform communication standards already exist, but for the most part they are either focused on a particular interconnect hardware, a homogeneous HPC architecture, or locality (inter-thread, inter-process, inter-processor).
Each existing standard has different design methodologies, strengths, and weaknesses. Some are very complex requiring hundreds of lines of code just to handle simple concepts. Others intend to be simple but can get deceptively complex. Some mask important underlying features which can have performance impacts on latency and determinism.
Unfortunately, there is no single standard that fits all localities, features, and strengths. A single application may be required to use multiple communication interfaces. Over time this application may need to be re-distributed on different hardware requiring a large refactoring of code (e.g. moving inter-process communication to inter-thread communication). This results in high development costs, compromising shortcuts taken, potential to require use of non-de-facto 3rd party proprietary APIs, and overwhelmed application developers.
At a fundamental level, communication is about getting data from one end point to another. This concept is the same for all interconnects and localities.
If multiple low-level communication APIs are wrapped into a high-level open standard without compromising the low-level features and strengths, then this new open standard could be a one stop shop for developers.
Using this new API, distributing an application across different cores, processors, GPUs and IO devices would be faster and easier than with existing solutions.
A new open standard would be conceptually similar to MPI, MCAPI, OFI, etc. It could be used as an alternative to these APIs, or layered over lower-level communication code (e.g. sockets), providing a clean, modern programming abstraction.
Current standards do not seem to fully address the above goals. Technology has moved on considerably since many of these were established. The following is a basic overview of common point-to-point technologies, and how they could compare to a new unified API:
There are other technologies that try to solve distributed algorithms in a different way, such as OpenMP or HSA (Heterogeneous System Architecture)/HSAIL. These are different paradigms that are not in competition with the goals of unifying existing point-to-point technologies.
A more detailed presentation explaining the rationale behind creating a new Heterogeneous Communications API standard is here:
Who would benefit and potentially be involved in creating and using a new communication open standard?
Khronos would ensure that a quorum of relevant companies is interested to participate before initiating a working group to create this new standard.
To help us get started, please fill out this survey to allow us to collect feedback on your interests and usage of communication APIs – and your thoughts on a new open standard.
Please contact us at email@example.com if you have questions, or would like to discuss getting involved.
Takyon’s goal is to cater to the embedded HPC (High Performance Computing) engineer who is focused on algorithm development, not the complexities of low-level communication. They need the performance and flexibility of low-level and the simplicity of high-level, so the application can be re-factored in various ways without needing to redesign source code.
Where is this relevant:
Takyon is designed with the following requirements:
This is the formula to achieving best performance with modern interconnects.
Synchronizing requires messaging from one end point to the other and can perturb determinism and latency. Takyon only uses implicit synchronization to notify the sender when the message has left and notify the receiver when the message has arrived. All other synchronization is left to the application to control exactly when it happens. This is especially useful with multi-buffering when a synchronization signal only needs to occur after all the buffers are used up. The application should use explicit synchronization to know when:
Fault tolerance is the ability to recover after error situations occur, making a communication path unusable. This is also known as HAA (high application availability). This means that if something goes wrong with a communication path, it can be detected and either re-established or use an alternative path or method to make sure the application continues reliably. Fault tolerance in Takyon is achieved via these features:
Fundamentally, communication is about getting data from A to B. When using a high-level communication package, there should be no need to have different API groups for each type of interconnect, each type of buffering/synchronization, or the different localities (thread, process, processor). Takyon's core API is comprised of five simple and intuitive communication functions:
These functions can be used for reliable point-to-point communication, un-reliable one-sided communication useful for things like IO device streaming (video, audio, Lidar, etc.) and network multicasting.
Other proposals are welcome – please contact us at firstname.lastname@example.org if you would like to discuss getting involved.