Merci ! Votre abonnement a bien été enregistré !
il y a un soucis. Merci de vérifier votre saisie.

Thales et le calcul parallèle: les nouveaux outils arrivent dans l’industrie

Les industries de défense sont à la frontière technologique et visent une performance extrême. Aujourd’hui, le défi est de gérer en temps réel des flux de données de plus en plus massifs, dans des systèmes embarqués les plus légers possibles. Performance maximale, poids minimal: la solution, c’est le calcul parallèle. Mais dans l'industrie, on code beaucoup à la main et la parallélisation pose de multiples problèmes. Comment récrire les 100 000 lignes de code d’une application radar? Thales utilise de nouveaux outils de parallélisation semi-automatique, développés en partenariat avec Mines ParisTech.

Monday
19
March 2018
read in english
read in english
Lire le résumé

Le calcul parallèle est particulièrement adapté au traitement des flux continus de données, aux applications dites «dataflow»: des données qui arrivent en masse continuellement, et qu’il faut traiter en temps réel. Il sert principalement à exécuter simultanément des opérations indépendantes à des fins d’accélération globale. Dans les industries de la défense, de l’aéronautique, de l’espace, du transport terrestre et de la sécurité, les domaines d’application sont souvent liés au monde des systèmes embarqués. La parallélisation, quand elle est possible, permet de minimiser le temps de calcul, ou de traiter davantage de données. Mais quand le code est déjà écrit, il faut tout reprendre à zéro. C’est tout l’enjeu des outils de parallélisation automatique qui commencent à être utilisés dans certaines industries friandes de technologies. Thales, dans le cadre d’une politique d’open innovation, a travaillé avec Mines ParisTech pour développer un de ces outils. Les utilisateurs réalisent vite les avantages de la parallélisation semi-automatique. Il ne s’agit pas seulement de gagner du temps ou de simplifier la maintenance. Il y a aussi des étapes avec l’outil qui sont moins sujettes à erreur. Le fait de générer un code automatiquement correct, par design, c’est aussi un avantage. Au total on gagne en productivité et cela permet aux ingénieurs de se concentrer sur d’autres choses. La démarche libère ainsi de la créativité.

Paris Innovation Review – Quels sont les enjeux et les contraintes du calcul parallèle pour un industriel comme Thales?

Michel Barreteau – Aujourd’hui, le calcul parallèle est partout, des supercalculateurs aux ordinateurs de bureau ou aux smartphones. Il sert principalement à exécuter simultanément des opérations indépendantes à des fins d’accélération globale. Dans les industries de la défense, de l’aéronautique, de l’espace, du transport terrestre et de la sécurité, qui sont les principaux marchés de Thales, les domaines d’application sont souvent liés au monde des systèmes embarqués, avec des exigences particulières et des contraintes spécifiques.

Il nous faut notamment beaucoup de performance. Mais il s’agit souvent de systèmes autonomes, qui n’ont pas la puissance des supercalculateurs. Nous parlons de machines qui volent, qui roulent, qui flottent, et dont l’autonomie est moindre ; donc il faut faire des compromis pour avoir la puissance suffisante et une consommation adaptée. Il y a aussi beaucoup d’applications temps réel, ce qui n’est pas toujours le cas des applications sur supercalculateur. Des systèmes embarqués en temps réel posent des contraintes particulières.

Le calcul parallèle est particulièrement adapté aux applications «dataflow» : des données qui arrivent en masse continuellement, et qu’il faut traiter en temps réel. 

Le calcul parallèle est particulièrement adapté au traitement des flux continus de données, aux applications dites « dataflow » : des données qui arrivent en masse continuellement, et qu’il faut traiter en temps réel. Cela peut être des applications radar, sonar, mais aussi de l’imagerie médicale, de la vidéo, etc. Nous avons travaillé ainsi récemment sur les données issues de capteurs d’un radar embarqué : une application radar qui cartographie le sol, qui en donne une sorte d’imagerie, à partir de l’écho qui est renvoyé.

Le traitement de ces données est réalisé par des applications qui, dans le monde industriel, sont le plus souvent écrites à la main. Dans ce cas précis, cela représente  environ une centaine de milliers de lignes de code. Il ne s’agit pas de générer un croquis, mais une représentation très précise. Et pour cela les données doivent arriver en masse. Imaginez un avion utilisant cette application : vu sa vitesse et son altitude, une cartographie précise du sol, en temps réel, est un véritable défi. Pour vous donner une idée de ce que peut signifier le « temps réel » dans ces conditions, on injecte des gros blocs de données régulièrement cadencés de l’ordre de plusieurs millisecondes pour nourrir l’application. La parallélisation, quand elle est possible, permet de minimiser le temps de calcul, ou de traiter davantage de données.

