Autotuning assisté par apprentissage automatique de tâches OpenMP

Modern computer architectures are highly complex, requiring great programming effort to obtain all the performance the hardware is capable of delivering. Indeed, while developers know potential optimizations, the only feasible way to tell which of them is faster for some platform is to test it. Furthermore, the many differences between two computer platforms, in the number of cores, cache sizes, interconnect, processor and memory frequencies, etc, makes it very challenging to have the same code perform well over several systems. To extract the most performance, it is often necessary to fine-tune the code for each system. Consequently, developers adopt autotuning to achieve some degree of portable performance. This way, the potential optimizations can be specified once, and, after testing each possibility on a platform, obtain a high-performance version of the code for that particular platform. However, this technique requires tuning each application for each platform it targets. This is not only time consuming but the autotuning and the real execution of the application differ. Differences in the data may trigger different behaviour, or there may be different interactions between the threads in the autotuning and the actual execution. This can lead to suboptimal decisions if the autotuner chooses a version that is optimal for the training but not for the real execution of the application. We propose the use of autotuning for selecting versions of the code relevant for a range of platforms and, during the execution of the application, the runtime system identifies the best version to use using one of three policies we propose: Mean, Upper Confidence Bound, and Gradient Bandit. This way, training effort is decreased and it enables the use of the same set of versions with different platforms without sacrificing performance. We conclude that the proposed policies can identify the version to use without incurring substantial performance losses. Furthermore, when the user does not know enough details of the application to configure optimally the explore-then-commit policy usedy by other runtime systems, the more adaptable UCB policy can be used in its place.Les architectures informatiques modernes sont très complexes, nécessitant un grand effort de programmation pour obtenir toute la performance que le matériel est capable de fournir. En effet, alors que les développeurs connaissent les optimisations potentielles, la seule façon possible de dire laquelle est le plus rapide pour une plate-forme est de le tester. En outre, les nombreuses différences entre deux plates-formes informatiques, dans le nombre de cœurs, les tailles de cache, l'interconnexion, les fréquences de processeur et de mémoire, etc, rendent très difficile la bonne exécution du même code sur plusieurs systèmes. Pour extraire le plus de performances, il est souvent nécessaire d'affiner le code pour chaque système. Par conséquent, les développeurs adoptent l'autotuning pour atteindre un certain degré de performance portable. De cette façon, les optimisations potentielles peuvent être spécifiées une seule fois et, après avoir testé chaque possibilité sur une plate-forme, obtenir une version haute performance du code pour cette plate-forme particulière. Toutefois, cette technique nécessite de régler chaque application pour chaque plate-forme quelle cible. Non seulement cela prend du temps, mais l'autotuning et l'exécution réelle de l'application diffèrent. Des différences dans les données peuvent déclencher un comportement différent, ou il peut y avoir différentes interactions entre les fils dans l'autotuning et l'exécution réelle. Cela peut conduire à des décisions sous-optimales si l'autotuner choisit une version qui est optimale pour la formation, mais pas pour l'exécution réelle de l'application. Nous proposons l'utilisation d'autotuning pour sélectionner les versions du code pertinentes pour une gamme de plates-formes et, lors de l'exécution de l'application, le système de temps d'exécution identifie la meilleure version à utiliser à l'aide de l'une des trois politiques que nous proposons: Mean, Upper Confidence Bound et Gradient Bandit. De cette façon, l'effort de formation est diminué et il permet l'utilisation du même ensemble de versions avec différentes plates-formes sans sacrifier les performances. Nous concluons que les politiques proposées peuvent identifier la version à utiliser sans subir de pertes de performance substantielles. De plus, lorsque l'utilisateur ne connaît pas suffisamment de détails de l'application pour configurer de manière optimale la politique d'exploration puis de validation utilisée par d'autres systèmes de temps d'exécution, la politique UCB plus adaptable peut être utilisée à sa place