OpenSPL est né du constat que le modèle de calcul temporel pour programmer les processeurs multicoeurs atteignait ses limites en termes de scalabilité, d’efficacité et de complexité. Cela nécessite des innovations radicales dans la conception des systèmes destinés à passer à l’échelle. Que signifie spatial ? Comment fonctionne OpenSPL et à quel avenir est dévolu ce nous langage de programmation ? Regardons tout cela en détail…

Oskar Mencer – CEO, Maxeler Technologies / Imperial College London.
Michael J. Flynn – Professor, Stanford University, and Chairman Maxeler Technologies.
John P. Shen – Head of Nokia Research Center North America Lab.

OpenSPL est une initiative originale créée par CME Group, Chevron, Juniper et Maxeler Technologies dans l’objectif double est de faire prendre conscience et de faire accepter le principe du calcul selon la localité spatiale plutôt que selon la localité temporelle. Bien que cette initiative soit nouvelle, les concepts et idées à la base de la localité spatiale sont utilisés depuis fort longtemps. Ainsi, par exemple, réaliser un ASIC (Application Specific Integrated Circuit) revient essentiellement à calculer dans l’espace même si, en l’occurrence, l’écriture du programme nécessite des centaines d’ingénieurs et plusieurs années d’effort, indépendamment de toute notion de coût. Le prix de revient d’un ASIC est d’ailleurs devenu si élevé qu’il doit pouvoir supporter l’exécution d’un maximum d’applications. Cela étant, le calcul dans l’espace apporte au programmeur l’avantage du substrat de silicium et de l’approche essai / erreur. Il permet d’adapter précisément la structure spatiale au problème que doit résoudre le substrat.

Le calcul dans l’espace peut être vu comme la généralisation de dizaines d’années de recherche dans les tableaux systoliques, les calculateurs vectoriels et tout un large éventail de projets de recherche tels que la thèse d’Alan Huang [1] sur le Computational Origami. Pour remonter plus loin encore – vers la fin des années 50 – on se souvient qu’IBM a révolutionné la conception hardware avec son SMS (Standard Modular System), qui utilisait des cartes de circuits standardisés pouvant être produites plus rapidement et avec une meilleure fiabilité que les cartes spécialisées. A l’époque, les ingénieurs concevaient des grilles 2D de blocs où chaque bloc définissait une fonction logique (c’est-à-dire une carte) et ses interconnexions. Chacun des blocs ainsi connectés était alors programmé sur des cartes perforées pour réaliser l’exécution de la grille de calcul sur l’ordinateur. Cette conception “compilée” vérifiait la validité formelle de la logique algorithmique, mettait à jour les informations permettant la gestion du signal et produisait au final le routage des circuits pour leur mise en production. Ce processus automatisé de conception et de production a permis aux IBM 1401 et 7090 de dominer le marché pendant pas mal de temps. On peut également affirmer que le SMS était le précurseur de la conception SLT utilisée dans le System 360 et d’autres emblématiques mainframes de cette période. Les systèmes basés sur OpenSPL tirent profit des enseignements dérivés de cette conception de lignes d’assemblage dans les usines de production (et donc également des premiers systèmes IBM) pour, cette fois, produire les résultats d’un calcul.

Retour en 2014. Que signifie OpenSPL en pratique ? Plutôt que de décrire un thread d’instructions et de le dupliquer sur plusieurs processeurs afin de travailler sur des flux de données SIMD, OpenSPL découple les calculs en composants orientés flux de contrôle ou flux de données, afin de créer une grille d’unités arithmétiques (Fig. 1) sur laquelle les données s’écoulent, exactement de la même façon que des pièces en production se déplaceraient dans une usine d’assemblage. Chacune de ces unités arithmétiques passe le résultat de son opération à l’unité voisine, ce qui permet d’éliminer la plupart des accès aux registres ou à la mémoire.

Comment fonctionne un programme OpenSPL ? En suivant tout simplement un graphe orienté dont les entrées / sorties sont connectées à la mémoire et aux autres bus E/S. Comme illustré au listing 1, cette approche supporte la syntaxe de tout langage de programmation. Nous aurions probablement pu introduire la notion de graphes orientés dans l’expression “calcul OpenSPL” mais cela aurait sans doute été moins élégant.

Dans cet exemple, SCS signifie Spatial Computing Substrate en écho à l’objet même de l’initiative OpenSPL. Plutôt que prétendre qu’un même programme peut être compilé de façon optimale pour différentes architectures et substrats, OpenSPL a été défini comme une base sur laquelle les membres de cette initiative peuvent développer leur propre compilateur spécifique à leur substrat ainsi que l’implémentation du runtime.

