Processing

Please wait...

Settings

Settings

Goto Application

1. WO2020193351 - COMPUTERISED PROCESSING OF A SEQUENCE OF COMPUTING AGENTS IMPLEMENTED BY A SET OF DIFFERENT TECHNOLOGIES

Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters

[ FR ]

Description

Titre de l'invention : Traitement informatisé d’un enchaînement d’agents de calcul mis en œuvre par un ensemble de technologies distinctes

La présente invention concerne l'enchaînement automatisé de traitements informatiques sur des données telles que, par exemple, des données d'imagerie numérique. Elle concerne plus particulièrement l’enchaînement de traitements issus de technologies différentes, c'est-à-dire, notamment, de plateformes de traitement distinctes.

Contexte de l’invention

Le traitement automatisé de données numériques implique généralement l’enchaînement d'un certain nombre de sous-traitements afin d'aboutir à un résultat recherché. Ces sous-traitements peuvent être très spécifiques ou plus généraux, et, essentiellement dans ce dernier cas, ils peuvent être offerts par des technologies différentes comme autant d'implémentations.

Ainsi, par exemple, un processus de traitement et d'analyse d'images d'origine biologique peut consister en un ensemble de traitements consistant à

-visualiser des images de cellule par le biais de logiciels propriétaires des microscopes. Chaque image est enregistrée indépendamment sur le système de l'utilisateur ;

-puis, sur chaque image est appliquée un ensemble d'algorithme de traitement afin d'extraire des informations particulières (position des noyaux de cellule, indicateurs de la forme des cellules, etc.) ;

-ces données sont ensuite stockées sur un tableau. Leur analyse statistique est réalisée par la composition de macro-fonctions du tableau (par exemple, le logiciel Excel) et de scripts en langage Python par exemple.

La durée d'un tel processus pour être de plusieurs heures. En outre, un besoin d'automatisation existe afin de libérer les opérateurs humains (chercheurs, techniciens...) de tâches longues et fastidieuses, et de diminuer le coût du processus.

Si des outils existent pour certaines étapes de la chaîne de traitement, d'autres ne sont pas automatisés, comme notamment la liaison entre les étapes qui reste

essentiellement manuelle dans les solutions de l'état de l'art (copie des images, formatage des données....)

En outre, chaque étape du processus peut être mise en oeuvre par une technologie existante (un outil ou logiciel d'analyse ou de traitement d'image...), mais chaque outil est associé à des modalités particulières, issues de son domaine d'opération normal, et ayant des implications notamment sur ses interfaces (formats des données d'entrée, de sortie...).

Ainsi, différents outils de traitement d'image existent (OpenCV, ImageJ, ITK...), mais chacun possède des spécificités car issus d'un domaine distinct et répondant aux exigences de métiers différents (imagerie médicale, imagerie spatiale, etc.)

Par nature, ces outils ne sont pas nativement interopérables. Bien que l'utilisation de solutions dites de "bindings" permette d'utiliser OpenCV en langage Java, la traduction entre les structures de données n'est pas fournie et l'utilisateur doit donc développer les éléments nécessaires.

Résumé de l’invention

Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités.

Plus particulièrement, la présente invention vise donc à améliorer la situation en proposant une solution permettant de faire interopérer des outils variés, en automatisant les interfaçages entre ces outils ainsi que la sélection de la technologie permettant d'implémenter une étape d'un traitement complexe.

A cette fin, la présente invention propose un procédé pour l’exécution d’un traitement composé d’un ensemble d’agents de calcul sur une plateforme de traitement de données, chaque agent associant une routine à des modalités d’exécution de ladite routine, et ledit procédé comprenant

une étape de fourniture d’une représentation dudit traitement informatique sous la forme d’un squelette composé d’un ensemble orienté de noeuds, chaque nœud correspondant à un desdits agents de calcul ;

une étape de décomposition dudit squelette en un graphe exhaustif dans laquelle on détermine l’ensemble des modules logiciels pouvant mettre en œuvre chacun desdits agents, et on remplace le cas échéant chaque nœud par un groupe de nœuds, chaque nœud dudit groupe

correspondant à un module logiciel pouvant mettre en oeuvre l’agent correspondant au nœud remplacé ;

