Pourquoi Alan Perlis et pas Hopper ? Parce que c'est lui qui a fourni un premier compilateur fonctionnel (qui prend un programme de « haut niveau » — si j'ai bien compris, il s'agissait de formules mathématiques — en entrée et génère du code machine en sortie).
Grace Hopper a proposé le premier langage (et le compilateur associé) « pour humains » je dirais, et que je qualifierais de « généraliste » (même si je pense que le langage créé par Perlis était aussi Turing-complet). C'est l'une des premières personnes à insister sur la notion de lisibilité des programmes (au sens d'avoir un programme écrit « en anglais », ou quelque chose d'approché), et très clairement la première à avoir mené à bien ce projet.
Par contre, il existe un prix Hopper (et à ma connaissance pas de Prix Perlis), qui récompense une contribution unique et majeure accomplie avant 35 ans. Bon, il a été créé après la mort de Grace Hopper, et ça fait un peu guise de mea culpa de la part de l'ACM, mais peu de personnes peuvent se targuer d'avoir un prix à leur nom (même de façon posthume). Il y a aussi un Prix Hopper décerné « en interne » par la marine US pour les femmes qui ont des contributions majeures dans le numérique/l'informatique.
Concernant le côté tardif des remises de prix, honnêtement ça dépend aussi parfois de l'ère du temps. L'un des deux co-récipiendaires en 2025, Charles Sutton, récompensé pour ses travaux sur l'apprentissage renforcé (sur lequel il publie depuis les années 70, et qui a de vraies applications depuis longtemps), est bien plus vieux que Yann Le Cun (2015), récompensé pour son travail sur l'apprentissage profond de réseaux de neurones artificiels (et de mémoire, il a commencé à publier dessus vers 1989).
Enfin, concernant les progrès en compilation, il y a beaucoup de choses en ce qui concerne les compilateurs optimisants. La parallélisation automatique « générale » ne fonctionne pas (ou pas bien), ou bien est limitée au cas « triviaux » (sur des programmes qui respectent des propriétés facilement déterminées à la compilation). Je vais BEAUCOUP simplfier dans ce qui suit.
Modèle polyédrique
Par contre, il y a eu beaucoup de travaux sur l'optimisation et la parallélisation automatique de certains types de programmes, en particulier l'optimisation sur des nids de boucles imparfaits. Il s'agit d'optimisations reposant sur le modèle polyédrique. L'idée est que si des boucles imbriquées dans un programme respectent certaines propriétés bien spécifiques (notamment qu'on peut garantir le « sens » dans lequel les tableaux utilisés dans ces nids de boucles est « monotone », c'est-à-dire que l'accès est toujours croissant ou décroissant), alors il est possible de créer une représentation de l'espace d'itération de ces boucles sous forme de polyèdre, et les points qui le composent sont les points de l'espace d'itération. On peut ensuite « tordre » ce polyèdre pour changer l'ordre des boucles, dérouler certaines boucles, fusionner certaines instructions, etc., en fonction des contraintes d'optimisation voulues (taille du code, rapidité du programme, etc.).
Le modèle (et les premières implémentations semi-automatisées) a été proposé par Paul Fautrier dans les années 80. Il a co-écrit un article dans « Encyclopedia of Computer Science » qui résume l'approche. On peut trouver une version complète sur ResearchGate.
Il y a eu beaucoup de recherche en France, mais tout était très théorique, et quand c'était vraiment implémenté, c'était surtout des implémentations faites à la main pour montrer que les algos marchaient. Courant des années 2000, certaines implémentations dans des compilateurs (GCC avait une branche dédiée, mais qui a mis beaucoup de temps a être fusionné avec le tronc commun ; clang/llvm a eu des implémentations très rapidement). Ironiquement, pas mal de profs qui travaillent à Ohio State University ont fait leur postdoc dans des labos français fin des années 80/courant 90, et ont fait ce que les français n'ont pas su : ils ont implémenté le modèle polyédrique dans un compilateur dès le début des années 2000. Depuis, le modèle est disponible dans LLVM, et il me semble qu'il n'est plus nécessaire d'activer explicitement une option pour que ce soit utilisé.
Le modèle polyédrique permet non seulement l'optimisation du code concerné, mais aussi la parallélisation automatique lorsqu'il s'applique. Cependant, pour paraphraser Feautrier, « Malheureusement le modèle polyédrique ne s'applique qu'aux polyèdres. » Un programme qui fait des accès indirects à une liste ou un tableau (A[B[i]]) ne peut être optimisé grâce au modèle polyédrique, car le compilateur est a priori incapable de garantir la monotonie des accès au tableau A dans mon exemple. Il existe des compilateurs (commerciaux) qui proposent d'annoter le code pour donner les infos nécessaires aux compilateurs optimisants reposant sur le modèle polyédrique pour l'aider à savoir quand il est possible de l'utiliser.
Renouveau des langages fonctionnels pour exploiter le parallélisme
Parmi les autres choses que je peux voir, c'est qu'avec la généralisation du parallélisme dans les ordinateurs (à cause de la venue des processeurs multicœurs vers 2004, et leur généralisation vers la fin des années 2000), tout un tas de langages, notamment fonctionnels, ont vu leur utilisation augmenter, mais aussi la recherche liée aux langages fonctionnels a aussi repris du poil de la bête (au moins à l'époque). La raison étant que les langages fonctionnels ont tendance à moins s'appuyer sur un état global du programme, ce qui veut dire que lorsqu'on crée des tâches pour s'exécuter en parallèle sur un système multiprocesseurs/multicœurs, alors il y a moins de risques de conflits, car les zones mémoires partagées sont moins grandes et moins nombreuses.
LLVM en général
LLVM est à la base un projet de compilateur financé par la NSF aux US (début des années 2000). Bien qu'il y ait des contributions au domaine de la compilation qui en sont dérivés, le projet en lui-même était innovant en termes d'architecture logicielle (et de génie logiciel) : il s'agissait d'intégrer dans un même cadre toutes les techniques d'optimisation ayant un impact positif significatif, et de proposer une architecture modulaire permettant de facilement intégrer de nouvelles passes de compilation (il y a aussi eu pas mal de publications sur la représentation interne du graphe de représentation des programmes donnés en entrée à LLVM).
L'impact de LLVM sur la recherche en compilation est extrêmement important. En proposant un logiciel raisonnablement bien documenté, et très bien architecturé, cela a permis à beaucoup de gens (étudiant-e-s en info « éclairés », technicien-ne-s/ingénieur-e-s, et bien entendu chercheurs et chercheuses dont c'est le métier) d'explorer et d'expérimenter pour l'optimisation de code, là où franchement, avec GCC, c'était bien plus galère.
C'en est au point que les compilateurs d'Intel et Nvidia/PGI, et je crois aussi celui de Microsoft, sont tous basés sur LLVM (bien entendu il y a des histoires de licences aussi, mais pas que).
LLVM innove beaucoup grâce à son système de représentation intermédiaire. L'IR de base reprend les « bonnes pratiques » pour un compilo, mais est aussi super facilement extensible (toutes proportions gardées — on parle d'un compilateur quand même). Récemment (vers 2019 ?) il a été proposé MLIR, qui est une sorte de moyen de créer ses propres représentations intermédiaires dans LLVM, exprimées à partir de l'IR de LLVM. Ça permet de rajouter des opérations et opérateurs utiles pour certains domaines (par exemple, la prise en compte de tenseurs pour des programmes qui s'en servent, comme les logiciels générant des modèles d'apprentissage profond).
Je suis pas mal à la ramasse sur tout ce qui s'est passé depuis 10-15 ans, du peu que j'ai suivi, Fran Allen avait bien raison en 2007 : il y avait un gros bouillonnement lié à l'arrivée des multicœurs et manycores. :-)
# Prix Turing et Grace Hopper
Posté par lasher . En réponse à la dépêche Delphine Demange et les compilateurs. Évalué à 10.
Sommaire
De l'attribution du prix Turing
Pourquoi Alan Perlis et pas Hopper ? Parce que c'est lui qui a fourni un premier compilateur fonctionnel (qui prend un programme de « haut niveau » — si j'ai bien compris, il s'agissait de formules mathématiques — en entrée et génère du code machine en sortie).
Grace Hopper a proposé le premier langage (et le compilateur associé) « pour humains » je dirais, et que je qualifierais de « généraliste » (même si je pense que le langage créé par Perlis était aussi Turing-complet). C'est l'une des premières personnes à insister sur la notion de lisibilité des programmes (au sens d'avoir un programme écrit « en anglais », ou quelque chose d'approché), et très clairement la première à avoir mené à bien ce projet.
Par contre, il existe un prix Hopper (et à ma connaissance pas de Prix Perlis), qui récompense une contribution unique et majeure accomplie avant 35 ans. Bon, il a été créé après la mort de Grace Hopper, et ça fait un peu guise de mea culpa de la part de l'ACM, mais peu de personnes peuvent se targuer d'avoir un prix à leur nom (même de façon posthume). Il y a aussi un Prix Hopper décerné « en interne » par la marine US pour les femmes qui ont des contributions majeures dans le numérique/l'informatique.
Concernant le côté tardif des remises de prix, honnêtement ça dépend aussi parfois de l'ère du temps. L'un des deux co-récipiendaires en 2025, Charles Sutton, récompensé pour ses travaux sur l'apprentissage renforcé (sur lequel il publie depuis les années 70, et qui a de vraies applications depuis longtemps), est bien plus vieux que Yann Le Cun (2015), récompensé pour son travail sur l'apprentissage profond de réseaux de neurones artificiels (et de mémoire, il a commencé à publier dessus vers 1989).
Enfin, concernant les progrès en compilation, il y a beaucoup de choses en ce qui concerne les compilateurs optimisants. La parallélisation automatique « générale » ne fonctionne pas (ou pas bien), ou bien est limitée au cas « triviaux » (sur des programmes qui respectent des propriétés facilement déterminées à la compilation). Je vais BEAUCOUP simplfier dans ce qui suit.
Modèle polyédrique
Par contre, il y a eu beaucoup de travaux sur l'optimisation et la parallélisation automatique de certains types de programmes, en particulier l'optimisation sur des nids de boucles imparfaits. Il s'agit d'optimisations reposant sur le modèle polyédrique. L'idée est que si des boucles imbriquées dans un programme respectent certaines propriétés bien spécifiques (notamment qu'on peut garantir le « sens » dans lequel les tableaux utilisés dans ces nids de boucles est « monotone », c'est-à-dire que l'accès est toujours croissant ou décroissant), alors il est possible de créer une représentation de l'espace d'itération de ces boucles sous forme de polyèdre, et les points qui le composent sont les points de l'espace d'itération. On peut ensuite « tordre » ce polyèdre pour changer l'ordre des boucles, dérouler certaines boucles, fusionner certaines instructions, etc., en fonction des contraintes d'optimisation voulues (taille du code, rapidité du programme, etc.).
Le modèle (et les premières implémentations semi-automatisées) a été proposé par Paul Fautrier dans les années 80. Il a co-écrit un article dans « Encyclopedia of Computer Science » qui résume l'approche. On peut trouver une version complète sur ResearchGate.
Il y a eu beaucoup de recherche en France, mais tout était très théorique, et quand c'était vraiment implémenté, c'était surtout des implémentations faites à la main pour montrer que les algos marchaient. Courant des années 2000, certaines implémentations dans des compilateurs (GCC avait une branche dédiée, mais qui a mis beaucoup de temps a être fusionné avec le tronc commun ; clang/llvm a eu des implémentations très rapidement). Ironiquement, pas mal de profs qui travaillent à Ohio State University ont fait leur postdoc dans des labos français fin des années 80/courant 90, et ont fait ce que les français n'ont pas su : ils ont implémenté le modèle polyédrique dans un compilateur dès le début des années 2000. Depuis, le modèle est disponible dans LLVM, et il me semble qu'il n'est plus nécessaire d'activer explicitement une option pour que ce soit utilisé.
Le modèle polyédrique permet non seulement l'optimisation du code concerné, mais aussi la parallélisation automatique lorsqu'il s'applique. Cependant, pour paraphraser Feautrier, « Malheureusement le modèle polyédrique ne s'applique qu'aux polyèdres. » Un programme qui fait des accès indirects à une liste ou un tableau (
A[B[i]]) ne peut être optimisé grâce au modèle polyédrique, car le compilateur est a priori incapable de garantir la monotonie des accès au tableauAdans mon exemple. Il existe des compilateurs (commerciaux) qui proposent d'annoter le code pour donner les infos nécessaires aux compilateurs optimisants reposant sur le modèle polyédrique pour l'aider à savoir quand il est possible de l'utiliser.Renouveau des langages fonctionnels pour exploiter le parallélisme
Parmi les autres choses que je peux voir, c'est qu'avec la généralisation du parallélisme dans les ordinateurs (à cause de la venue des processeurs multicœurs vers 2004, et leur généralisation vers la fin des années 2000), tout un tas de langages, notamment fonctionnels, ont vu leur utilisation augmenter, mais aussi la recherche liée aux langages fonctionnels a aussi repris du poil de la bête (au moins à l'époque). La raison étant que les langages fonctionnels ont tendance à moins s'appuyer sur un état global du programme, ce qui veut dire que lorsqu'on crée des tâches pour s'exécuter en parallèle sur un système multiprocesseurs/multicœurs, alors il y a moins de risques de conflits, car les zones mémoires partagées sont moins grandes et moins nombreuses.
LLVM en général
LLVM est à la base un projet de compilateur financé par la NSF aux US (début des années 2000). Bien qu'il y ait des contributions au domaine de la compilation qui en sont dérivés, le projet en lui-même était innovant en termes d'architecture logicielle (et de génie logiciel) : il s'agissait d'intégrer dans un même cadre toutes les techniques d'optimisation ayant un impact positif significatif, et de proposer une architecture modulaire permettant de facilement intégrer de nouvelles passes de compilation (il y a aussi eu pas mal de publications sur la représentation interne du graphe de représentation des programmes donnés en entrée à LLVM).
L'impact de LLVM sur la recherche en compilation est extrêmement important. En proposant un logiciel raisonnablement bien documenté, et très bien architecturé, cela a permis à beaucoup de gens (étudiant-e-s en info « éclairés », technicien-ne-s/ingénieur-e-s, et bien entendu chercheurs et chercheuses dont c'est le métier) d'explorer et d'expérimenter pour l'optimisation de code, là où franchement, avec GCC, c'était bien plus galère.
C'en est au point que les compilateurs d'Intel et Nvidia/PGI, et je crois aussi celui de Microsoft, sont tous basés sur LLVM (bien entendu il y a des histoires de licences aussi, mais pas que).
LLVM innove beaucoup grâce à son système de représentation intermédiaire. L'IR de base reprend les « bonnes pratiques » pour un compilo, mais est aussi super facilement extensible (toutes proportions gardées — on parle d'un compilateur quand même). Récemment (vers 2019 ?) il a été proposé MLIR, qui est une sorte de moyen de créer ses propres représentations intermédiaires dans LLVM, exprimées à partir de l'IR de LLVM. Ça permet de rajouter des opérations et opérateurs utiles pour certains domaines (par exemple, la prise en compte de tenseurs pour des programmes qui s'en servent, comme les logiciels générant des modèles d'apprentissage profond).
Je suis pas mal à la ramasse sur tout ce qui s'est passé depuis 10-15 ans, du peu que j'ai suivi, Fran Allen avait bien raison en 2007 : il y avait un gros bouillonnement lié à l'arrivée des multicœurs et manycores. :-)