Le listing 2 donne un autre exemple de noyau control flow dans data flow où les candidats sont calculés simultanément dans l’espace et seule la bonne valeur est exploitée au travers du résultat SCSVar. Le listing 3 propose un exemple de noyau, Moving Average, où sont utilisés des nombres à virgule flottante de 7 bits pour l’exposant et 17 bits pour la mantisse.

A ce niveau de description, la question qu’on nous pose le plus souvent est de savoir ce qu’il advient des instructions conditionnelles. Ces instructions (les “if“, par exemple), ne sont pas nées égales en droit. On peut ainsi les classer en trois catégories : primo, les assignations conditionnelles ; secundo, les branchements de données (data forks) ; tertio, la séparation des chemins globaux dans le flux du programme. Le calcul dans l’espace possède trois mécanismes naturels qui correspondent à ces trois types d’instructions conditionnelles. Primo, on utilise un multiplexeur simple pour sélectionner une source de données parmi deux. Secundo, un embranchement dans un graphe ou un embranchement amène les données dans des graphes différents. Le troisième point, qui consiste à diviser les chemins globaux en codes et implémentations séparées, demande pour sa part plus de travail. Cette restructuration du code est probablement la partie la moins plaisante pour les développeurs contemporains, notamment ceux qui sont rompus à l’art du C++. Heureusement, ce travail de détricotage des chemins globaux n’est à effectuer que sur les parties du programme les plus souvent utilisées, c’est-à-dire généralement de petits segments de code. Un peu comme en contexte d’optimisation après profilage.

Maintenant que nous savons comment programmer dans un espace 2D, nous avons besoin d’une machine capable d’exécuter nos codes. Le standard OpenSPL décrit le concept de substrats de calcul dans l’espace, autrement dit les architectures qui supportent ce paradigme. Si le modèle n’est pas pleinement finalisé – il reste encore un certain nombre de choses à affiner – un premier substrat commercial est cependant d’ores et déjà disponible : le Multiscale Dafaflow Computing de Maxeler Technologies. Parce qu’il propose toute une gamme de serveurs, d’équipements de réseau et bientôt de stockage pour le calcul intensif en entreprise, ce substrat peut être utilisé pour des applications a priori infiniment variées. Il est fourni avec simulateurs et débogueurs, et bénéficie d’un programme de soutien qui en a ouvert la technologie à une centaine d’universités dans le monde. Alors que le standard OpenSPL se développe, d’autres substrats vont probablement voir le jour. Ils auront l’avantage commun de réduire de plusieurs ordres de magnitude la consommation électrique et la taille physique des appareils de calcul, de sorte qu’ils ouvriront cette technologie au calcul embarqué et mobile, y compris probablement le wearable computing.

Le domaine du calcul intensif mobile est sans conteste un des plus prometteurs. La puissance d’OpenSPL combinée à de nouveaux substrats pour la détection et le traitement en temps réel rend potentiellement possible une réduction très importante de la consommation électrique et de la taille des appareils. De tels supercalculateurs mobiles vont s’avérer essentiels pour le développement de produits qu’on envisage aujourd’hui mais qu’on ne sait pas encore fabriquer. Cet univers comprend les services cloud, les assistants spécialisés mobiles de toute sorte et les capteurs environnementaux embarqués – ce que l’on appelle globale “Internet des objets”. Pour pouvoir supporter le traitement temps réel d’une quantité massive de données (traitement qui comprend leur extraction et leur synthèse), des systèmes exaflopiques seront nécessaires. Mais en raison du caractère précisément massif et global de ce volume de données, une infrastructure cloud de calcul centralisée n’est probablement pas la bonne approche. En revanche, confier ce traitement à des calculateurs pétaflopiques mobiles distribués aux quatre coins du cloud devrait déboucher sur une meilleure efficacité – donc offrir un meilleur service aux utilisateurs.

OpenSPL, basé sur un modèle de calcul à flux de données et combiné à des substrats matériels appropriés, permet potentiellement d’améliorer de deux ordres de grandeur le compromis performance/puissance. Il ouvre la voie au développement de supercalculateurs mobiles pouvant être largement déployés sans requérir de datacentres dédiés ni, donc, d’infrastructures de support. A ce titre, il devrait apporter la puissance et l’efficacité énergétique que nécessitent les applications mobiles de demain.

[1] The folding of circuits and systems Applied Optics, Vol. 31, Issue 26, pp. 5419-5422, 1992.