une étape d’affectation de coûts à chaque nœud dudit graphe exhaustif, et à chaque transition entre nœuds ;

une étape de détermination d’un graphe optimal en conservant un chemin dudit graphe minimisant lesdits coûts ;

une étape d’exécution consistant à appeler de façon ordonnée les modules logiciels correspondant audit graphe optimal et à assurer les traductions et synchronisation de données entre chaque appel.

Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles :

- les coûts affectés à chaque nœud dudit graphe exhaustif comprennent un temps d’exécution, et les coûts affectés à chaque transition comprennent un temps de traduction des données entre les environnements technologies des modules logiciels associés aux nœuds concernés, et un temps de transfert des données ;

- à chaque nœud dudit squelette est associé un exécuteur instanciant lesdites modalités d’exécution associé à l’agent correspondant audit nœud ; ledit squelette comporte des nœuds génériques correspondant chacun à un agent de calcul pouvant être mis en œuvre par au moins deux modules logiciels, et des nœuds spécifiques correspondant chacun à un agent de calcul pouvant être mis en œuvre par un unique module logiciel.

Un autre aspect de l’invention concerne un dispositif pour l’exécution d’un traitement informatique composé d’un ensemble de routines sur une plateforme multi-technologique comprenant des moyens pour

- fournir une représentation dudit traitement informatique sous la forme d’un squelette composé d’un ensemble orienté de nœuds, chaque nœud correspondant à un desdits agents de calcul;

- décomposer ledit squelette en un graphe exhaustif en déterminant l’ensemble des modules logiciels pouvant mettre en œuvre chacune desdits agents, et remplaçant, le cas échéant, chaque nœud par un groupe de nœuds, chaque nœud dudit groupe correspondant à un module logiciel pouvant mettre en œuvre l’agent correspondant au nœud remplacé ;

- affecter des coûts à chaque nœud dudit graphe exhaustif, et à chaque transition entre nœuds ;

- déterminer un graphe optimal en conservant un chemin dudit graphe minimisant lesdits coûts ;

- exécuter ledit traitement en appelant de façon ordonnée les modules logiciels correspondant audit graphe optimal et à assurer les traductions et synchronisation de données entre chaque appel.

Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles :

- les coûts affectés à chaque nœud dudit graphe exhaustif comprennent un temps d’exécution, et les coûts affectés à chaque transition comprennent un temps de traduction des données entre les environnements technologies des modules logiciels associés aux nœuds concernés, et un temps de transfert des données ;

- le dispositif comprend des moyens pour, à chaque nœud dudit squelette, associer un exécuteur instanciant lesdites modalités d’exécution associé à l’agent correspondant audit nœud.

- ledit squelette comporte des nœuds génériques correspondant chacun à un agent de calcul pouvant être mis en œuvre par au moins deux modules logiciels, et des nœuds spécifiques correspondant chacun à un agent de calcul pouvant être mis en œuvre par un unique module logiciel.

Un autre aspect de l’invention concerne un système pour l’exécution d’un traitement informatique composé d’un ensemble d’agents de calcul, comportant un dispositif tel que précédemment défini, ainsi que des applications logicielles mettant à disposition lesdits modules logiciels audit dispositif.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés.

Brève description des dessins

La figure 1 représente schématiquement un organigramme fonctionnel selon un mode de réalisation de l’invention.

La figure 2 représente schématiquement des exemples de motifs pour la formation de squelettes selon un mode de réalisation de l’invention.

Les figures 3a, 3b, 3c représentent schématiquement des exemples de squelettes selon un mode de réalisation de l’invention.

Description détaillée de l’invention

L'invention peut s'appliquer aux traitements d'images numériques, par exemple des images médicales ou de tissus organiques afin d'établir des informations sur la composition cellulaire.

Mais elle peut s'appliquer également à toute chaîne complexe de traitement de données numériques (traitement du signal, etc.) et tout champ d'application.

D'une façon générale, ces traitements peuvent se décrire comme un ensemble de sous-traitements, organisés sous la forme d'une chaîne ou d'autres types d'arrangement ou "workflow".

