Projet GL
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
Edit page

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.

Consignes

  • 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_fct qui utilise l’objet), vous utilisez la valeur indiquée pour gl00 pour ce programme (par exemple 50000 pour ln2_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 gl00 que 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