En sécurité, la plus part des bugs sont trouvé avec des fuzzers. Concernant l'analyse statique, il existe https://en.wikipedia.org/wiki/Sparse qui permet de vérifier des propriétés statiques (gestion de mutex, d'espace mémoire, etc...).
Ces outils sont développés par les développeurs noyaux, qui n'ont pas en général de bagage en recherche dans le domaine concerné (test aléatoire, analyse statique). Au bout d'un moment ils pensent à un outil et ils en développent un from scratch pour leurs besoins. C'est une approche classique d'ingénieur et louable, mais les outils en question restent en général loin derrière l'état de l'art, les problèmes sur lesquels travaillent les chercheurs qui bossent dans le domaine. La recherche en analyse statique c'est Astrée par exemple, un outil qui prouve l'absence de comportement indéfini (segfault compris) dans l'ensemble du code de contrôle de certains Airbus. On est très, très loin devant Sparse en terme de puissance.
Ce que j'aimerais voir, si les développeurs Linux étaient plus ouverts au fait d'intégrer des résultats de recherche, c'est des outils qui sont développés pour le kernel par une collaboration d'universitaires et de développeurs noyaux actifs (il y a des chercheurs qui sont aussi développeurs noyaux). C'est le cas par exemple des travaux sur la formalisation du modèle mémoire de Linux et en particulier de RCU, qui est fait par un mélange d'universitaires et de développeurs—et il y a quelques développeurs qui se laissent parfois convaincre d'écrire des patches Coccinelle. Mais c'est très rare, ce n'est pas dans la culture de la communauté qui développe le noyau; c'est dommage.
Bien sûr, les prototypes issus de la recherche ne sont pas utilisables en l'état sur un logiciel aussi gros et compliqué que le noyau. C'est pour ça qu'il faut une collaboration entre les deux communautés, pour que les universitaires aient des retours sur les besoins du noyau, soient forcés de rendre leurs outils plus généraux et plus faciles à utiliser sur de vrais projets, et aient aussi l'assurance qu'il y a des gens prêt à les adopter derrière, qu'un effort de passage à l'échelle ne sera pas fourni à perte. Encore une fois, pour ça il faut une culture volontaire du côté des développeurs, et elle manque pour le noyau Linux (alors qu'elle est présente pour Windows, en partie parce que Microsoft n'a pas laissé le choix à ses développeurs). On peut dire que beaucoup de développeurs ont déjà plein de boulot et n'ont pas le temps de jouer à tester des prototypes d'outils pour le noyau, mais encore une fois, c'est une question de priorité (des personnes, et des organisations : la Linux Foundation pourrait financer ce genre de travaux si elle en avait envie).
Je n'ai pas vu de DSL.
Un exemple concret, dans la communauté que je connais mieux (et qui n'est pas celle qui travaille le plus sur la génération de code efficace, c'est plutôt un à-côté pour nous), serait Generating performance portable code using rewrite rules: from high-level functional expressions to high-performance OpenCL code par Michel Steuwer, Christian Fensch, Sam Lindley, et Christophe Dubach, 2015. Ils définissent un petit langage très simple pour composer des expressions qui décrivent des calculs sur GPU, et une façon de le compiler qui donne des programmes qui vont plus vite que des versions écrites à la main par des experts. Par exemple le code pour décrire une multiplication matrice/vecteur (GEMV en BLAS) dans ce langage est
et le résultat de la compilation va un peu plus vite que les bibliothèques fournies par les vendeurs de GPU (CUBLAS sur un GPU Nvidia, clBLAS sur un GPU AMD, et la MKL pour un CPU Intel), et est entre 2 et 5 fois plus rapide qu'une implémentation OpenCL portable selon la machine sur laquelle on la fait tourner.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 9.
Ces outils sont développés par les développeurs noyaux, qui n'ont pas en général de bagage en recherche dans le domaine concerné (test aléatoire, analyse statique). Au bout d'un moment ils pensent à un outil et ils en développent un from scratch pour leurs besoins. C'est une approche classique d'ingénieur et louable, mais les outils en question restent en général loin derrière l'état de l'art, les problèmes sur lesquels travaillent les chercheurs qui bossent dans le domaine. La recherche en analyse statique c'est Astrée par exemple, un outil qui prouve l'absence de comportement indéfini (segfault compris) dans l'ensemble du code de contrôle de certains Airbus. On est très, très loin devant Sparse en terme de puissance.
Les développeurs du noyau Windows ont aussi des outils très fins, avec une vraie collaboration avec la communauté de recherche sur l'analyse statique de fonctions noyau et des kernels, qui demande des annotations utilisées en pratique par les développeurs; voir SAL 2.0 Annotations for Windows Drivers par exemple, ou l'énorme travail sur le "whitebox testing" des composants Windows et de .NET ( par exemple, https://www.microsoft.com/en-us/research/publication/pex-white-box-test-generation-for-net/ ).
Ce que j'aimerais voir, si les développeurs Linux étaient plus ouverts au fait d'intégrer des résultats de recherche, c'est des outils qui sont développés pour le kernel par une collaboration d'universitaires et de développeurs noyaux actifs (il y a des chercheurs qui sont aussi développeurs noyaux). C'est le cas par exemple des travaux sur la formalisation du modèle mémoire de Linux et en particulier de RCU, qui est fait par un mélange d'universitaires et de développeurs—et il y a quelques développeurs qui se laissent parfois convaincre d'écrire des patches Coccinelle. Mais c'est très rare, ce n'est pas dans la culture de la communauté qui développe le noyau; c'est dommage.
Bien sûr, les prototypes issus de la recherche ne sont pas utilisables en l'état sur un logiciel aussi gros et compliqué que le noyau. C'est pour ça qu'il faut une collaboration entre les deux communautés, pour que les universitaires aient des retours sur les besoins du noyau, soient forcés de rendre leurs outils plus généraux et plus faciles à utiliser sur de vrais projets, et aient aussi l'assurance qu'il y a des gens prêt à les adopter derrière, qu'un effort de passage à l'échelle ne sera pas fourni à perte. Encore une fois, pour ça il faut une culture volontaire du côté des développeurs, et elle manque pour le noyau Linux (alors qu'elle est présente pour Windows, en partie parce que Microsoft n'a pas laissé le choix à ses développeurs). On peut dire que beaucoup de développeurs ont déjà plein de boulot et n'ont pas le temps de jouer à tester des prototypes d'outils pour le noyau, mais encore une fois, c'est une question de priorité (des personnes, et des organisations : la Linux Foundation pourrait financer ce genre de travaux si elle en avait envie).
Un exemple concret, dans la communauté que je connais mieux (et qui n'est pas celle qui travaille le plus sur la génération de code efficace, c'est plutôt un à-côté pour nous), serait Generating performance portable code using rewrite rules: from high-level functional expressions to high-performance OpenCL code par Michel Steuwer, Christian Fensch, Sam Lindley, et Christophe Dubach, 2015. Ils définissent un petit langage très simple pour composer des expressions qui décrivent des calculs sur GPU, et une façon de le compiler qui donne des programmes qui vont plus vite que des versions écrites à la main par des experts. Par exemple le code pour décrire une multiplication matrice/vecteur (GEMV en BLAS) dans ce langage est
et le résultat de la compilation va un peu plus vite que les bibliothèques fournies par les vendeurs de GPU (CUBLAS sur un GPU Nvidia, clBLAS sur un GPU AMD, et la MKL pour un CPU Intel), et est entre 2 et 5 fois plus rapide qu'une implémentation OpenCL portable selon la machine sur laquelle on la fait tourner.