EP1082656A1 - Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles - Google Patents

Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles

Info

Publication number
EP1082656A1
EP1082656A1 EP00915272A EP00915272A EP1082656A1 EP 1082656 A1 EP1082656 A1 EP 1082656A1 EP 00915272 A EP00915272 A EP 00915272A EP 00915272 A EP00915272 A EP 00915272A EP 1082656 A1 EP1082656 A1 EP 1082656A1
Authority
EP
European Patent Office
Prior art keywords
application
placement
model
data
constraints
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00915272A
Other languages
German (de)
English (en)
Inventor
Juliette Thomson-CSF Prop. Intellectuell MATTIOLI
Christophe Thomson-CSF Prop Intellect. GUETTIER
Jean Thomson-CSF Propriété Intellectuelle JOURDAN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Thomson CSF SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales SA, Thomson CSF SA filed Critical Thales SA
Publication of EP1082656A1 publication Critical patent/EP1082656A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Definitions

  • the present invention relates to a generic method for assisting with the placement of signal processing applications on parallel computers.
  • the placement (“Mapping” in English) consists in distributing the data and the processing linked to a processing, such as a signal processing application, on a computer, generally a computer with parallel architecture. This placement is static, because all of the placement choices are made before the execution of the placed application, unlike dynamic placement. Many tools and programming environments are known for carrying out the placement. These include, among others, the INDE SynDEx tool for signal and image processing, the PTOLEMY tool from the University of Berkeley, the HPF for scientific computing, the "FX compiler”, the GEDEA from the company LOCKHEED MARTIN, ... However, few known tools allow complete automation of the placement.
  • the Ptolemy environment is essentially an environment for simulating and prototyping heterogeneous systems integrating material and software.
  • the subject of the present invention is a generic method for assisting the placement of systematic signal processing applications on a computer with a homogeneous parallel architecture, a method which makes it possible to automatically obtain at least one optimized placement solution, at a granularity level. as fine as possible, and this, from a complete functional description of the application, and of the computer used.
  • the method according to the invention consists, for each functional and physical component of the application, in establishing a model defined by a set of relationships on the different variables relating to this component, in order to model the constraints, to be solved concurrently the relationships thus established, to deduce at least one solution, and, if several solutions are obtained, to choose the one optimizing at least one criterion.
  • the constraints are those relating to the sub-functions of the placement function, namely: partitioning, alignment, data distribution and processing sequencing.
  • the present invention will be better understood on reading the detailed description of an embodiment, taken by way of nonlimiting example and illustrated by the appended drawing, the single figure of which is a functional diagram of the placement function, implemented in accordance with the invention.
  • the present invention relates to systematic signal processing, that is to say unconditional, not subject to external orders or actions. This treatment is, moreover, deterministic and structured.
  • This processing can be, for example, of the compression of pulses or the computation of Fourier transforms (FFT).
  • FFT Fourier transforms
  • Systematic signal processing applications are made up of task sequences, which can be expressed by well-structured and parallel loop nests (nested loops and defined bounds).
  • Each loop nest contains a call to a procedure or macro-instruction generally corresponding to an array transformation, that is to say to a function of a signal processing library such as an FFT.
  • a signal processing library such as an FFT.
  • the processing operations are regular (not subject to external tests) and are carried out on multi-dimensional signals, the data are organized in large tables whose dimensions (for example source, frequency, recurrence time, pointing time) carry the vectors on which the individual treatments will be carried out.
  • the table easily adapts to the dimensions of the sensor system, and allows the mathematical formulation of the treatments to be given by computer.
  • the indices of the variables making up the formulas become table indices.
  • a task also called a routine, procedure or processing, accepts one or more data streams as input and output.
  • a flow represents the data accessed in read or write by one and only one elementary processing. All of this data constitutes a basic access or domain of elementary transformation. The same treatment is repeated on an iteration space defined by the application.
  • the formulation of the treatment it describes the formula of the elementary transformation.
  • the output data is expressed in terms of the input data.
  • the basic read or write accesses are specified according to the indices of the tables.
  • the dimensions of the arrays and the memory space required to execute a treatment on the whole iteration space of the treatment are also specified.
  • the data flow can be conditioned by the data or the indices of the tables (it depends on the application).
  • properties are associated with data flows:
  • Acquisition is considered to be a full-fledged task including an output stream, and a recurrence (acquisition frequency).
  • a data flow graph (Data Flow Graph) can be used which can come from any conventional formalism for description of signal application subject to that it contains the information specified above.
  • TSS systematic signal processing
  • a data flow graph (Data Flow Graph) can be used which can come from any conventional formalism for description of signal application subject to that it contains the information specified above.
  • Placement is the automatic distribution of signal processing operations to be performed on a data stream, and these data themselves, on a computer with a parallel multiprocessor architecture taking into account the different constraints of material resources as well as the performances imposed on the computer.
  • the parallel architecture in question here is a homogeneous parallel architecture, in which all the processors are identical, of the SIMD / SPMD (“Single Instruction / Program Multiple Data”) type, that is to say in which all the processors execute the same instruction or the same sequence of instructions (for example a program) on different data.
  • the routing of information between the different processors is static, that is to say that the data paths between processors are imposed before the initialization of each mode (they are defined during the compilation of the application ).
  • the macro-instructions executed in parallel on each of the processors are identical.
  • the data necessary for the processing of the macro-instruction must reside in the local memory of the processor which executes it.
  • the “dimensions” of the architecture of the computer used are imperative placement constraints. However, these constraints are not taken into account by conventional automatic placement methods (such as the methods cited above) and are therefore not treated for this purpose in the state of the art.
  • the characteristic parameters of said dimensions are:
  • the power of a processor For real-time signal processing applications, the latency of the calculations (time after which the results of these calculations are available) is very important. This time can be limited by a maximum value, and it depends on the power of the processor that performs the calculation. This power is expressed in number of calculation cycles per second.
  • the placement discussed here includes the four sub-functions of alignment partitioning, distribution and sequencing. Until now, these four sub-functions have been dealt with separately. On the other hand, the present invention provides for treating these sub-functions simultaneously and concurrently.
  • This placement makes it possible to find the adequacy between a program (whose parallelism is specified or not) and a computer with homogeneous parallel architecture as specified above. It consists in distributing the processing and the data on the various processors of the computer and establishing their sequencing, by optimizing the parallelism of the application.
  • constraints are, on the one hand, “application” constraints (linked to the size of the specific elementary tasks of systematic signal processing), on the other hand, constraints linked to the architecture of the computer (number of processors, memory capacity , topology of the processor network and data throughput, and finally constraints linked to execution (fine-grained scheduling, overlap between data communications and the calculations performed).
  • Constraints modeling essentially consists in establishing, for each constraint, a relation between at least two variables or a relation between a variable and a given value (generally a threshold). This relation is a linear relation (generally a polynomial of the 1st degree).
  • the method of the invention starting from this modeling, performs the concurrent (non-sequential) resolution of all the models, to deduce therefrom one or more solutions satisfying all the constraints.
  • the goal is to optimize different criteria such as the latency of the application or the (financial) cost of the target architecture.
  • many models specific to the placement problem have been developed and complete the description of the problem, such as communications or physical time. Given the number of tasks and the number of data to consider during placement, each model is defined by intention rather than extension.
  • the possibility of working at several levels of granularity is fundamental for the placement problem, and we use for this an algebraic formulation of partitioning. This fixes the granularity of the other models, so it maintains many relationships within the conceptual model.
  • dependency constraints often link several models, so these are global constraints and the cornerstone of the problem to be solved.
  • there are local heuristics to one or more models However, there is no known overall heuristic.
  • the heart of the present invention uses the multi-model approach by concurrent constraints [J. Jourdan, F. Fages, D. Rozzonelli & A. Demeure, "Data Alignment and Task Scheduling On Parallel Machines Using Concurrent Model-based Programming", Proc. ILPS 94, 1994], which makes it possible to grasp the problem of automatic placement in a global manner.
  • the models are established on the basis of one model per constituent, whether functional or physical. By definition, a model must be seen as the set of specifications for the behavior of the constituent it models.
  • the functional diagram of the single figure of the drawing shows the different models implemented for the “placement” function referenced 1 as a whole. These models are: the architecture of the target processors (2), the memory capacity (3), the partitioning of data flows (4), inter-processor communications (5), event scheduling or calculation sequencing (6), the physical time or calculation time (7) and the signal inputs and outputs (8).
  • the different links established between these models are of two kinds: the “hyperlinks” represented by complex arrows (9, 10) in the form of irregular polygons, which each link several models together, and simple links, represented by arrowed lines each. at their ends and each connecting two models.
  • the complex arrow 9 which corresponds to the “number of processors” criterion, links the models 2, 3, 4 and 5.
  • Model 2 is linked by simple links to models (3) (“memory size” criterion), 5 (“bandwidth” criterion) and 6 (“programming mode” criterion).
  • Model 3 and linked by simple links to models 4 (“data volume” criterion) and 6 (“distance and cardinality” criterion).
  • Model 4 is linked by a simple link to model 7 (“calculation volume” criterion).
  • Model 5 is linked by simple links to models 6 (“communication events” criterion) and 7 (“communication duration” criterion).
  • Model 6 is linked by a simple link to model 7 (“distance and cardinality” criterion).
  • model 7 and linked by a simple link to model 8 (“latency and recurrence” criterion).
  • the specifications of the behavior of the various constituents of these models are expressed on the basis of mathematical relationships. We can therefore deduce that the models are identified with the set of relationships defined on their variables. These relations are either primitives of the language used (primitives forming part of a library of relations), or relations defined by the user.
  • compositionality The composition of relational models is quite simply the logical conjunction of the relationships that constitute the model. This implies a simple semantics of compositionality.
  • the set of solutions of a composite model is quite simply the intersection of the solutions of the models. They contribute to the universality of the program.
  • the properties of the induced process are then: •
  • a wider field of use A model can be used in several contexts depending on the goal to be achieved.
  • the state of a system is characterized by the content of the memory at a given instant.
  • the basic operations are reading and writing to or from memory.
  • the state of a system is then characterized only by the set of values of the memory boxes associated with the variables that compose it.
  • the fundamental difference between the method of the invention and the other software solutions is the representation of this memory.
  • the memory is not reduced to a set of memory boxes but constitutes in itself a constraint.
  • the latter is capable of providing partial information on all the variables which make up the system. It is interesting to note that all the reasoning implemented by the constraints is based on this paradigm of manipulation of partial information. The advantage of constraints is simply that the system being developed can make decisions without having to wait for it to be fully determined.
  • the resolution of industrial applications is not confined to a well-defined problem, but integrates the combination of several sub-problems.
  • Combinatorial optimization problems must be solved on multi-component, multifunctional problems in which the constraints are very heterogeneous and where the different elements at different levels of granularity must be considered.
  • the invention offers solutions allowing the coexistence of partially overlapping, coordinating and decomposing models.
  • the invention makes it possible independently of the heterogeneity of the constraints, by simple local interactions, to guarantee a global coordination of the system.
  • the method of the invention offers a good technological solution, because it allows, during the resolution, the concurrent use of all the redundant models.
  • the architecture which is in fact a set of parameters such as the number of processors, bandwidth, ...
  • the memory which defines through a capacity constraint for which one is sure to be able to calculate an allocation.
  • the real time signal which consists of latency and input / output constraints (periods, ).
  • a model consists of definitions of variables on which the model-specific constraints are based.
  • the method of the invention allows both to solve the problem of automatic placement of signal processing applications on parallel machines and allows the user to manipulate a solution provided without violating the constraints posed by the overall system. This approach is part of a context of codesign and virtual prototyping.
  • the user has configured his machine with an insufficient number of processors for the type of placement he wishes.
  • the method will make it possible to find the minimum number of processors necessary for the placement imposed in the set of available processors.
  • the user can impose a sequencing of calculations.
  • the system will then find the partitions, that is to say the distributions of data and calculations in memory and on the appropriate processors. > Likewise, the user can impose an initial partitioning, the system will find compatible schedules.
  • the process makes it possible to specify the resources necessary to place a particular application on a given type of machine without violating the application constraints. This consists in taking into account the dimensions and the number of each hardware component
  • Machine dimension the process makes it possible to configure a minimum machine for a given application.
  • the user can, for example, choose to configure a machine with a minimum number of processors.
  • Latency the process makes it possible to find the placement (s) that minimize (s) the execution time of the application on a target machine predefined by the user.
  • Cost by integrating a cost (financial for example) on each of the hardware components, the process allows find the placement (s) of the application that minimizes this cost.
  • Machine occupancy time the process makes it possible to find the placement (s) which minimizes (s) the occupation time of the target machine predefined by the user in order to be able to possibly place a second application .

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Le procédé de l'invention, destiné au traitement de signal systématique sur un calculateur multiprocesseur à architecture parallèle homogène, consiste à établir, pour chaque constituant fonctionnel et physique de l'application, un modèle défini par un ensemble de relations sur les différentes variables relatives à ce constituant, afin de modéliser les contraintes, puis à résoudre de façon concurrente ces relations, et à en déduire au moins une solution.

Description

PROCEDE GENERIQUE D'AIDE AU PLACEMENT D'APPLICATIONS DE TRAITEMENT DE SIGNAL SUR CALCULATEURS PARALLELES
La présente invention se rapporte à un procédé générique d'aide au placement d'applications de traitement de signal sur calculateurs parallèles.
Le placement (« Mapping » en anglais) consiste à distribuer les données et les traitements liés à un traitement, tel qu'une application de traitement de signal, sur un calculateur, en général un calculateur à architecture parallèle. Ce placement est statique, car l'ensemble des choix du placement est pris avant l'exécution de l'application placée, contrairement au placement dynamique. On connaît, pour réaliser le placement, de nombreux outils et environnements de programmation. On citera, entre autres, l'outil SynDEx de l'INRIA pour le traitement de signal et d'image, l'outil PTOLEMY de l'Université de Berkeley, le HPF pour le calcul scientifique, le « FX compiler », le GEDEA de la Société LOCKHEED MARTIN, ... Cependant, peu d'outils connus permettent l'automatisation complète du placement. De plus, même si l'objectif général des outils tels que SynDEx ou GEDEA est de fournir à l'utilisateur une aide au développement et à l'optimisation d'applications temps réel implémentées sur une architecture multiprocesseurs, généralement hétérogène, en vue de la réalisation rapide de prototypes, ces outils ne gèrent qu'un niveau de granularite grossier (la granularite étant le degré de finesse et de précision que l'on veut obtenir pour une application et son implémentation sur une architecture donnée). L'environnement Ptolemy est essentiellement un environnement de simulation et de prototypage de systèmes hétérogènes intégrant du matériau et du logiciel.
De plus, tous ces systèmes connus permettent, en général, d'estimer les performances d'un placement pour une solution donnée, tout en indiquant le réseau de communication entre processeurs le plus efficace, ainsi qu'un code généré automatiquement pour chacun des processeurs du système.
C'est pourquoi, les langages dédiés, tel le HPF, proposent des primitives de placement manuel. A partir de ces primitives, le programmeur doit déterminer lui-même le bon placement. Il en résulte que l'utilisation des ressources offertes par des super-calculateurs comportant de très nombreux processeurs est loin d'être optimale, tant la fonction de placement est complexe. En effet, cette fonction inclut le découpage, la distribution et l'alignement des données sur les différents processeurs, la répartition des tâches de calcul et de communication, ainsi que leur ordonnancement dans le temps. De plus, chaque choix relatif à l'une de ces fonctions est intimement lié à l'architecture du calculateur et aux caractéristiques physiques des architectures parallèles.
La présente invention a pour objet un procédé générique d'aide au placement d'applications de traitement de signal systématique sur un calculateur à architecture parallèle homogène, procédé qui permette d'obtenir automatiquement au moins une solution optimisée de placement, à un niveau de granularite aussi fin que possible, et ce, à partir d'une description fonctionnelle complète de l'application, et du calculateur utilisé. Le procédé conforme à l'invention consiste, pour chaque constituant fonctionnel et physique de l'application, à établir un modèle défini par un ensemble de relations sur les différentes variables relatives à ce constituant, afin de modéliser les contraintes, à résoudre de façon concurrente les relations ainsi établies, à en déduire au moins une solution, et, en cas d'obtention de plusieurs solutions, à choisir celle optimisant au moins un critère.
Les contraintes sont celles relatives aux sous-fonctions de la fonction de placement, à savoir : le partitionnement, l'alignement, la distribution de données et le séquencement des traitements. La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de mise en œuvre, pris à titre d'exemple non limitatif et illustré par le dessin annexé, dont la figure unique est un schéma fonctionnel de la fonction placement, mise en œuvre conformément à l'invention. La présente invention se rapporte au traitement de signal systématique, c'est-à-dire non conditionnel, non soumis à des ordres ou actions extérieurs. Ce traitement est, en outre, déterministe et structuré. Ce traitement peut être, par exemple, de la compression d'impulsions ou le calcul de transformées de Fourier (FFT). Les applications de traitement du signal systématique sont formées de séquences de tâches, que l'on peut exprimer par des nids de boucles (boucles imbriquées et à bornes définies) bien structurés et parallèles. Chaque nid de boucles contient un appel à une procédure ou macro-instruction correspondant en général à une transformation de tableau c'est-à-dire à une fonction d'une librairie de traitement du signal telle qu'une FFT. Une telle transformation a été décrite dans le brevet français n° 2 732 787. Les traitements sont réguliers (non soumis à des tests extérieurs) et s'effectuent sur des signaux multi-dimensionnels, les données sont organisées en grands tableaux dont les dimensions (par exemple source, fréquence, temps de récurrence, temps de pointage) portent les vecteurs sur lesquels vont s'effectuer les traitements individuels. Le tableau s'adapte facilement aux dimensions du système de capteurs, et permet de donner informatiquement la formulation mathématique des traitements. Ainsi, les indices des variables composant les formules deviennent des indices de tableaux.
Ces procédures ont un coût d'exécution fixé, inclus dans la spécification de l'application. Celle-ci est globalement représentée par un graphe de flot de données acyclique. L'application est, en effet, sous forme d'assignation unique, c'est-à-dire que chaque élément de tableau n'est mis qu'une seule fois à jour par l'application. Dans une mise en œuvre parallèle, la distribution de ce grand tableau sur les nœuds de calcul change d'un traitement au suivant, provoquant ainsi un problème classique du parallélisme : le changement d'axe, ou « corner turn », consommant beaucoup de ressources de communication.
Pour pouvoir mettre en œuvre l'invention, il faut décrire fonctionnellement l'application de traitement de signal, et plus particulièrement les composantes de cette applications, à savoir les tâches. Une tâche, aussi appelée, routine, procédure ou traitement, accepte en entrée et en sortie un ou plusieurs flux de données. Ces flux sont définis à partir des tableaux d'entrée et de sortie, de la façon exposée dans le susdit brevet français n° 2 732 787, et que l'on rappelle succinctement ci- dessous. Sur chaque tableau considéré, un flux représente les données accédées en lecture ou écriture par un et un seul traitement élémentaire. L'ensemble de ces données constitue un accès élémentaire ou domaine de la transformation élémentaire. Un même traitement est réitéré sur un espace d'itération défini par l'application. Certaines propriétés sont associées à ce nœud du traitement :
• La formulation du traitement : elle décrit la formule de la transformation élémentaire. Les données de sortie sont exprimées en fonction des données d'entrée. Les accès élémentaires en lecture ou en écriture sont spécifiés en fonction des indices des tableaux. Les dimensions des tableaux et l'espace mémoire requis pour exécuter un traitement sur tout l'espace d'itération du traitement sont également spécifiés.
• La complexité du calcul : elle exprime la puissance de calcul requise par le nœud de traitement en opérations/seconde. Elle est liée à l'architecture utilisée, et représente une donnée d'entrée de l'application.
Le flux de données peut être conditionné par les données ou les indices des tableaux (il dépend de l'application). Comme pour les nœuds, des propriétés sont associées aux flux de données :
• Le codage des données. Celles-ci sont codées sur un certain nombre de bits (12-16-32-64-...), elles représentent généralement des nombres réels à virgule fixe ou bien des nombres complexes (codés sur deux nombres entiers).
• La récurrence d'un flux. Cette valeur est une fonction de la puissance de calcul des traitement dont le flux provient des récurrences des flux entrants de ce même traitement.
• L'acquisition est considérée comme une tâche à part entière comprenant un flux de sortie, et une récurrence (fréquence d'acquisition).
• Le nombre de données liées à une transformation élémentaire. Il définit le nombre de données que requiert la transformation élémentaire du nœud destination. Ces données sont dites produites par le nœud source et dites consommées par le nœud destination. Toutefois, il arrive que des données soient calculées et non utilisées par la suite (on n'exploite pas la totalité des données d'une bibliothèque, qui peut être d'usage général), ce qui n'implique pas de duplication de calcul.
Les accès élémentaires à un tableau sont des fonctions affines des indices de ce tableau, des constantes et des variables scalaires privées. L'espace d'itération d'un traitement est quant à lui complètement défini par des fonctions affines portant uniquement sur les indices des différents tableaux.
Plus précisément, une tâche se décompose en deux parties :
• L'espace d'itérations externe décrivant le domaine de calculs. L'une des dimensions peut être infinie. Elle représente le temps. Ce domaine est représenté par un nid de boucles parfaitement imbriqué et totalement parallèle. Il n'y a aucune dépendance en écriture, par contre, il peut exister des recouvrements en lecture. C'est ce domaine de calculs qu'il faut placer et ordonnancer sur la machine parallèle.
• L'espace d'itérations interne décrivant l'ensemble des données qui sont utiles au calcul de la macro-instruction ou procédure. Les fonctions d'accès aux éléments de tableau sont des fonctions pseudo-affines. Des fonctions modulo sont parfois utilisées pour prendre en compte le caractère cyclique des capteurs pouvant être reliés au calculateur.
On peut utiliser comme formalisme de description fonctionnelle de l'application de TSS (traitement de signal systématique) un graphe de flot de données (Data Flow Graph) qui peut provenir de n'importe quel formalisme classique de description d'application du signal sous réserve qu'il contienne les informations précisées ci-dessus. En particulier, on peut décrire l'application à partir des langages suivants :
• Le langage « Array-OI » (exposé dans le susdit brevet français 2 732 787), • Le langage ALPHA,
• Un langage décrivant un ensemble de nids de boucles parfaitement imbriqués,
• Ou le formalisme de description de type MD/SDF.
Le placement consiste à distribuer automatiquement les opérations de traitement de signal à effectuer sur un flot de données, et ces données elles-mêmes, sur un calculateur à architecture multiprocesseurs parallèle en tenant compte des différentes contraintes de ressources matérielles ainsi que des performances imposées au calculateur.
L'architecture parallèle dont il est question ici est une architecture parallèle homogène, dans laquelle tous les processeurs sont identiques, de type SIMD/SPMD (« Single Instruction/Program Multiple Data »), c'est-à-dire dans laquelle tous les processeurs exécutent la même instruction ou la même séquence d'instructions (par exemple un programme) sur des données différentes. Le routage de l'information entre les différents processeurs est de type statique, c'est-à-dire que les chemins de données entre processeurs sont imposés avant l'initialisation de chaque mode (ils sont définis lors de la compilation de l'application). A un instant donné, les macro- instructions exécutées en parallèle sur chacun des processeurs sont identiques. Les données nécessaires au traitement de la macro-instruction doivent résider dans la mémoire locale du processeur qui l'exécute.
Pour les applications de traitement de signal, les « dimensions » de l'architecture du calculateur utilisé sont des contraintes impératives du placement. Cependant, ces contraintes ne sont pas prises en compte par les procédés classiques de placement automatique (tels que les procédés cités ci-dessus) et ne sont donc pas traitées à cet effet dans l'état de l'art. Les paramètres caractéristiques desdites dimensions sont :
- Le nombre de processeurs disponibles, qui sont tous de puissance égale.
- La puissance d'un processeur. Pour les applications de traitement de signal en temps réel, le temps de latence des calculs (temps au bout duquel les résultats de ces calculs sont disponibles) est très important. Ce temps peut être borné par une valeur maximale, et il dépend de la puissance du processeur qui réalise le calcul. Cette puissance est exprimée en nombre de cycles de calcul par seconde.
- La mémoire disponible. Elle est répartie uniformément sur l'ensemble des processeurs du calculateur.
- Les caractéristiques de communication entre processeurs. Elles sont définies en termes de bande passante, c'est-à-dire en nombre de cycles machine nécessaires à assurer la communication d'un paquet de données entre les processeurs d'une paire de processeurs. La durée des communications n'est alors pas fonction de la topologie du calculateur.
Le placement dont il est question ici comprend les quatre sous- fonctions de partitionnement d'alignement, de distribution et de séquencement. Jusqu'à présent, ces quatre sous-fonctions étaient traitées chacune séparément. Par contre, la présente invention prévoit de traiter simultanément ces sous-fonctions et de façon concurrente. Ce placement permet de trouver l'adéquation entre un programme (dont le parallélisme est spécifié ou non) et un calculateur à architecture parallèle homogène telle que spécifiée ci-dessus. Il consiste à distribuer les traitements et les données sur les différents processeurs du calculateur et à établir leur séquencement, en optimisant le parallélisme de l'application.
Ce placement comprend la détermination des diverses contraintes liées à l'application. Ces contraintes sont, d'une part, des contraintes « applicatives » (liées à la taille des tâches élémentaires spécifiques du traitement de signal systématique), d'autre part des contraintes liées à l'architecture du calculateur (nombre de processeurs, capacité mémoire, topologie du réseau de processeurs et débit de données, et enfin des contraintes liées à l'exécution (ordonnancement affine, recouvrement entre les communications de données et les calculs effectués).
La modélisation par contraintes consiste essentiellement à établir, pour chaque contrainte, une relation entre au moins deux variables ou une relation entre une variable et une valeur donnée (généralement un seuil). Cette relation est une relation linéaire (généralement un polynôme du 1er degré).
Le procédé de l'invention, partant de cette modélisation, effectue la résolution concurrente (non séquentielle) de tous les modèles, pour en déduire une ou plusieurs solutions satisfaisant toutes les contraintes. Dans le cas de plusieurs solutions satisfaisantes, on peut choisir celle satisfaisant de la meilleure façon un ou plusieurs critères (dont des exemples sont cités ci- dessous), et on peut avantageusement procéder de façon heuristique.
Les langages de spécifications d'applications de signal, les polynômes en nombres entiers et les applications affines permettent de modeliser précisément les fonctionnalités du placement. L'algèbre linéaire permet de construire les différents modèles au niveau de granularite requis par la complexité du problème général. Ces modèles sont issus de l'état de l'art du placement automatique [J. Li & M. Chen, « The data alignment phase in compiling programs for distributed memory machines », Journal of Parallel and Distributed Computing, p. 213-221 , Vol. 13, 1991 ; P. Feautrier, « Toward Automatic Distribution », Parallel Processing Letters, p. 233-244, Vol. 4, n° 3, 1994 ; M. Dion, « Alignement et distribution en parallélisation automatique », Thèse Informatique, ENS. LYON, 1996] et ont fait l'objet d'une adaptation au contexte applicatif du signal. Ils sont exprimés à l'aide de contraintes linéaires et non linéaires intégrables au procédé de l'invention. Ce procédé s'impose alors d'une part par sa capacité à traiter l'algèbre propre aux différents modèles et d'autre part par sa dimension de langage qui facilite l'expression et la composition d'heuristiques et de contraintes spécifiques à un domaine, et/ou de stratégies complexes permettant le contrôle des étapes de résolution. Les données manipulées par le système de placement sont donc des éléments de tableaux, des macro-instructions, dont il faut nécessairement modeliser le comportement selon les fonctions à résoudre. L'ensemble des modèles décrits ci-dessous sont entièrement formalisés à partir de l'algèbre linéaire, permettant le contrôle de la granularite pour chaque modèle. Chaque modèle définit une composante de la compilation d'une application de traitement du signal sur machine parallèle.
• La distribution des calculs et des données sur les processeurs, est en fait un problème de ressources disjonctives (exclusives les unes des autres).
• L'ordonnancement des traitements en tenant compte des ressources mémoire et communications, représentées par des contraintes capacitives.
Le but est d'optimiser différents critères comme la latence de l'application ou le coût (financier) de l'architecture cible. De plus, de nombreux modèles spécifiques au problème de placement ont été développés et viennent compléter la description du problème, comme par exemple les communications ou le temps physique. Compte tenu du nombre de tâches et du nombre de données à considérer lors du placement, chaque modèle est défini en intention plutôt qu'en extension. La possibilité de travailler à plusieurs niveaux de granularite s'avère fondamentale pour le problème de placement, et l'on utilise pour cela une formulation algébrique du partitionnement. Celui-ci fixe la granularite des autres modèles, il entretient donc de nombreuses relations au sein même du modèle conceptuel. De plus, les contraintes de dépendances relient à de nombreuses reprises plusieurs modèles, ce sont donc des contraintes globales et la clef de voûte du problème à résoudre. Enfin, on dispose d'heuristiques locales à un ou plusieurs modèles. Cependant, on ne connaît pas d'heuristique globale. Le cœur de la présente invention utilise l'approche multi-modèles par contraintes concurrentes [J. Jourdan, F. Fages, D. Rozzonelli & A. Demeure, « Data Alignment and Task Scheduling On Parallel Machines Using Concurrent Model-based Programming », Proc. ILPS 94, 1994], ce qui permet d'appréhender le problème du placement automatique de manière globale. Selon le procédé de l'invention, les modèles sont établis à raison d'un modèle par constituant, qu'il soit fonctionnel ou physique. Par définition, un modèle doit être vu comme l'ensemble des spécifications du comportement du constituant qu'il modélise.
On a représenté sur le schéma fonctionnel de la figure unique du dessin les différents modèles mis en œuvre pour la fonction « placement » référencée 1 dans son ensemble. Ces modèles sont : l'architecture des processeurs cibles (2), la capacité de la mémoire (3), le partitionnement des flots de données (4), les communications inter-processeurs (5), l'ordonnancement événementiel ou séquencement des calculs (6), le temps physique ou temps de calcul (7) et les entrées-sorties de signaux (8).
Les différents liens établis entre ces modèles sont de deux sortes : les « hyperliens » représentés par des flèches complexes (9, 10) en forme de polygones irréguliers , qui relient chacune plusieurs modèles ensemble, et des liens simples, représentés par des traits fléchés chacun à leurs extrémités et reliant chacun deux modèles.
La flèche complexe 9, qui correspond au critère « nombre de processeurs », relie les modèles 2, 3, 4 et 5. La flèche complexe 10, qui correspond au critère « dépendances », relie les modèles 3, 4, 5 et 6. Le modèle 2 est relié par des liens simples aux modèles (3) (critère « taille mémoire »), 5 (critère « bande passante ») et 6 (critère « mode de programmation »).
Le modèle 3 et relié par des liens simples aux modèles 4 (critère « volume de données ») et 6 (critère « distance et cardinalité).
Le modèle 4 est relié par un lien simple au modèle 7 (critère « volume de calcul »).
Le modèle 5 est relié par des liens simples aux modèles 6 (critère « événements de communication ») et 7 (critère « durée de communication »).
Le modèle 6 est relié par un lien simple au modèle 7 (critère « distance et cardinalité »).
Enfin, le modèle 7 et relié par un lien simple au modèle 8 (critère « latence et récurrence »). Dans les modèles décrits ci-dessus, les spécifications du comportement des différents constituants de ces modèles, sont exprimés à partir de relations mathématiques. On peut donc en déduire que les modèles sont identifiés à l'ensemble des relations définies sur leurs variables. Ces relations sont soit des primitives du langage utilisé (primitives faisant partie d'une bibliothèque de relations), soit des relations définies par l'utilisateur.
Du fait que les modèles constituent eux-mêmes l'essentiel du procédé, les propriétés du paradigme relationnel (ensemble des règles régissant les relations pouvant être établies entre les modèles) ont des conséquences immédiates sur les propriétés des composantes fonctionnelles du procédé. Les propriétés du paradigme relationnel sont les suivantes :
• Description formelle : Les relations représentent une description formelle du comportement du constituant. En effet, pour chacune des sous-fonctions du placement, une modélisation mathématique a été spécifiée formellement. Dans la plupart des cas, elle est issue des travaux des spécialistes des parallélisations, et elle a été adaptée non seulement au cadre applicatif qu'est le traitement du signal mais étendue au contexte de la modélisation concurrente. • « Adirectionalité » : Le concept de relation permet d'abandonner le paradigme fonctionnel basé sur la distinction des entrées/sorties. Une relation assure une réversibilité totale des arguments. Ceci permet de ne faire la distinction qu'à l'exécution, en fonction de la nature des arguments (connus et inconnus).
• « Compositionalité » : La composition des modèles relationnels est tout simplement la conjonction logique des relations qui constituent le modèle. Ceci implique une sémantique simple de la compositionalité. L'ensemble des solutions d'un modèle composite est tout simplement l'intersection des solutions des modèles. Elles contribuent à l'universalité du programme. Les propriétés du procédé induites sont alors : • Un domaine d'utilisation élargi : Un modèle peut être utilisé dans plusieurs contextes en fonction du but à réaliser.
• Une interchangeabilité accrue : Un modèle peut être modifié ou complètement redéfini par la donnée d'une nouvelle spécification sans avoir à intervenir sur les autres modèles. • Une compositionalité intrinsèque : Le modèle d'un système est construit à partir du modèle de ses composants.
• Une maintenabilité simple : La maintenabilité reste locale à chaque modèle.
• Une extensibilité aisée : Etendre un système revient à le composer avec le système existant.
Dans toutes les solutions logicielles connues de parallélisation, l'état d'un système est caractérisé par le contenu de la mémoire à un instant donné. Les opérations élémentaires sont la lecture et l'écriture sur, ou à partir de la mémoire. L'état d'un système n'est alors caractérisé que par l'ensemble des valeurs des cases mémoires associées aux variables qui le composent. La différence fondamentale entre le procédé de l'invention et les autres solutions logicielles est la représentation de cette mémoire. Dans le cas de l'invention, la mémoire n'est pas réduite à un ensemble de cases mémoire mais constitue en elle-même une contrainte. Cette dernière est capable de fournir de l'information partielle sur l'ensemble des variables qui composent le système. Il est intéressant de noter que tout le raisonnement mis en œuvre par les contraintes est basé sur ce paradigme de manipulation d'informations partielles. L'avantage des contraintes est tout simplement dû au fait que le système en cours d'élaboration peut prendre des décisions sans avoir à attendre qu'il soit entièrement déterminé.
La résolution d'applications industrielles ne se cantonne pas à une problématique bien définie, mais intègre la combinaison de plusieurs sous- problèmes. Il faut résoudre des problèmes d'optimisation combinatoire sur des problèmes multi-composants, multifonctions dans lesquels les contraintes sont très hétérogènes et où il faut considérer les différents éléments à différents niveaux de granularite. L'invention offre des solutions permettant la coexistence de modèles se recouvrant partiellement, se coordonnant et se décomposant.
Une alternative pour les problèmes multi-composants, multifonctions : la spécification de modèles pour chaque composant et pour chaque fonction qui se combinent ensuite lors de la résolution d'un but, permet d'apporter une alternative à la résolution de problèmes de systèmes. De plus, souvent les modèles sont très hétérogènes. Certains peuvent s'exprimer exclusivement à l'aide de contraintes linéaires, d'autres peuvent nécessiter des contraintes symboliques ou booléennes.
L'invention permet indépendamment de l'hétérogénéité des contraintes, par de simples interactions locales, de garantir une coordination globale du système.
Dans le cas des problèmes d'optimisation combinatoire, le procédé de l'invention offre une bonne solution technologique, car elle permet, lors de la résolution, l'utilisation concurrente de tous les modèles redondants.
En effet :
• La résolution de problèmes hautement combinatoires se résume rarement à une seule formalisation mathématique.
Souvent, pour ne pas dire toujours, des formalisations complémentaires sont nécessaires. Un exemple pourrait être les formalisations redondantes qui tirent avantage des propriétés des solutions partielles, un autre exemple serait la prise en compte des symétries du problèmes, etc. • Le problème qui se pose alors est d'utiliser en même temps toutes ces informations. Dans le contexte d'approches plus classiques, comme la recherche opérationnelle ou la programmation en nombres entiers, cette étape s'avère toujours très délicate. En effet, les programmes écrits dans un langage impératif nécessitent un temps de développement non négligeable et sont souvent difficiles à étendre et à modifier. L'invention permet également de résoudre les problèmes relationnels des modèles à plusieurs niveaux de granularite. L'efficacité de la réalisation finale dépend de trois paramètres.
Tout d'abord, elle dépend crucialement de l'efficacité du système de contraintes utilisé, du contrôle que l'on a sur la recherche d'une solution (voir ci-dessous), mais aussi, considérablement, de la granularite considérée dans la modélisation. L'expérience montre qu'il est indispensable de considérer différents niveaux de granularite et de pouvoir raisonner sur les différents niveaux. Ici encore, l'invention offre une solution en permettant la description, la coexistence et la coordination de modèles à différents niveaux de granularite. Ce dernier point n'a pas encore été vraiment exploité dans des applications. La fonction « placement » est alors modélisée au travers de différents modèles issus des travaux des spécialistes de la « parallélisation automatique » comme :
• Le partitionnement qui exprime la distribution des calculs et des données sur les processeurs. • Les dépendances qui caractérisent les itérations accédant aux mêmes données.
• L'ordonnancement qui consiste à organiser l'exécution des traitements parallèles dans le temps.
• L'interphase qui donne les communications entre deux phases de calcul partitionnées.
• L'architecture qui est en fait un ensemble de paramètres comme le nombre de processeurs, la bande passante, ...
• Les communications.
• La mémoire qui définit au travers d'une contrainte de capacité pour laquelle on est sûr de pouvoir calculer une allocation. • Le signal temps réel qui est constitué de la latence et des contraintes d'entrées/sorties (périodes, ...). De manière générique, un modèle se compose de définitions de variables sur lesquelles reposent les contraintes propres aux modèles. Le procédé de l'invention permet à la fois de résoudre le problème du placement automatique d'applications traitement de signal sur machines parallèles et permet à l'utilisateur de manipuler une solution fournie sans violation des contraintes posées par le système global. Cette approche s'inscrit dans un contexte de codesign et de prototypage virtuel. A partir d'une description formelle de l'application (comme par exemple un langage de type MD/SDF développé à Berkeley, une description fonctionnelle en ARRAY-OL ou une spécification à l'aide de nids de boucles) l'outil produira un pseudo-code générique de placement pour des machines cibles homogènes considérées. Ce pseudo-code sera ensuite directement interfaçable avec les différents compilateurs des architectures cibles. Ce procédé peut donc permettre à l'utilisateur :
- de saisir une solution partielle : l'utilisateur saisit une solution partielle de placement et l'outil poursuit sa recherche en complétant la solution de placement qui sera validée par conception. Par exemple :
> L'utilisateur a configuré sa machine avec un nombre insuffisant de processeurs pour le type de placement qu'il désire. Le procédé va permettre de trouver le nombre minimal de processeurs nécessaires au placement imposé dans l'ensemble des processeurs disponibles.
> L'utilisateur peut imposer un séquencement des calculs. Le système va alors trouver les partitionnements, c'est-à- dire les distributions des données et des calculs en mémoire et sur les processeurs adéquats. > De même, l'utilisateur peut imposer un partitionnement initial, le système va trouver les ordonnancements compatibles.
- de jouer sur les compromis (« trade-off ») usuels : le procédé permet à l'utilisateur de valider les compromis entre les paramètres sensibles du placement en phase de conception de l'application, compromis entre :
> Nombre de processeurs/Bande passante,
> Mémoire/temps réel, > Nombre de processeurs/temps réel,
> Bande passante/temps réel,
> Mémoire/Bande passante.
- de visualiser des solutions complexes comme par exemple l'ordonnancement, le découpage des données, l'affectation etc..
- de dimensionner la machine : le procédé permet de spécifier les ressources nécessaires pour placer une application particulière sur un type de machine donnée sans violer les contraintes applicatives. Cela consiste à prendre en compte les dimensions et le nombre de chaque composant matériel
(Hardware).
> Nombre et puissance des processeurs,
> Performance du réseau d'interconnexions,
> Taille et type de mémoire (mémoire vive et mémoire cache synchrone/asynchrone, disque dur),
> Dimension des différentes interfaces systèmes.
- de choisir le critère d'optimisation du placement :
> Dimension machine : le procédé permet de configurer une machine minimale pour une application donnée. L'utilisateur peut, par exemple, choisir de configurer une machine avec un nombre minimal de processeurs.
> Latence : le procédé permet de trouver le (ou les) placement(s) qui minimise(nt) le temps d'exécution de l'application sur une machine cible prédéfinie par l'utilisateur.
> Efficacité : le procédé permet de maximiser le parallélisme du (ou des) placement(s) de l'application sur une machine cible prédéfinie par l'utilisateur.
> Coût : en intégrant un coût (financier par exemple) sur chacun des composants matériels, le procédé permet de trouver le (ou les) placement(s) de l'application qui minimise(nt) ce coût.
> Temps d'occupation de la machine : le procédé permet de trouver le (ou les) placement(s) qui minimise(nt) le temps d'occupation de la machine cible prédéfinie par l'utilisateur afin de pouvoir éventuellement placer une seconde application.
> Récurrence d'entrée ou de sortie : le procédé permet de trouver le (ou les) placement(s) qui minimise(nt) la cadence d'entrée et/ou de sortie des résultats produits par un ensemble de traitements. Ces contraintes sont souvent imposées dans le cadre des signaux vidéo, acoustiques et/ou hyperfréquences.
- de déterminer les paramètres du signal comme le modes des entrées/sorties, la latence, la récurrence (d'entrée et/ou de sortie) pour une machine et une application données. De plus, la présence d'un ensemble d'heuristiques permet à l'utilisateur de soulager la recherche d'une solution, en l'orientant. L'ingénieur peut en effet ; - choisir une ou plusieurs heuristiques dans un ensemble prédéfini, c'est-à-dire avoir le choix de différentes solutions canoniques de placement. Par exemple :
> Ordonnancement des calculs au plus tôt, ou au plus tard.
- Maximiser le parallélisme, - Minimiser les communications,
- Recouvrir les communications par les calculs,
- Maximiser la localité des données dans les différents processeurs.

Claims

REVENDICATIONS
1. Procédé générique d'aide au placement d'une application de traitement de signal sur un calculateur à architecture parallèle homogène, caractérisé par le fait qu'il consiste, pour chaque constituant fonctionnel et physique de l'application, à établir un modèle défini par un ensemble de relations sur les différentes variables relatives à ce constituant, afin de modeliser les contraintes, à résoudre de façon concurrente les relations ainsi établies, et à en déduire au moins une solution, et à effectuer le placement de l'application.
2. Procédé selon la revendication 1 , caractérisé par le fait que les différents modèles mis en œuvre sont : l'architecture des processeurs cibles
(2), la capacité de la mémoire (3), le partitionnement des flots de données (4), les communications inter-processeurs (5), le séquencement des calculs (6), le temps de calcul (7) et les entrées-sorties de signaux (8).
3. Procédé selon la revendication 1 ou 2, caractérisé par le fait qu'en cas d'obtention de plusieurs solutions, on choisit celle optimisant au moins un critère, le choix étant fait de façon heuristique.
4. Procédé selon l'une des revendications précédentes, caractérisé par le fait que l'application est décrite fonctionnellement par un graphe de flot de données multidimensionnelles.
5. Procédé selon la revendication 4, caractérisé par le fait que l'application est décrite à partir de l'un des langages suivants : le langage « ARRAY-OL », le langage ALPHA, un langage décrivant un ensemble de nids de boucles parfaitement imbriqués, le formalisme de description de type MD/SDF.
EP00915272A 1999-04-02 2000-03-31 Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles Withdrawn EP1082656A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9904182A FR2791789B1 (fr) 1999-04-02 1999-04-02 Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles
FR9904182 1999-04-02
PCT/FR2000/000824 WO2000060460A1 (fr) 1999-04-02 2000-03-31 Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles

Publications (1)

Publication Number Publication Date
EP1082656A1 true EP1082656A1 (fr) 2001-03-14

Family

ID=9543985

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00915272A Withdrawn EP1082656A1 (fr) 1999-04-02 2000-03-31 Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles

Country Status (4)

Country Link
EP (1) EP1082656A1 (fr)
AU (1) AU3664400A (fr)
FR (1) FR2791789B1 (fr)
WO (1) WO2000060460A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2818406B1 (fr) * 2000-12-19 2003-03-07 Thomson Csf Procede de placement d'applications multiprocesseurs
FR2819601B1 (fr) * 2001-01-16 2003-07-18 Canon Kk Procede et dispositif de partition de programme informatique
WO2002059743A2 (fr) * 2001-01-25 2002-08-01 Improv Systems, Inc. Compilateur destine a des architectures a processeurs multiples et a memoire repartie
FR2820526B1 (fr) 2001-02-05 2003-06-13 Thomson Csf Procede de simulation de performances, et procede de realisation d'applications multiprocesseurs, et dispositifs permettant de mettre en oeuvre lesdits procedes
DE102010028896A1 (de) * 2010-05-11 2011-11-17 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Verfahren und Vorrichtung zum Zuweisen einer Mehrzahl von Teilaufgaben einer Aufgabe zu einer Mehrzahl von Recheneinheiten einer vorgegebenen Prozessorarchitektur

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5418953A (en) * 1993-04-12 1995-05-23 Loral/Rohm Mil-Spec Corp. Method for automated deployment of a software program onto a multi-processor architecture
FR2732787B1 (fr) * 1995-04-07 1997-05-16 Thomson Csf Procede de saisie graphique d'application de traitement de signal

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0060460A1 *

Also Published As

Publication number Publication date
AU3664400A (en) 2000-10-23
FR2791789A1 (fr) 2000-10-06
WO2000060460A1 (fr) 2000-10-12
FR2791789B1 (fr) 2001-08-10

Similar Documents

Publication Publication Date Title
Cummins et al. Compilergym: Robust, performant compiler optimization environments for ai research
Yu et al. Dynamic control flow in large-scale machine learning
Rocklin Dask: Parallel computation with blocked algorithms and task scheduling.
Bergstra et al. Machine learning for predictive auto-tuning with boosted regression trees
US9081928B2 (en) Embedded system development
Boutellier et al. Actor merging for dataflow process networks
Huang et al. Alcop: Automatic load-compute pipelining in deep learning compiler for ai-gpus
Bonfietti et al. Throughput constraint for synchronous data flow graphs
Danelutto et al. Algorithmic skeletons meeting grids
EP1082656A1 (fr) Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles
Mandel et al. ReactiveML, ten years later
de Oliveira Dantas et al. A component-based framework for certification of components in a cloud of HPC services
Madsen et al. Modeling and analysis framework for embedded systems
Agullo et al. Exploiting a parametrized task graph model for the parallelization of a sparse direct multifrontal solver
Goli Visioncpp: A sycl-based computer vision framework
Jeanmougin et al. Warp-level CFG construction for GPU kernel WCET analysis
Singhal et al. A Vision on Accelerating Enterprise IT System 2.0
Almqvist Integrating SkePU's algorithmic skeletons with GPI on a cluster
Browne et al. Visual programming and parallel computing
Potop-Butucaru et al. Integrated worst-case response time evaluation of multicore non-preemptive applications
Honorat Modeling, Scheduling, Pipelining and Configuration of Synchronous Dataflow Graphs with Throughput Constraints
Feldman Software-Defined Hardware Without Sacrificing Performance
Fox et al. Algebraic models of correctness for abstract pipelines
Kotak Efficient Execution of DG-FEM workloads on GPUs via CUDA graphs
Kofman Low power application architecture adaptation using SMT solvers

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20001208

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: THALES

RBV Designated contracting states (corrected)

Designated state(s): DE GB IE

17Q First examination report despatched

Effective date: 20070828

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080308