La parallélisation est donc un facteur de performance. Mais quand le code est déjà écrit, est-ce que cela ne signifie pas qu’il faut tout reprendre à zéro?

C’est tout l’enjeu des outils de parallélisation (semi-)automatique qui sont développés aujourd’hui et commencent à être utilisés dans certaines industries friandes de technologies. Pour continuer l’exemple précédent, l’outil SPEAR de Thales que nous utilisons a pu générer, en quelques minutes seulement, un code parallèle de  plusieurs dizaines de milliers de lignes, qui a fonctionné dans des conditions de contraintes réelles.

Mon métier consiste précisément à assurer cette parallélisation efficace au travers de méthodes et outils. Mais ce n’est pas le métier de Thales d’être un éditeur de logiciel. Avec mes collègues, nous nous appuyons parfois sur des technologies extérieures permettant de programmer des systèmes qui ont besoin de parallélisation. Nos clients sont majoritairement les unités opérationnelles du groupe Thales. Lorsque nous ne trouvons pas sur le marché des outils capables de répondre aux besoins exprimés, nous le développons nous-mêmes ou avec des partenaires.

C’est dans ce cadre que nous avons travaillé avec Mines ParisTech. Il s’agissait de développer un outil d’aide à la programmation parallèle, un outil graphique qui permette d’abstraire la complexité du parallélisme. Nous avions besoin de deux outils complémentaires.

Tout d’abord, un outil capable d’analyser un code C conséquent en nombre de lignes et d’en extraire le parallélisme ; et dans ce cas l’École est intervenue comme un partenaire précieux. En effet les Mines disposent d’un tel outil. Il réalise une analyse de dépendances ; cela permet d’identifier quelles parties de code sont séquentielles et lesquelles sont parallélisables. Nous récupérons cette information et il reste à la manipuler graphiquement en partitionnant et distribuant les données sur les processeurs et dans le temps avant de générer le code résultant.

Cela nous amène au deuxième élément, qui n’est plus lié à l’extraction du parallélisme mais à son exploitation. Les chercheurs des Mines nous ont permis de développer une solution scientifiquement plus robuste que le petit cœur logiciel maison dont nous disposions jusqu’alors.

Nous disposons donc d’un outil customisé pour les besoins Thales, développé en lien avec la technologie des Mines dans le cadre d’un partenariat. La couche basse, celle fournie par l’École, est transparente : c’est une bibliothèque de services de base sur laquelle nous nous appuyons pour ajouter des fonctionnalités qui sont spécifiques aux façons de fonctionner des programmeurs manuels de Thales.

Il y a ici des enjeux importants : nous parlons d’applications industrielles, qui viennent de différents domaines puisque Thales couvre plusieurs marchés, et nous souhaitions donc un outil propre scientifiquement parlant, souple et évolutif, dont nous puissions nous servir pour toutes les applications que nous souhaitions développer. Or les Mines disposent d’une technologie, une bibliothèque avec ce cœur logiciel mathématiquement valide, extensible et éprouvé. À partir de cette brique logicielle, on peut définir des fonctionnalités qui aident à la parallélisation des applications que nous traitons – pour l’essentiel, des flux de données. L’outil SPEAR de Thales intégrant la technologie des Mines prend une application séquentielle en entrée, l’analyse, extrait le parallélisme, l’exploite, et génère à la fin un code parallèle, pour différentes architectures matérielles parallèles.

Ce type d’outil s’appuie sur une solide base mathématique, et fait donc appel à des compétences qui ne se trouvent pas facilement ailleurs. L’École des Mines y travaille depuis longtemps, et j’avais moi-même fait ma thèse sur un sujet proche. François Irigoin, chercheur aux Mines, tout comme moi avons croisé au début de notre carrière la route de Paul Feautrier, un des pères du modèle polyédrique qui reste le fondement de ces outils ; il a poursuivi dans cette voie et a développé avec son équipe un outil de parallélisation automatique, qui s’appelle PIPS. Il existe une communauté active autour de ce sujet, convaincue que ces solides bases mathématiques peuvent servir pour la parallélisation des applications industrielles ; ce qui n’est pas faux puisque cela existe dans le plus répandu des compilateurs, GCC.

Néanmoins, comme vous le disiez, dans l’industrie, les gens programment parallèlement à la main. Suffit-il de leur montrer qu’ils vont gagner en productivité s’ils utilisent ces nouveaux outils?

C’est une question sensible en effet. Bien sûr, nous profitons de cet outil pour faciliter les choses à l’utilisateur. Et nous n’imposons pas une solution hors sol : nous customisons, nous parallélisons « à la mode Thales ». Mais il ne faut pas se mentir, pour des utilisateurs qui programment manuellement, c’est difficile d’adopter un outil qui requiert a priori une retouche de leur code legacy et ne suit pas le processus habituel de développement manuel en terme de validation et de qualité. De plus, les fortes contraintes de délais et de coûts industriels les incitent à ne pas prendre de risques avec un outil dont on n’a pas pu comparer et  vérifier l’efficacité sur le terrain car on ne peut financer en parallèle les deux approches.

