|
Offres de stage Master 2 | 
|
Pérennisation d'un système de benchmarks pour Common Lisp
1.introduction
Plus de 50 ans après la naissance du langage, et plus de 15 après sa standardisation, Lisp souffre toujours d'une légende de lenteur. Il est par exemple très rare de trouver des applications de calcul numérique scientifique écrites en Common Lisp. Dans le pire des cas, le développeur ne connaîtra tout simplement pas ce langage, et dans le meilleur des cas, ayant "entendu dire" qu'il est lent, considérera préférable de sacrifier un peu d'expressivité au profit de la performance.
Si cette légende de lenteur prend sa source dans une réalité tout à fait concrète datant des débuts du langage, cela fait pourtant de nombreuses années qu'elle est devenue totalement injustifiée. Lisp n'est plus, et depuis longtemps, un langage lent. Bien au contraire, les performances d'un programme Lisp bien écrit, optimisé, et compilé nativement, sont comparables à celles que l'on obtient de langages (ou à défaut de leurs compilateurs) considérés comme efficaces, tels C ou C++.
Rendre ses lettres de noblesse à Lisp consiste donc à casser cette légende de lenteur, le corollaire étant que si l'on ne perd rien en performance, on y gagne par contre beaucoup en expressivité.
2.contexte
Le travail proposé se situe dans le cadre d'un projet de recherche en cours sur le comportement et les performances de Common Lisp. Le but de ce projet est de fournir des bases expérimentales solides montrant que les performances d'un programme écrit en Common Lisp sont équivalentes à celle d'un programme C ou C++ similaire.
Le cas échéant, l'intérêt du travail réside également dans la capacité que nous avons à faire remonter nos observations vers les développeurs des principaux compilateurs Common Lisp, afin de contribuer à une amélioration ou une surveillance de leur niveau de performance (ce qui s'est déjà produit).
Cette étude passe par une analyse qualitative d'un certain nombre d'aspects du langage: la première étape consistait à évaluer l'arithmétique de bas niveau. La deuxième étape, en cours, cherche à observer le comportement des trois aspects fondamentaux de la couche objet: l'instantiation, l'accès aux slots (membres des classes) et le dispatch générique en général.
3.travail à réaliser
Afin de mener à bien cette étude, plusieurs compilateurs sont testés, et cela sur de nombreux paramètres (types de données, taille des classes, niveaux d'optimisation etc). La combinatoire induite engendre un grande quantité de tests individuels (micro-benchmarks): plus de 1300 cas de figures distincts dans la dernière étude. Si l'analyse de ces résultats ne peut qu'être manuelle, le lancement des tests ainsi que la collecte des résultats peuvent être très largement automatisés.
Dans l'état actuel des choses, le système de benchmarks utilisé est sous-optimal (partiellement automatisé et relativement ad-hoc). Par exemple, la génération des diagrammes comparatifs de performance est faite au travers d'un outil (xmgrace) dans une version instable et dont l'interface risque de changer. Le processus de collecte des résultats ne permet pas de conserver un historique sur plusieurs versions d'un même compilateur, rendant délicate voire impossible la mise en place de tests de régression etc.
Le travail à réaliser consiste donc en la pérennisation de ce système de benchmarks. Le but sera d'en faire un système robuste, intégrant de manière simple tous les point précités: collecte de résultats, génération automatique de diagrammes comparatifs, suivi des performances aussi bien transversal (plusieurs compilateurs) que longitudinal (plusieurs versions d'un même compilateur) etc. Une architecture de type base de données est à prévoir (même si cette base est elle-même ad-hoc).
4.pré-requis & apports du stage
Une connaissance préalable de Common Lisp est très vivement souhaitée. Cependant, pour un candidat motivé, la nécessité d'un apprentissage « sur le tas » n'est pas rédhibitoire, dans la mesure où le sujet ne porte pas à proprement parler sur le langage lui-même.
Une pérennisation réussie de ce système de benchmark permettra non seulement de faciliter le travail à venir, mais également de reprendre et mettre à jour les résultats déjà obtenus, en leur donnant une perspective chronologique qui manque à l'heure actuelle. Ce travail peut donc de lui-même aboutir à de nouvelles publications sur le sujet.
Enfin, si le déroulement du stage est satisfaisant, il peut naturellement se poursuivre sous la forme d'une thèse dont le financement est déjà prévu.
5.détails pratiques
- Responsable: Didier Verna
-
Lieu du stage:
Laboratoire de Recherche et Développement de l'EPITA (LRDE)
14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre
(Paris 13, Porte d'Italie) - Rémunération: 800 Euros Nets / Mois
6.bibliographie
Pour Common Lisp: Practical Common Lisp (Peter Seibel) http://www.gigamonkeys.com/book/
Pour le projet de recherche correspondant:
- Beating C in Scientific Computing Applications -- On the Behavior and Performance of Lisp, Part I. Verna, D. (2006). In Third European LISP Workshop at ECOOP , Nantes, France. http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf
- CLOS Efficiency: Instantiation -- On the Behavior and Performance of Lisp, Part 2.1 Verna, D. (2009). In Proceedings of the International Lisp Conference, MIT, Cambridge, Massachusetts, USA. http://www.lrde.epita.fr/~didier/research/verna.09.ilc.pdf
|
|
