Ce n’est un secret pour personne, les processeurs deviennent de plus en plus complexes au fil du temps. Depuis les premiers pentium où la fréquence faisait tout et où une mine de crayon suffisait à surcadencer, beaucoup de chemin a été parcouru, et il faut désormais tenir compte des caches, ports d’exécution, prefetchers et autres pipelines qui, s’ils accélèrent en général les temps d’exécutions, complexifient d’autant plus sa prédiction. Si ces rouages vous intéressent, nous vous avions compilé un petit récapitulatif il y a deux ans déjà.

 

Or, dans le cycle de développement d’un programme, il se peut (bon, pas pour tous, nous sommes d’accord...) qu’une phase d’optimisation ait lieu. Dans ce cas l’idée est de passer d’un débugging fonctionnel (« pourquoi mon programme ne donne pas les réponses attendues ? ») à un débugging de performance (« pourquoi mon programme est-il lent ? »). Vous vous en doutez, plus le CPU est complexe, plus cette réponse est longue et fastidieuse à trouver. Généralement, une bonne partie des optimisations sont effectuée par le compilateur (dans le cas des langages passant par cette étape), ou l’interpréteur (dans les autres cas, justement).

 

C'est pas facile tout ça ! [cliquer pour agrandir]

«Un CPU, c’est que c’est pas simple du tout » —Captain Obvious

 

Pourtant, dès que le code devient non-trivial, les compilateurs rament et ont du mal à trouver la meilleure solution, qui se base de toute manière sur un modèle de coût des instructions pas forcément toujours aussi proche de la réalité qu’espéré. C’est ce problème-là qu’a voulu attaquer une équipe de chercheurs du MIT, en passant par une approche bien en vogue en 2019 2020 : le machine learning.

 

Entraîné sur un ensemble de plus de 300 000 basic blocks — des morceaux élémentaires de programme constitués d’instructions ne contenant ni sauts ni de points d'arrivées de sauts, c'est-à-dire des blocs d'instructions exécutées pour sûr consécutivement par le CPU — issus de tous les horizons, un algorithme basé sur des méthodes statistiques a réussi à prédire les temps d’exécutions et la consommation énergétique de programmes de manière plus précise que les outils fournis par Intel (à savoir IACA, un projet maintenant déprécié).

 

L’inconvénient de cette approche réside cependant dans le côté « boite noire » que les méthodes statistiques offrent. En effet, sans représentation un minimum exploitable, difficile de renvoyer à l’utilisateur une information utile sur les démarches à suivre permettant l’optimisation. Si, en France, certaines équipes se penchent sur cette thématique, le MIT a décidé de repasser par une boite noire sauce machine learning toujours. Si cela fonctionne sur la plupart des exemples fournis dans le papier, notamment en matière de vectorisation de code, nous pouvons émettre quelques doutes quant à sa généralisation et son intégration dans des suites logicielles répandues dans les environnements de production tels LLVM ou GCC.... Ce qui est le souci de la plupart des papiers de recherche de manière générale ! (Source : MIT News)

 Utiliser des techniques d'IA sur du code, voilà une recherche très méta dans le domaine de l'informatique ! 

Sur le comptoir, au même sujet

 
 
 
 
 

afficher plus de prixAffichez donc moi tout, nom de nom

Plus d'infos avec le comptoir de l'info

Voir plus de news
Les 7 Ragots
   
Les ragots sont actuellement
ouverts à tous, c'est open bar !