Néanmoins les utilisateurs réalisent vite les avantages de la parallélisation semi-automatique. Il ne s’agit pas seulement de gagner du temps ou de simplifier la maintenance. Il y a aussi des étapes avec l’outil qui sont moins sujettes à erreur. Le fait de générer un code automatiquement correct, par design, c’est aussi un avantage. Au total on va gagner du temps, gagner en productivité.

Cela permet-il aux ingénieurs de se concentrer sur d’autres choses?

Oui, précisément. Dans un processus de programmation parallèle, il y a des tâches à forte valeur ajoutée et d’autres qui le sont moins. La plupart du temps, on arrive à automatiser celles qui peuvent l’être, par exemple, générer des communications paramétrées sans erreur de synchronisation. Pour les tâches à plus forte valeur ajoutée, comme faire des choix de placement des calculs sur les processeurs, par exemple, il en va autrement : l’ingénieur peut disposer de 6-8 mois devant lui pour faire le travail de portage d’une application sur une architecture matérielle, et il ne peut pas faire tous les choix possibles. L’outil, en libérant du temps, permet d’en passer davantage à faire des choix de placement via l’exploration de l’espace des possibles, ce qui permet d’ouvrir de nouvelles pistes. L’ingénieur n’est pas remplacé par l’outil : il se « re-déploie » sur des activités plus intéressantes. D’autre part notre approche semi-automatique sécurise l’utilisateur qui contrôle le processus d’exploration ; cela aide à son acceptation.

Cette démarche s’inscrit dans une recherche de productivité : obtenir plus de performance, à moindre coût. Mais elle libère aussi de la créativité.

C’est tout l’intérêt de cette démarche. Dans son principe, elle s’inscrit dans une recherche de productivité : obtenir plus de performance, à moindre coût. Mais elle libère aussi de la créativité : si l’utilisateur a plus de temps, il peut très bien essayer d’autres scénarios de parallélisation. Cela permet d’ouvrir de nouvelles perspectives.

Dans le même ordre d’idées, il y a un enjeu qui tient à la complexité croissante des architectures matérielles sous-jacentes. On dit qu’elles ont des « ressources hétérogènes » : des accélérateurs de différents types, de plus en plus de cœurs, de plus en plus de hiérarchie de mémoire et de plus en plus de façons de communiquer différentes. Le fait d’en faire abstraction, de pouvoir explorer ces différentes ressources et de les exploiter au mieux, c’est exactement ce qu’on attend, parce que cette nouvelle dimension sera de moins en moins gérable à la main, car trop complexe, et donc on n’aura pas assez de temps pour l’explorer.

Revenons aux utilisateurs et à leur code initial –  la centaine de milliers de lignes de l’application radar, par exemple. Pour rentrer ce code dans l’outil, faut-il le préparer, lui faire subir une première mise en forme?

Oui, et cela fait partie des étapes préparatoires sachant que cela ne concerne que la partie parallélisable qui représente une partie réduite de l’application complète. Pour qu’il soit exploitable par l’outil, le code doit être mis en forme, avec l’application de règles de codage qui permettront une exploitation optimale. Si on présente le code tel qu’il a été programmé à la main, certains éléments vont bloquer l’outil ou ne seront pas exploités car pas reconnaissables par l’outil.

Il y a donc un travail de restructuration qui n’est pas négligeable, mais qui a l’avantage d’être fait une fois pour toutes, quel que soit le type d’architecture matérielle que l’on choisira par la suite. A comparer à la pratique actuelle qui montre que ces codes sont repris manuellement par cycle de quelques années, et ce à chaque fois que l’architecture change.

Toutefois, pour éviter aux utilisateurs ce travail supplémentaire sur un code déjà écrit, nous préconisons plutôt notre outil pour de nouvelles applications : les règles de codage sont plus faciles à intégrer.

Le fait d’avoir travaillé sur ces règles de codage, qui permettent d’exploiter à fond l’outil des Mines en complément du nôtre, a une retombée inattendue vis-à-vis de la contrainte qu’elle engendre naturellement : appliquer ces règles offre plus de lisibilité au code : c’est plus clair, et donc a priori plus facile à débugger au niveau fonctionnel. Ce sont des avantages qu’on ne soupçonnait pas.

On comprend en vous entendant que la greffe est en train de prendre, que vos «clients» internes sont convaincus. La question est-elle posée de leur transférer purement et simplement cet outil, afin qu’ils achèvent de se l’approprier?

