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

Contenu supprimé Contenu ajouté
Ligne 95 :
==Les architectures ''dataflow'' hybrides==
 
NosLes architectures dataflow sont certes très belles, élégantes, tout ce qu'on veut (et encore, ça se discute...)créatives, mais celles-ci ont, comme toute architecture, été créées pour répondre à un besoin : la performance ! C'est le seul critère sur lequel on peut juger une architecture : est-elle rapide ? Le bilan est sans appel : ces architectures souffrent de défauts qui empêchent de les utiliser de façon réellement efficace.
 
Premièrement, la gestion des jetons et des instructions est assez laborieusecompliquée et plutôtutilise beaucoup de lentecircuits. La détection de la disponibilité des opérandes d'une instruction est souvent assez couteuse, et prend un certain temps, àvu causequ'elle duest faitfaite que la gestion de ces Tags se base surtout suravec des mémoires associatives. Hors, les mémoires associatives sont redoutablement lentes, ce qui pose de gros problèmes de performances. : leLe temps mitd'accès pour attendre queà la mémoire réponde est suffisamment grandsuffisant pour foutre en l'aircompenser 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 prenaitprend un certain temps, difficile à amortir. Gérer les différents cas, en testant la disponibilités des processeurs ou unités de calcul, trouver quelles instructions exécuter en priorité, etc ; est tout sauf gratuit. Autre problème : les Tagstags prennent de la mémoire. La consommation de mémoire peut devenir rapidement importante, en tout cas suffisamment pour devenir un problème. Ensuite, lel'immutabilité faitdes que ces architectures empêchent de modifier les donnéesvariables fait que la gestion des structures de données est laborieuse àpour lente.le L'immutabilitécompilateur deset variablesle peut certes être compensée par les I-structures (quand elles sont disponibles)programmeur, mais cela n’empêche pas de faireentraine 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 ontsont unelimitée faiblepar localitéla spatiale,rapidité couplée à une localité temporelle franchement pas meilleure. Ces architectures se comportent très mal lorsquede la mémoire à laquelle elle accède estRAM lenteprincipale. La même chose a lieu dans les programmes impératifs sur des architectures normale, à la différence que celles-ci ont apportées des solutions : celles-ci possèdent des caches, et divers niveaux deune hiérarchie mémoire, afin d'amortir le cout des accès mémoires. Seul problème, ces caches etMais 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 lesdes programmes fonctionnels en général (à cause de l'immutabilité de variables, d'allocations mémoires fréquentes, des structures de donnée très peu localesutilisées, etc).
 
On peut toujours amortircompenser ces différents coutsdéfauts en exécutant beaucoup d'instructions en parallèle, mais cela ne suffit pas forcément. Il faut dire que rares sont les programmes aveccapables peu de dépendances et pour lesquels on peut trouverd’exécuter un grand nombre d'instructions à exécuter en parallèle. En tout cas, pas forcément suffisamment pour compenser les couts de recherche des opérandes et les autres couts annexes. Il faut dire que beaucoup d'instructions possèdent desles dépendances dansde undonnées programmesont (même programmé avec des langages fonctionnels),légion et qu'il n'y a pas de miracles. : onOn ne peut pas toujours trouver suffisamment d'instructions à paralléliser, sauf dans certains programmes, qui résolvent des problèmes particuliers. En conséquence, les ''architectures dataflow'' ont étés abandonnées, après pas mal de recherches, en raison de leurs faibles performances. Mais certains chercheurs ont quand même décidés de donner une dernière chance au paradigme ''dataflow'', en le modifiant de façon à le rendre un peu plus impératif.
 
===Les architectures ''Threaded Dataflow''===
 
Ainsi sont nées les '''architectures ''Threaded Dataflow''''' ! Sur ces architectures, un programme est découpé en plusieurs blocs d'instructions. À l'intérieur de ces blocs, les instructions s’exécutent les unes à la suite des autres. Par contre, les blocs eux-mêmes seront exécutés dans l'ordre des dépendances de données : un bloc commence son exécution quand tous les opérandes nécessaires à son exécution sont disponibles.
 
===Les architecture ''Explicit Data Graph Execution''===