Abaco propose au Khronos Group une API pour simplifier le développement d’applications sur plates-formes hétérogènes

[EDITION ABONNES] Takyon, tel est le nom choisi par Abaco, fournisseur de cartes et systèmes pour l’embarqué, pour estampiller une API que la société américaine a présentée à l’organisme de standardisation de logiciels Khronos Group afin qu'elle soit examinée par un comité exploratoire pour évaluer son intérêt.... L'objectif de cette API ? Réduire la difficulté à développer des applications embarquées sur des calculateurs hétérogènes, i.e. dotés de plusieurs processeurs différents cohabitant sur une même carte unité centrale. Si le sujet suscite suffisamment d’intérêt, le Khronos Group créera un groupe de travail et invitera toute société intéressée à se joindre à lui pour faire évoluer cette API vers un standard ouvert.

D’un point de vue technologique, Takyon associe des fonctionnalités de signalisation et de communication point à point de bas niveau dans le but de réduire la complexité des applications et les coûts de développement. Certes, il existe déjà des normes de communication entre plates-formes (MPI, MCAPI, OFI...), mais elles concernent généralement un matériel d'interconnexion particulier, une architecture de calcul à hautes performances HPEC (High Performance Embedded Computing) homogène ou des échanges de bas niveau (interthreads, interprocessus, interprocesseurs). Et, malheureusement, selon Abaco, il n'existe pas de norme générique qui s'adapte à tous les cas de figure qu’une application embarquée de haute performance doit pourtant prendre en compte. Résultats, toujours selon Abaco, la réutilisation d’applications sur différents matériels nécessite souvent une réécriture importante du code (par exemple, pour passer d’une communication interprocessus à une communication interthread). Ce qui se traduit par des coûts de développement élevés et un recours éventuel à des API propriétaires.

Comparaion des API de communication

 

L’utilisateur cible de l’API Takyon est donc un développeur d’applications HPEC qui doit se concentrer sur la mise en œuvre d’algorithmes de traitement de données et non sur des problématiques de communication, et qui a des besoins de performances et de flexibilité au niveau des protocoles point à point de bas niveau, et de simplicité au niveau méthodologique. Pour ce faire, l'API Takyon proposée repose sur cinq concepts de communication et ne comporte donc que cinq fonctions principales, facilitant de fait son apprentissage et son utilisation. Le concept sous-jacent est d’intégrer plusieurs API de communication de bas niveau dans une norme ouverte unique de haut niveau, sans compromis au niveau des fonctionnalités et des performances des échanges de données de bas niveau.

Ainsi via l’API Takyon, les développeurs pourraient plus facilement concevoir des applications complexes, évolutives, portables et tolérantes aux pannes, capables de tirer réellement parti de la richesse des plates-formes matérielles hétérogènes. Quant aux racines technologiques de Takyon, elles sont à chercher dans l’expertise d’Abaco en matière de logiciels embarqués avancés, mise en place en particulier au sein de son environnement de développement Axis.

« Il existe déjà de nombreuses normes de communication multiplates-formes, mais elles sont principalement axées sur un matériel d'interconnexion particulier, une architecture HPEC homogène ou des échanges interthreads, interprocessus, interprocesseurs ou intra-applications, précise Peter Thompson, vice-président en charge du marketing produit chez Abaco. Chaque norme existante a des méthodologies de conception. Certaines sont très complexes, nécessitant des centaines de lignes de code simplement pour gérer des concepts simples. D'autres se veulent simples, mais deviennent d'une complexité trompeuse dans des cas d'utilisation réels. D'autres encore cherchent à masquer des caractéristiques sous-jacentes importantes pouvant avoir un impact sur la latence et le déterminisme. Face à cette confusion, nous pensons que le Khronos Group a le potentiel pour résoudre ce problème à partir de notre apport, et pour conduire à l'élaboration d'un standard ouvert. »