Conférence gcc+MELT de Basile Starynkévitch chez Parinux

Mardi dernier, j’assistais à la conférence de Basile Starynkévitch sur le compilateur gcc et la réalisation de greffons. La description de la conférence, organisée par Parinux, est disponible ici ainsi que les slides de la présentation.

Pour ceux qui auraient raté la conf ou ceux qui n’ont pas pu se déplacer ou qui n’ont pas eu de place (oui, limité à 20 !), vous pourrez retrouver cette conférence présentée au salon « Solutions Linux en mars 2010″. De plus, une  autre conférence sera programmée par Parinux. Ce sera publié dans l’agenda du libre.

Bref, tout ça, c’est bien beau, mais qu’est ce qui a été dit ?
Je ne suis pas du tout dans l’informatique de formation (je suis étudiant en physique fondamentale) bien que j’ai quelques connaissances en programmation, mais je me dis que dans une conférence on apprend toujours quelque chose, alors même si la seconde partie semble très ardue, j’ai foncé. Alors, oui, j’ai appris des petites choses dans la première partie. En vrac :

Quelques rappels (pour moi) sur ce qu’est la compilation. Grosso modo, c’est le passage d’un langage source (qui n’est pas forcément du texte) en un langage cible (qui n’est pas toujours du binaire). On fait une distinction entre compilateur et interpréteur qui lui analyse, traduit et exécute.

Quelques corrections d’idées reçues : le C n’est pas forcément un langage proche de la machine, n’est pas forcément portable (32/64 bits) ni même le plus performant.

La complexité  des processeurs a été mis en exergue ainsi que les questions de performances. Chercher une information dans la RAM est 500 fois plus long que d’aller la chercher dans un cache (dit L1)

GCC possède un copyright FSF. Je ne le savais pas, et le conférencier à bien expliqué que cela pouvait être un frein important (il en a d’ailleurs fait les frais), en entreprise, pour des contributions. Ceci s’oppose au kernel linux par exemple, où c’est le nom du (des) développeur(s) qui est utilisé pour le copyright. C’est ce qui explique sans doute l’intérêt des greffons car ceux-ci ne sont pas assujettis à cette contrainte.

La prise de poids du code (qui correspond effectivement à de nouvelles fonctionnalités) est croissante, ce qui augmente bien évidement sa complexité : + 35% en 3 ans environ.

Un autre point que j’ignorais totalement est que les commits (ajout de codes nouveaux dans le trunk) doit être validé par un pair. Ce n’est pas sans rappeler les publications scientifiques. Cependant, un développeur indépendant (ie seul dans son coin) aura plus de mal à faire passer ses patchs qu’un codeur de chez google qui a plusieurs collègues impliqués dans le projet. D’ailleurs, il a été discuté que google a de grands intérêts à payer des programmeurs pour gcc (pour ceux qui se poseraient la question). Le conférencier a pris simplement la supposition qu’ils pouvaient améliorer de 0.1 % les performances de gcc et que sur des millions de serveurs, cela devrait être amortis par les couts d’électricité.

Il a été remarqué aussi que gcc ne gère pas le multithreading ! On contourne cependant le problème par la création de fichiers objets (*.o) à partir des *.c en parallèle dans les makefiles. (make -j2 par ex.) L’ajout d’options d’optimisation (-O1, -O2, -O3, -Oo…) augmente considérablement le temps de compilation. Ces options font que gcc va « malaxer » le code plus longtemps. C’est pour cela qu’il est intéressant lorsque l’on développe un peu de passer un -O0 pour éviter les optimisations qui ne nous intéressent pas lorsque l’on vérifie/débugue.

La suite était vraiment plus technique, je ne vais pas en parler pour ne pas dire de bêtises (en espérant ne pas en avoir dit de trop ci-dessus ), mais j’espère que je vous ai convaincu que :

• même dans une conférence technique, on peut apprendre des choses intéressantes
• vous, connaisseur en la matière, pouvez être intéressés par cette conférence.