Excepté à des fins d’expérimentations, cet outil n’est pas encore déployé dans les unités opérationnelles, principalement car il n’a pas atteint le stade de produit avec tous les aspects de tests et de maintenance nécessaires, y compris pour les modules provenant des Mines. Sachez par ailleurs que ce n’est pas la mission du centre de recherche de Thales ; néanmoins l’intérêt de certaines unités reste manifestement présent puisqu’il est évalué régulièrement sur de nouvelles architectures parallèles. Nous l’utilisons en interne pour répondre aux demandes des unités, mais il ne serait pas encore exploitable directement : ce n’est pas une suite logicielle vendue dans le commerce, mais une technologie en cours de développement, et dont l’utilisation demande une expertise spécifique. Ce n’est pas un produit fini, que nous pourrions transférer aux unités avec un mode d’emploi ; un accompagnement resterait nécessaire. Comme je vous le disais, nous ne sommes pas un éditeur de logiciel – ce n’est pas notre métier. Nous proposons plutôt un service.

Dans votre «proposition de valeur» auprès des unités, il y a une connaissance fine des métiers et des styles de programmation. C’est évidemment un plus. Mais le fait de ne servir que des clients internes ne vous enferme-t-il pas dans une bulle de connaissances propre à Thales, avec des façons spécifiques de développer, de faire, d’envisager la programmation?

Non, car il y a aussi beaucoup d’échanges avec l’extérieur. Thales Research & Technology est engagé dans beaucoup de projets collaboratifs, et nous sommes à l’écoute de ce qui se passe à l’extérieur. Nous avons aussi une volonté d’utiliser de plus en plus des technologies externes développées par nos partenaires, dans le cadre de ce que l’on appelle l’Open Innovation. L’une des particularités  de Thales Research & Technology, c’est précisément d’être un pont entre les académiques, les PME et nos clients Thales. Si des technologies venant de l’extérieur répondent aux besoins des clients internes Thales, nous n’allons pas les redévelopper en interne : nous les achetons. Si une partie de la solution est fournie par l’extérieur, nous ne faisons que l’adapter pour répondre aux besoins des entités. Si la solution n’existe pas, nous la développons.

Nous faisons donc un état de l’art pour voir ce qui est disponible, afin de ne pas réinventer la roue. Cela suppose de regarder les faiblesses et les forces de chacun des outils, chacune des technologies, et partir de là pour savoir si nous pouvons acheter le produit sur étagère, ou s’il faut le développer nous-mêmes, ou encore s’il est préférable de le développer en partenariat.

Il y a une tendance, ces derniers temps, à privilégier les achats de produits déjà développés, parce que cela permet de limiter les coûts. Mais le développement de produits originaux et les partenariats ont aussi leur intérêt, notamment quand on travaille avec des partenaires     académiques éprouvés, qui connaissent bien le monde industriel.

Les chercheurs des Mines ont une grande sensibilité aux besoins du client, et la dimension industrielle est dans l’ADN de l’École. A chaque fois qu’on a fait appel à eux, ils ont eu à cœur d’adapter précisément leurs résultats de recherche à nos cas particuliers. Car dans le monde industriel, il y a beaucoup d’exceptions, ce n’est pas aussi générique que les mathématiques.

Il y a aussi une dimension opérationnelle. L’outil PIPS développé par l’équipe de François Irigoin existe depuis longtemps, mais dès ses débuts c’était l’un des seuls qui traitait des applications significatives,  industriellement parlant, en terme de lignes de code. Or la scalabilité est un point essentiel quand on travaille pour l’industrie : il s’agit de savoir faire des choses en pointe sur le plan scientifique, mais appliquées à la réalité industrielle, avec des codes qui ont quelques centaines de milliers de lignes, parfois quelques millions sachant que les sections parallélisables représentent heureusement souvent moins de 20% de l’ensemble de l’application. Il n’est pas facile de tenir les deux bouts, et c’est précisément l’enjeu des partenariats entre académie et industrie. Néanmoins notre partenariat n’a pas adressé l’étape d’industrialisation, plus coûteuse en terme d’ingénierie.

La qualité de ces partenariats est un facteur de compétitivité. Dans le cas de l’informatique, cela se mesure directement, en jours de développement et de maintenance économisés, en nombre de lignes de code générées correctement et en optimisation du ratio performance consommation.

Une relation d’âge mûr et éprouvée offre à la fois de la confiance, une meilleure compréhension et un gain de temps appréciable pour les deux parties. Chacun sait comment l’autre travaille. Ces partenariats, du reste, prennent diverses formes. Ils sont parfois financiers, parfois collaboratifs, avec une diversité de contrats. On peut aussi mentionner quelques thèses. Pour les Mines, l’avantage, je crois, est de se rapprocher des usages industriels ; pour Thales, il était ici de bénéficier d’un outil best of class.

Michel Barreteau
Expert Programmation parallèle & outils, Thales Research & Technology