Selon différents mode de réalisation, l'invention concerne un procédé et un dispositif pour l'exécution d'une telle chaîne de traitement sur une plateforme de traitement de l'information. Cette plateforme peut être un serveur ou un ensemble de serveurs informatiques, de type "ferme de serveurs", éventuellement virtualisé et abstraites sous la forme d'un "nuage" (ou "cloud" selon la terminologie en langue anglaise plus habituelle).

Le dispositif peut former un "noyau" d'une chaîne d'outils logiciels plus complète offrant différents services pour aider le développeur de la chaîne de traitement à la mettre concrètement en place sur la plateforme. Préférentiellement, ce noyau et ces outils annexes, ainsi que le procédé, rendent les aspects technologiques transparents pour ces développeurs afin de permettre aux personnes spécialisés dans un champ d'application (imagerie médicale, imagine biologique...) d'utiliser des outils provenant de technologies tierces sans recourt à des connaissances spécifiques à ces technologies, et sans utiliser non plus de connaissances pointues en informatique.

Un traitement peut se définir par un ensemble d'agents logiciels, ou agents de calcul, chacun représentant un "sous-traitement".

Un agent peut se définir, d'une façon générale, par une association entre une ou plusieurs routines logicielles, et des modalités d'exécution de ces routines. Ces modalités définissent des besoins techniques pour exécuter la ou les routines : ressources du CPU, ressources mémoires, ressources en communication, etc.

L’ouvrage de Jacques Ferber, « Les systèmes multi-agents. Vers une intelligence collective », InterEditions, 1995, proposent des définitions formelles des notions de systèmes multi-agents et d’agents de calcul, pages 14-16.

On peut par ailleurs ici considérer un agent comme une instance technologique dédiée à l’exécution d’une routine spécifique, elle-même étant la spécialisation d’une routine dite générique (ou sémantique). Un agent possède ainsi un objectif de traitement, des ressources d’exécution et une capacité de communiquer avec le cœur de l’application.

La figure 1 schématise un organigramme fonctionnel d'une mise en œuvre du procédé selon l'invention.

Ce procédé peut être décomposé en deux phases P1 , P2. Une première phase P1 correspond à la génération d'une séquence d'exécution correspondant à la chaîne de traitement, et une seconde phase, P2, correspond à l'orchestration de l'exécution proprement dite de la séquence d'exécution.

La première phase P1 comprend une première étape S1 , consistant à fournir une représentation de cette chaîne de traitement sous la forme d'un squelette composé d'un ensemble orienté de nœuds, chaque nœud correspondant à un agent de la chaîne de traitement.

Cette étape S1 prend donc en entrée une première représentation du traitement qui peut être dépendant d'une technologie de formalisation quelconque et a pour but de la transformer dans une seconde représentation sous la forme d'un squelette.

En particulier, cette étape S1 peut comprendre une « désérialisation », selon laquelle le modèle d’exécution est traduit par le noyau depuis un langage descriptif (xml, yaml, json...) vers une représentation objet de notre approche du squelette algorithmique. Comme on le verra plus loin, le modèle d’exécution décrit ainsi les exécuteurs, les routines à appliquer et les enchaînements des processus.

Un squelette algorithmique, ou simplement "squelette", est un concept qui a été introduit dans Cole M. « Algorithmic skeletons: A structured approach to the

management of parallel computation », PhD Thesis, University of Edinburgh, Computer Science Dpt, Edinburgh 1988 ; ainsi que dans Cole M. « Algorithmic Skeletons: Structurée! Management of Parallel Computation ». Research Monographs in Parallel and Distributed Computing », Pitman/MIT Press: London, 1989

On peut définir un squelette comme un modèle haut-niveau de représentations d'un traitement particulièrement adapté à la description des aspects de parallélisassions haut-niveau et de distribution des calculs.

Un squelette peut être considéré, et construit, comme la composition de motifs particuliers dont chacun peut être lui-même un sous-squelette, et ceci de manière récursive. Des motifs terminaux s’inscrivent en tant qu’élément minimaux de squelette. Ce sont les motifs « map », « split » et « reduce ».

Différents motifs ont été décrits dans l'état de la technique. La figure 2 illustre 4 motifs : "map", "pipe", "farm" et "reduce ".Cette liste n’est pas exhaustive. Ainsi, on peut ajouter par exemple le motif « split » qui permet de transformer un flux de données en plusieurs flux sortants.

