Caractérisation d’architectures de calcul

Comme discuté dans le chapitre précédent, notre méthodologie d’analyse de l’em- barquabilité nécessite un modèle d’architecture. Ce modèle doit être générique et réutili- sable, c’est-à-dire qu’une fois construit, il doit pouvoir être réutilisé pour tester l’embar- quabilité de n’importe quel algorithme. Les données issues de cette étape de caractéri- sation d’architectures sont ensuite utilisées dans notre méthode de prédiction de perfor- mance.Lors d’une première approche, nous souhaitions construire ce modèle uniquementà partir d’informations disponibles dans les documentations et datasheets des fondeurs. Ainsi, une analyse de l’embarquabilité basée uniquement sur ces informations permet- trait de prédire le respect des contraintes temps-réels uniquement à partir de la datasheet d’un SoC, sans aucune implémentation ni mesure. Nos premières contributions [SAUS-(c’est-à-dire lorsque les performances sont limitées par la capacité de calcul) et elle ne permet pas de prendre en compte des informations non communiquées par le fondeur, comme le comportement d’exécutions concurrentes, les effets du compilateur, etc.(c’est-à-dire lorsque les performances sont limitées par les capacités de la mémoire) uniquement en utilisant la bande passante théorique de la mémoire et la taille du cache. En effet, le délai d’accès à des données est très variable en fonction de la localisation de ces données, suivant qu’elles se trouvent dans le cache L1, L2 ou dans la mémoire centrale. Dans notre raisonnement nous sommes arrivés à la conclusion qu’il est indispensable de passer par une étape de caractérisation d’architecture en exécutant un programme spécifique permettant d’extraire des caractéristiques non présentes dans la datasheet mais indispensables pour une prédiction précise.

De plus, dans un contexte industriel, il est tout à fait envisageable de demander à un fournisseur de SoC d’exécuter un programme spécifique permettant la caractérisation de ses architectures. Cependant, cela implique que ce programme spécifique soit le plus générique possible de manière à pouvoir être exécuté sur un très grand nombre d’architectures différentes. Finalement, notre approche de prédiction de performance se place sur deux niveaux de précision, comme illustré sur la figure 4.1. Dans le premier cas seulement les informa- tions issues des fondeurs (datasheet ou autres documents) sont utilisées pour construire le modèle de l’architecture. Cette approche a pour avantage de pouvoir fonctionner sans la nécessité d’avoir le SoC à modéliser sous la main. Cependant, elle ne permet pas de prendre en compte les informations non communiquées par le fondeur du type effet de cache, latence mémoire, comportement des accès mémoire concurrents ou même les ef- fets de compilation.Dans un premier temps, nous proposons une discussion autour des méthodologies existantes à propos de la caractérisation d’architectures. Lorsque l’on cherche à compa- rer deux performances il est primordial de définir les critères et les métriques à utiliser pour déterminer la meilleure des deux. Ainsi, dans le milieu du sport l’épreuve du 100 mètres définit le test suivant : l’athlète qui parcours 100 mètres en moins de temps que ses concurrents est le meilleur, on cherche donc ici à qualifier la vitesse de sprint de chaque athlète. Or un champion de 100 mètres ne sera probablement pas aussi performant sur une autre épreuve tel que le marathon ou le saut à la perche. Il est donc très complexe de déterminer quel est meilleur sportif sur tous les plans. Le même raisonnement peut s’appliquer à la comparaison des puissances de calcul entre deux architectures.

Lorsque l’on parle de puissance de calcul d’un système, on retrouve très souvent les mêmes métriques. Ainsi, le classement des 500 ordinateurs les plus puissants [MEUER et collab., 2016] est donné en FLoating point Operations Per Second (FLOPS), ou opéra- tions en virgule flottante par seconde. À l’heure actuelle le calculateur le plus puissant, utilisé au National Supercomputing Center in Wuxi (Chine), a une performance mesurée autour de 90 peta FLOPS. Concernant les calculateurs embarqués, la DrivePX de Nvidia fournit une puissance de calcul théorique d’environ 1 tera FLOPS. Or cette métrique ne prend pas du tout en compte les performances sur les nombres entiers. D’ailleurs elle est souvent mise en avant par Nvidia pour démontrer la performance de ses GPU, comme illustré en figure 4.2. En effet, ceux-ci sont plus performants sur des opérations en virgule flottante qu’avec des opérations sur des entiers, contrairement au processeur classique du type CPU Intel ou ARM. De plus, il n’est jamais précisé le type d’opérations qui est uti- lisé, à savoir addition, multiplication, division, etc. Si dire qu’une unité de calcul en virgule flottante est aussi performante sur des additions et des multiplications paraît logique et cohérent, cela paraît toutefois moins convaincant de dire qu’il faut autant de cycles pour effectuer une addition qu’une division. Il suffit d’ailleurs de regarder n’importe quelle da- tasheet pour se rendre compte qu’une division prend beaucoup plus de cycles qu’une addition ou une multiplication.