Palmarès Projets GL 2026
Toutes les équipes du projet GL sont invitées à se comparer les unes aux autres en mesurant l’efficacité
énergétique du code produit par leur compilateur sur les 3 fichiers de test fournis dans
src/test/deca/codegen/perf/provided.
Le tableau ci-dessous est éditable par les étudiants, ce qui vous permet de noter les performances de chaque équipe. LORSQUE votre compilateur est prêt à participer, c’est à dire capable de compiler au moins un des programmes, vous pouvez remplir les cases du tableau avec une ligne pour votre équipe. Il s’agit d’un palmarès à trier par la colonne “Score”, du plus faible (c’est à dire le moins consommateur) au plus fort (le plus gourmand en cycles, donc en énergie). Ce score est une pondération des résultats sur les 3 programmes de test. Vous devez donc honnêtement remplir le tableau avec les performances (actuelles) de votre compilateur. Si vous l’améliorez, vous aurez le droit de changer votre ligne et de la remonter plus haut dans le classement.
Votre objectif est bien sûr de faire mieux que le vieux compilateur des enseignants, conçu il y a bien longtemps, dans le “monde d’avant”, sans souci d’efficacité énergétique. Il ne devrait donc pas être difficile à battre, et la compétition se jouera entre les meilleures équipes. Vous pouvez regarder le Palmarès de l’année 2021 pour voir ce à quoi était parvenu vos anciens. 20 équipes de 2021 avaient fait mieux que le vieux compilateur des profs. Nous espérons que la conscience environnementale accrue des étudiants permettra à encore plus d’équipes en 2026 d’améliorer ce score. Une place dans le “TOP 10” donnera un bonus pour la partie de la note consacrée au développement durable.
- Pour chaque programme, vous devez donner le nombre de cycles utilisés par le code assembleur
produit par votre compilateur, que vous pouvez obtenir par la commande
ima -s. - Chacun de ces programmes a été validé, et ne produira pas d’erreur (débordement arithmétique ou
autre).
Donc vous pouvez (et c’est recommandé) obtenir l’assembleur par la commande
decac -n. C’est d’ailleurs ce à quoi sert cette option: gagner du temps d’exécution (et de la consommation de ressources) sur les programmes validés. - Si vous n’êtes pas encore capables de compiler un des programmes (par exemple
ln2_fctqui utilise l’objet), vous utilisez la valeur indiquée pour gl00 pour ce programme (par exemple 50000 pourln2_fct) pour calculer le score. Donc avant que votre compilateur ne puisse compiler de l’objet et des fonctions, vous avez peu de chances de battre VieuxCompDeProf. - Bien entendu, vous n’avez le droit d’afficher un nombre de cycles différent de
gl00que si vous pouvez compiler ce programme ET si votre assembleur calcule le résultat correct (annoncé dans les commentaires du fichier source). - Afin de mieux comparer les équipes, nous vous demandons aussi de préciser l’extension que vous traitez. En effet, les équipes ayant choisi l’extension Optim sont favorisées pour traiter spécifiquement l’efficience de leur compilateur puisque c’est l’objet principal de leur extension.
- Toutes les modifications sur le Wiki sont enregistrées, donc toute malhonnêteté entraînera la disqualification de l’équipe et bien sûr une incidence sur la note du projet (pour non respect de l’éthique - sportive).
| Equipe | Extension | S=Syracuse42 | L0=ln2 | L1=ln2 fct | Score=L0+L1+10*S |
|---|---|---|---|---|---|
| gl25 | RISC-V | 701 | 6084 | 8700 | 21794 |
| gl54 | TRIGO | 1324 | 15064 | 18239 | 46543 |
| VieuxCompDeProf | TRIGO | 1340 | 15194 | 18102 | 46696 |
| gl13 | Tableau | 1394 | 15554 | 18427 | 47921 |
| gl29 (@RF) | TRIGO | 1624 | 16244 | 20573 | 53057 |
| gl30 (@RF) | TRIGO | 1608 | 22652 | 25997 | 64729 |
| gl28 (@RF) | ARMv7 | 1626 | 16096 | 50000 | 82356 |
| gl26 (@RF) | TAB | 1759 | 19568 | 50000 | 87158 |
| gl27 (@RI-2) | TRIGO | 1374 | 50000 | 50000 | 113741 |