Le motif "map" décrit l'application d'un algorithme particulier à chaque élément d'une collection. Le motif "pipe" est une succession de motifs "map". Le motif "farm" désigne l'application en parallèle de plusieurs motifs "map". Le motif "reduce" synthétise plusieurs données pour n'en retourner qu'une seule (la somme de termes, par exemple).

Ces motifs sont décrits dans de nombreuses sources de l'état de la technique, par exemple dans « Patterns and Skeletons for Parallel and Distributed Computing », de Fethi A. Rabhi, Sergei Gorlatch ; ou bien encore dans E. Chis, Adriana & Gonzalez-Velez, Horacio. (2018). “Design Patterns and Algorithmic Skeletons: A Brief Concordance". 10.1007/978-3-319-73767-6_3.

Selon un mode de réalisation de l’invention, un squelette peut être vu comme une arborescence, dont chaque nœud correspond à un agent, et chaque agent représentant un "sous traitement".

Les liens entre les nœuds correspondent aux interfaces d'entrée et de sortie qui caractérise chaque agent. Chaque nœud correspondant à un agent, il peut donc être associé à une ou plusieurs routines (un agrégat de routines) et aux modalités d'exécution de ces routines.

La figure 3a schématise un exemple de squelette pour un traitement constitué d'une chaîne de sous-traitements, ou agents, 31 , 32, 33, 34.

Dans une étape S2, on décompose ce squelette en un graphe exhaustif, c'est-à-dire incorporant les implémentations possibles d'un agent donné par des modules logiciels disponibles.

Ces modules logiciels sont des fonctions offertes de façon autonome par des outils ou applications logicielles. Ainsi un agent est une vue abstraite d'une fonctionnalité qui peut être offerte, ou "instanciée" par un ou plusieurs modules.

Par exemple, un rééquilibrage de la balance des blancs dans une image peut être un agent qui peut être implémentés par des modules logiciels offerts par diverses applications de traitement numérique de l'image. Ces modules logiciels correspondent à des "technologies" distinctes, caractérisés par des modalités de fonctionnement spécifiques (structures de données, temps de calcul, performances....).

