« Fonctionnement d'un ordinateur/Les architectures dataflow » : différence entre les versions

Pour résoudre les défauts des architectures ''dataflow'' statiques, il faut faire sauter la règle du "un jeton par flèche", ce qui est fait sur les '''architectures ''dataflow'' dynamiques'''. L'idée de ces architectures est d'associer, pour chaque jeton, l'exemplaire d'une fonction ou d'une boucle ils sont destinés. Pour cela, on ajoute des informations à cotécôté de l'opérande, regroupées dans ce qu'on appelle le ''tag''. Dorénavant, une instruction s’exécute une fois que tous ses opérandes ayant le même tag sont disponibles.

Sur les architectures statiques, les jetons avaient un emplacement pré-reservéréservé dans les instructions mêmes. Mais sur les architectures dynamiques, on ne peut réserver de la place pour les opérandes à l'avance, vu qu'une instruction dans une boucle ou une fonction peut s’exécuter en un nombre indéterminé d'exemplaires. C'est maintenant aux jetons d'indiquer quelle est l'instruction qui doit les manipuler, en mémorisant son adresse. Les opérandes sont mémorisés à part des instructions, dans une mémoire séparée de la mémoire d'instructions (en clair, les architectures dynamiques sont de type Harvard). Les opérandes sont mis en attente dans une file d'attente. À chaque ajout d'un opérande dans la file d'attente, le processeur vérifie quels sont les opérandes de la file qui possèdent le même tag et la même adresse d'instruction.

Les '''architectures Explicit Token-Store''' utilisent une sorte de pile. L'opérande est remplacé par deux choses : un pointeur vers le cadre de pile qui contient la donnée et de quoi localiser l'opérande dans la pile. Elle représentent une amélioration assez conséquente des architectures précédentes. Sur ces machines, lorsqu’une fonction ou une boucle s’exécute, elle réserve un cadre de pile et y stocke ses opérandes et ses variables locales. A chaque appel d'une fonction ou à chaque itération d'une boucle, on crée un nouveau cadre pour les opérandes de la dite version. Ainsi, chaque fonction ou itération de boucle pourra avoir son propre jeu d'opérandes et de variables locales, permettant ainsi l'utilisation de fonctions réentrantesré-entrantes ou récursives et un déroulage matériel des boucles.

Premièrement, la gestion des jetons et des instructions est compliquée et utilise beaucoup de circuits. La détection de la disponibilité des opérandes d'une instruction est assez couteusecoûteuse et prend un certain temps, vu qu'elle est faite avec des mémoires associatives. Hors, les mémoires associatives sont redoutablement lentes, ce qui pose de gros problèmes de performances. Le temps d'accès à la mémoire est suffisant pour compenser tous les gains apportés par la parallélisation. Autre problème : la répartition des instructions prêtes sur les différentes unités de calcul prend un certain temps, difficile à amortir. Autre problème : les tags prennent de la mémoire, suffisamment pour devenir un problème. Ensuite, l'immutabilité des variables fait que la gestion des structures de données est laborieuse pour le compilateur et le programmeur, entraineentraîne beaucoup d'allocations mémoires et augmente fortement le nombre de lectures et écritures en mémoire, comparé à un programme impératif.

Et ensuite, le plus gros problème de tous : ces architectures sont limitée par la rapidité de la mémoire RAM principale. La même chose a lieu dans les programmes impératifs sur des architectures normale, à la différence que celles-ci ont des caches et une hiérarchie mémoire, afin d'amortir le coutcoût des accès mémoires. Mais ces techniques ne fonctionnent correctement que lorsque le code exécuté a une bonne localité temporelle et spatiale. Ce qui n'est franchement pas le cas des programmes conçus pour les architectures ''dataflow'' et des programmes fonctionnels en général (à cause de l'immutabilité de variables, d'allocations mémoires fréquentes, des structures de donnée utilisées, etc).

Les architectures '''''Explicit Data Graph Execution''''' se basent sur le fonctionnement des compilateurs modernes pour découper un programme procédural ou impératif en blocs de code. Généralement, ceux-ci vont découper un programme en petits morceaux de code qu'on appelle des blocs de base, qui sont souvent délimités par des branchements (ou des destinations de branchements). Ces sont ces blocs de base qui seront exécutés dans l'ordre des dépendances de données. Certaines architectures de ce type ont déjà été inventées, comme les processeurs ''WaveScalar'' et ''TRIPS''.

Quelques liens sur l'architecture ''wavescalar'' :