Dès lors, on peut différentier des noeuds génériques et des noeuds spécifiques. Un nœud spécifique ne peut être implémenté que par une unique technologie (c'est-à-dire par un unique module logiciel), tandis qu'un nœud générique peut être implémenté par au moins deux technologies (ou modules logiciels). Pour ces nœuds génériques, un choix doit donc être effectué, et un des avantages de l'invention est de permettre un choix automatique et transparent de l'implémentation d'un nœud générique.

Les différentes implémentations d'un agent peuvent être mémorisées dans une structure de données afin de pouvoir, à partir d'un nœud générique, déterminer l'ensemble des implémentations possibles.

Une fois déterminé l'ensemble des modules implémentant un agent, on peut construire un graphe exhaustif en remplaçant le cas échéant chaque nœud du squelette par un groupe de nœud, dans lequel chaque nœud correspond à un module logiciel pouvant mettre en œuvre l'agent correspondant au nœud remplacé. Bien sûr, dans le cas d'un nœud spécifique, celui-ci correspond directement au module logiciel (unique) implémentant l'agent en question, il n'y a pas de sens à le remplacer (ou bien, on peut considérer qu'il est remplacé par un groupe formé d'un singleton).

Ainsi, selon un mode de réalisation de l’invention, cette notion de squelette introduit une notion de récursivité : chaque élément, ou motif, d’un squelette peut former un sous-squelette qui peut lui-même se décomposer également en sous-

squelettes et ainsi de suite jusqu’à des motifs élémentaires, formant feuilles de l’arborescence globale. Ce squelette peut donc être considéré comme un modèle descriptif multi-niveau, intégrant en leur sein le modèle relatif à l’environnement d’exécution. Ainsi, un agent d’exécution peut être l’agrégation d’un ensemble de sous-agents dédiés à des tâches qui leur sont propres.

La figure 3b illustre un tel graphe exhaustif basé sur l'exemple de la figure 3a. Sur ces deux figures, les « textures » à l'intérieur des noeuds correspondent aux technologies. Les noeuds 31 et 33 correspondent ainsi à des technologies distinctes (c'est-à-dire qui doivent être implémentés par des modules distincts) tandis que les noeuds 32 et 34 sont des noeuds génériques (en blanc). Dans cet exemple, on suppose que deux modules logiciels sont disponibles.

Le nœud 31 est un nœud spécifique, c'est-à-dire qu'un seul module logiciel disponible permet de l'implémenter. Ce nœud est donc conservé dans le graphe exhaustif tel quel.

Le nœud 32 est un nœud générique, il est donc remplacé par un groupe 32a, 32b, chacun de ces deux nœuds correspondant aux deux modules logiciels permettant de mettre en œuvre l'agent du nœud 32.

Le nœud 33 est un nœud spécifique ; il est donc conservé dans le graphe exhaustif tel quel. Le nœud 34 est un nœud générique, il est donc remplacé par un groupe 34a, 34b, chacun de ces deux nœuds correspondant aux deux modules logiciels permettant de mettre en œuvre l'agent du nœud 34.

Ainsi, le graphe exhaustif est un graphe orienté allant de la donnée à traiter vers le résultat final. Chaque nœud correspond à une routine de calcul. Les nœuds d'un même niveau correspondent à une alternative technologique. Chaque agent générique génère autant de chemins alternatifs que de technologies implémentent une solution à cette routine.

Dans une étape S3, on affecte des coûts à chaque nœud et à chaque transition entre les nœuds.

Les coûts affectés à un nœud peuvent comprendre notamment un temps d'exécution. Les coûts affectés aux transitions entre nœuds peuvent comprendre les temps de transfert de données entre le noyau et les modules logiciels ainsi que les temps de traduction des données vers et depuis ces modules logiciels. En effet, chaque module logiciel (technologie) est associé à des formats de données

particuliers et les changements de format impliquent nécessairement des temps de calcul propres.

Ces différents temps peuvent être obtenus à partir de modèles théoriques, qui peuvent se baser sur la connaissance des infrastructures de déploiement, mais aussi sur des données empiriques. Par exemple, des benchmarks peuvent être préalablement prévus sur des ensembles de données tests afin de fournir ces différents temps.

Toutefois, d'autres coûts, et d'autres combinaisons de coûts sont également possibles.

Dans une étape S4, on détermine un graphe optimal en choisissant un chemin minimisant ces coûts. La figure 3c illustre un tel graphe optimal dans le cas de l'exemple des figures 3a et 3b. Le choix d'un chemin passe par la sélection d'un unique nœud pour chaque groupe de nœuds d'un même niveau, c'est-à-dire correspondant à un même agent de calcul. Autrement dit, cette étape consiste à sélectionner, pour chaque agent, un module logiciel permettant de l'implémenter.

Ce choix, basés sur les coûts, permet de prendre en compte bien sûr les performances des différents modules disponibles (temps d'exécution...), mais aussi les interactions engendrées par chaque choix (temps de traduction...). En effet, il peut par exemple être plus intéressant de sélectionner un module offrant des performances moindres qu'un autre, mais impliquant moins de traduction de données avec les modules amont et/ou aval de la chaîne de traitement.

Dans une étape S5, le traitement composé de l'ensemble des agents de calcul peut être exécuté sur la plateforme de traitement en orchestrant les appels vers les différents modules logiciel. Plus précisément, il s'agit de parcourir le graphe optimal et d'appeler séquentiellement les modules logiciels de chaque nœud en assurant les traductions et synchronisation entre chaque appel.

Ainsi quand deux agents successifs du traitement sont mis en œuvre par des modules logiciels distincts, le noyau assure les traductions des données depuis le format associé au module amont vers le format associé au module aval. Dans l'exemple de la figure 3c, les nœuds 31 et 32b correspondent à des modules logiciels distincts, une traduction de données est donc nécessairement mise en place par le noyau pour traduire le résultat de l'exécution du nœud 31 en tant qu'entrée du nœud 32b.

Le noyau assure également la synchronisation, c'est-à-dire à la transmission des données vers et depuis chaque module logiciel. La mise en oeuvre de ces transmissions dépend de la plateforme de traitement sous-jacente et des applications logicielles mettant à disposition les modules logicielles implémentant les agents de calcul. Par exemple, les transmissions peuvent être assurées par des mécanismes d'espaces mémoires partagés (« memory mapping »), ou d'un fichier, ou d'un flux de données dans le cas d'une topologie distribuée de la plateforme de traitement sous-jacente.

Selon un mode de réalisation, les agents représentent des associations entre une ou plusieurs routines et les modalités d'exécution instanciées par des exécuteurs (ou « executors » en langue anglaise). Ces exécuteurs sont des abstractions de plusieurs éléments dédiés à l'exécution d'une routine. Des travaux de standardisation (RFC C++20/23) proposent une formalisation de cette notion d'exécuteur. L’approche décrite ici est généralisée afin de prendre en compte la distribution multiprocessus sur des ressources d'exécution.

La bibliothèque standard du Java propose également une interprétation et une implémentation des executors, différant notamment par les options configurables lors de l’exécution.

Un exécuteur peut contenir un ensemble de modèles, des métadonnées décrivant les ressources d'exécution, le contexte les agents exécutant les calculs.

Il répond aux questions suivantes : ce qu’il doit exécuter (la routine), comment il doit l’exécuter (en parallélisant les calculs ou non par exemple, il s’agit de la stratégie), et avec quelles ressources (inhérentes aux unités de calcul par exemple).

Les ressources d'exécution sont les unités de calcul utilisables par le programme. Un CPU ou un GPU est ainsi une ressource. Le modèle de ressource d'exécution décrit ainsi les fonctionnalités fondamentales de cette ressources : sa compétence de vectorisation des calculs, ses opérations fondamentales de mesure de performance, ses compétences de mémorisation, etc.

Le contexte d'exécution et une agrégation d'une ressource et d'un ensemble d'agents. Ainsi, il est possible de spécifier un contexte en tant que multithread partiel d'un seul processeur. Le contexte décrit ainsi la manière d'exécuter les routines avec une ressource, par le biais des agents.

Les agents correspondent aux unités fondamentales d'exécution d'un calcul, tel qu'un thread (ou fil d'exécution). Chaque agent exécute une tâche.

En outre, la stratégie d'exécution d'un exécuteur peut être paramétrée par la définition de stratégies. Ces dernières permettent de caractériser la mise en priorité de l'exécution des tâches (première arrivée, première exécutée, par exemple) et la manière d'agréger les sous-nœuds d'un motif du squelette.

Il est à noter que les squelettes algorithmiques présents dans la littérature (tels que Skepu2, ArrayFire, Muesli...) ne considèrent pas du tout la personnalisation du modèle d'exécution par l'explicitation de la ressource. Ainsi, ces outils ne permettent que la rédaction d'un code hétérogène CPU/GPU sans aucune considération de l'approche multiprocessus. Dans certains cas, le choix de l'unité de calcul est défini par implémentation: cela signifie qu'un algorithme particulier n'est accessible que sur une seule ressource.

La synchronisation des données est ainsi gérée par le squelette sans aucune paramétrisation possible et est rendue implicite pour le développeur. Si l'approche implicite permet de faciliter la rédaction d'un code source pour le développeur, l'opportunité d'explicitation permet des optimisations à la rédaction du code source et un choix dans la distribution de calcul.

La détermination des ressources réelles affectées aux ressources exprimées par les exécuteurs se font au moment de l'exécution du noyau, c'est-à-dire en fonction des ressources effectivement disponibles.

Lors de l'étape S2 de décomposition du squelette en un graphe exhaustif, on associe à chaque nœud un exécuteur. Si celui-ci n'a pas été préalablement déterminé (ce qui est le cas lorsqu'un nœud générique est décomposé en un groupe de nœuds), Par défaut, un nœud hérite de l'exécuteur issu de son nœud parent.

Lors de la génération du graphe optimal, les exécuteurs peuvent être utilisés pour définir les étapes de synchronisation des données.

Ainsi, chaque nœud du graphe optimal est nécessairement lié à un exécuteur. Lorsqu’un nœud soumet une tâche, dans l'étape d'exécution S5, il le soumet à l'exécuteur associé.

Les mécanismes des modes de réalisation décrits peuvent s’appliquer à différents cas pratiques d’utilisation. Un exemple d’applications peut être une chaîne de traitement de données permettant de générer de manière automatique la vignette d’une image. Cette vignette, d’une dimension inférieure à l’image d’origine, est une miniature représentant la partie signifiante de l’image d’origine.

Cette chaîne peut comporter une interface utilisateur et un ensemble de traitements algorithmiques.

L’interface utilisateur peut être mise en oeuvre via un service web, en utilisant une requête http. L’utilisateur peut par exemple transmettre l’image de deux façons : en précisant un lien valide (ou URL) permettant de la télécharger, ou bien en indiquant le contenu de l’image sous format base64.

L’ensemble de traitements algorithmiques comprend ensuite :

- la traduction du format de l’image en un format générique propice au traitement de données ;

- l’application d’un algorithme de recherche de la partie signifiante de l’image, comportant :

o sous-échantillonnage de l’image pour accélérer le calcul ;

o préparation des pixels et traitement pour la création d’un score de pertinence ;

o calcul des scores optimaux par l’utilisation de fenêtres glissantes, chaque fenêtre glissante possédant les dimensions de la miniature finale ;

o sélection de la fenêtre optimale ;

- extraction de la sous-partie de l’image correspondant à cette fenêtre optimale ;

- transformation de l’image dans un format spécifique (png, jpeg, webp...) et compression ;

- enregistrement de l’image dans une zone de téléchargement pour que l’utilisateur puisse la récupérer.

Plusieurs critères peuvent permettre d’évaluer les avantages de l’invention par rapport à des solutions selon différentes propositions de l’état de la technique : la réutilisabilité, l’interopérabilité et la distribution.

La réutilisabilité d’un code source définit ici son potentiel de réemploie dans des contextes différents. Cela permet de capitaliser sur des éléments déjà conçue en amont d’un projet informatique et de réduire ses coûts de développement.

L’interopérabilité d’un programme désigne sa capacité à pouvoir communiquer avec d’autres programmes. Nous employons le terme d’interopérabilité native pour classifier deux programmes informatiques communiquant avec les mêmes formats de données et ne nécessitant pas de traduction de ces dites données pour être utilisées. L’interopérabilité forte d’un système (programme, bibliothèque, service) permet de le rendre réutilisable, et donc de réduire les coûts ultérieurs de développement.

La distribution d’un programme désigne l’action d’exécuter tout ou partie d’un programme plusieurs fois, potentiellement sur plusieurs machines. Ainsi, l’ensemble de ces instances de ces éléments distribués peuvent réaliser de manière simultanée, des opérations similaires. À l’instar de la parallélisation, la distribution permet d’augmenter la performance d’un logiciel en augmentant le nombre de tâches similaires exécutées en même temps.

Différentes approches sont possibles, sans mettre en jeu les mécanismes des modes de réalisation de l’invention.

a- une première approche consiste en la rédaction du programme dans un langage unique

Le développeur utilise un langage unique pour rédiger le code source de ce programme, il peut s’appuyer sur des bibliothèques déjà existantes pour chacune de ces parties (si elles existent) et les faire travailler ensemble.

Exemple

Le développeur utilise le langage C++ pour rédiger son programme. Il utilise ainsi les bibliothèques suivantes :

- Libcurl permet d’assurer le téléchargement de l’image depuis une url distante

- OpenCV permet de traduire l’image depuis un format a en format utilisable pour le calcul, en s’appuyant sur d’autres bibliothèques telles que libpng, libjpeg, libtiff...

- Le développeur utilise le langage C++ pour effectuer le calcul sur les données

- La bibliothèque standard du C++ est employée pour générer un lien vers une image

- L’outil dédié d’Amazon Web Services (AWS SDK) permet de téléverser le résultat au sein d’un espace de stockage distant pour que l’utilisateur puisse la télécharger

Le résultat final est un exécutable ou une bibliothèque dans un langage particulier, qui n’est pas nativement opérable avec d’autres langages. Le tout est un produit insécable, dont chaque partie doit être dupliquée dans tout autre programme souhaitant réaliser les étapes similaires.

b - une autre approche consiste en la séparation des étapes dans des services différents : bibliothèques

Afin de proposer des éléments réutilisables, le développeur peut séparer chaque étape de son processus, grâce à des bibliothèques. La rédaction d’un autre produit de traitement d’image peut ainsi réutiliser ces parties de logiciel sans avoir à les réécrire. Cette démarche autorise la réutilisabilité mais ne prend absolument pas en compte le caractère d’accélération du calcul en le distribuant.

c - une autre approche consiste en la séparation et distribution du processus complet

Pour fournir une solution réutilisable et distribuée, le développeur peut distribuer l’intégralité de la solution décrite dans la section a, intégrant des bibliothèques dans la section b grâce à des outils tels que SLURM et OpenMPI. SLURM fournit des service pour distribuer un processus sur un ensemble d’ordinateur, tandis qu’OpenMPI propose des fonctionnalités pour les faire communiquer entre eux. Ainsi, plusieurs instances du même programme sont exécutées de manière simultanée.

Cette démarche possède une interopérabilité faible puisque le résultat final est propre à une technologie précise. Le processus distribué ne communique qu’avec les images à traiter et avec l’ensemble des processus enfants exécutés simultanément.

d - encore une autre approche consiste en la création de services interopérables natifs

Dans le but de répondre au dernier critère d’évaluation, le développeur peut proposer la création de solutions nativement interopérables. Des extensions des technologies ciblent sont rédigées afin d’étendre leurs compétences. Java par

exemple peut utiliser un processus C++, nativement (sans avoir besoin de traduction des données à traiter) grâce à l’utilisation de l’outil JNI.

L’interopérabilité est ainsi locale, puisque deux processus rendus communiquant de cette manière agissent comme un programme intégrant une bibliothèque. L’avantage particulier est la performance obtenue par l’absence de besoin de traduction d’un format de donnée a en format de donnée b. Cependant, il est nécessaire de réaliser cette étape de liaison native pour chaque association de technologie.

Cette approche est complexe et longue à mettre en place pour un développeur et est étroitement dépendante de l’évolution technologique des deux langages communiquant.

e - une autre approche consiste en la création de services web

Pour réduire la complexité de mise en oeuvre d’une solution interopérable, le développeur peut s’appuyer sur la formalisation des protocoles de communication, tels que http et gRPC.

Ces réponses plus simples à mettre en oeuvre que les services natifs, sont interopérables avec n’importe quelle technologie fournissant une interface compatible avec des protocoles. Cependant, elles nécessitent des étapes de copie de données et de traduction de format qui peuvent être coûteuses en temps de calcul et en bande passante.

Au contraire, selon une réalisation mettant en oeuvre l’invention, on obtient une simplification des étapes décrites précédemment. Cette approche permet, en particulier de réutiliser chacune des parties du programme, en proposant une démarche de distribution du calcul simplifiée, en laissant libre choix à l’utilisateur du caractère natif de l’interopérabilité proposée.

En outre, l’utilisation des squelettes algorithmiques permet de préciser plusieurs niveaux de distribution du calcul et de parallélisation.

Ainsi, nous pouvons aller à un niveau de détail plus fin de l’explicitation de la manière dont sera exécuté le processus final.

Le principal avantage est le gain de temps certains. Le développeur peut concevoir des modules réutilisables dans des technologies différentes (C++, Java, C#...) et décrire les enchaînements de chaque étape d’un point de vue macro. S’il le souhaite, il peut expliciter la manière fine dont sera exécutée chaque étape en précisant le type de tâche (tâche générique ou spécifique) et le type de ressource de calcul mis en oeuvre (quelle machine sera employée). Sinon, la solution inventive propose de résoudre cette question par l’emploi d’heuristiques dédiés à l’optimisation des calculs selon les types de données, des étapes des processus requises et de l’infrastructure machine mise à disposition.

Le tableau suivant permet de mettre en correspondance les approches de l’état de la technique décrites (a, b, c, d, e) et celle basée sur un mode de réalisation de l’invention, suivant les trois critères d’évaluation (réutilisabilité, interopérabilité, distribution) et le temps de développement. On attribue une note à chaque approche et pour chaque critère allant de 0 à 3 pour les trois premiers et de 1 à 5 pour le temps de développement estimé (1 étant le plus court).


Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art.