Fortran se défend bien. Mais je me pose des questions sur le test "Naïve Fibonacci". Je ne vois pas pourquoi Fortran serait 50 fois plus rapide que le C et tout autre langage. En général, Fortran a une vitesse similaire à celle de C et C++.
J'ai également pensé à une suppression de la récursivité en la transformant en une boucle.
Je vais en parler à un développeur de GFortran pour essayer d'en savoir plus. Sachant que GFortran est basé sur GCC et que pour cet exemple on a pour le Fortran et le C la même option -O3, ça serait du côté du front-end Fortran qu'il se passerait des choses…
Je me demande si avec -O2 et -O3 le programme recalcule vraiment la fonction récursive. La fonction fibonacci(n) est toujours appelée avec la même valeur n en argument et renvoie toujours la même valeur. Si l'optimiseur est capable de voir ça, il peut décider de supprimer les appels inutiles (un seul suffit !).
C'est juste une idée, mais j'ai déjà eu des problèmes similaires en essayant de faire des benchmarks simples en Fortran, avec optimisation -O3.
J'ai des gros doutes sur la crédibilités d'un tel test.
1. Il fait 100 millions de boucles or dans les vrais programme on ne fait pas autant de boucles. C'est un avantages pour les JIT et pas révélateurs des perfs.
2. Voir Swift devant et C tout de même relativement significativement derrière me parait suspect. Il y a aussi le classement de Cobol tout dernier alors qu'il est compilé et conçu pour des machines "peu puissante" (Enfin puissante mais a une autre époque et avec de grosses contraintes de perfs) qui est étrange. Même Ruby devant Python me parait suspect ou PyPy à ce poitn plus performant que Python…
Bref cela mériterait une étude approfondie pour trouver le loup.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Trois années d'Advent of Code fait en python m'ont appris que PyPy est terriblement plus rapide que Python quand tu codes mal et ne sait pas exploiter les bonnes structures, ou que tu fais un algo peu optimisé, ou ne sait pas exploiter les merveilles disponibles en une ligne de code.
Si tu penses bien ton programme, si tu connais les forces et faiblesses du langage, même sur d'énormes boucles, des traitements à plusieurs millions d'occurrences, Python est similaire, voire meilleur que PyPy, et occupe presque toujours moins de mémoire.
À mon avis tu as ta réponse : le code en dessous doit être identique partout, utilisant le même algo, pas du tout repensé langage par langage, et donc le benchmark est in fine complètement faux.
Posté par barmic 🦦 .
Évalué à 4 (+2/-0).
Dernière modification le 06 novembre 2025 à 21:23.
Il manque un objectif à ce benchmark. Très clairement il est fait pour le fun, mais on ne peut pas dire tel language est plus formant que tel autre aussi facilement. Il faut un contexte. Est-ce qu'on doit prendre en compte le temps de démarrage, le démarrage à froid, la consommation mémoire doit-elle être prise en compte, est-ce qu'on regarde des programmes écrits par les gens les plus techniques de chaque langages, quel usages (beaucoup de mathématiques, beaucoup de manipulation de chaînes de caractères, des I/O,…), qu'est ce que c'est la performance ? Un temps d'exécution ? Une capacité à traiter des volumes plus grands ? Une capacité à s'exécuter sur du matériel petit ?
Si on regarde le programme le mieux écrit possible. Aucun langage compilé statiquement ne peut faire mieux que l'assembleur car si un language compilé statiquement fait mieux il suffit de le décompiler pour obtenir le programme assembleur équivalent. Est-ce que c'est une raison d'utiliser de l'assembleur certainement pas puisqu'il y a d'autres facteurs que la performance à prendre en compte
# Performances...
Posté par YBoy360 (site web personnel) . Évalué à 3 (+1/-0).
Java plus rapide que Java native…
I use Arch BTW
[^] # Re: Performances...
Posté par YBoy360 (site web personnel) . Évalué à 2 (+0/-0).
Autre benchmark
https://github.com/kostya/benchmarks
I use Arch BTW
[^] # The Computer Language Benchmarks Game (formerly called The Great Computer Language Shootout)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
C'est la référence depuis longtemps :
https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html
Des benchmarks non micro et des codes écrits par des développeurs non novice sur chaque langage.
"La première sécurité est la liberté"
[^] # Re: The Computer Language Benchmarks Game (formerly called The Great Computer Language Shootout)
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 04 novembre 2025 à 15:23.
D'ailleurs FFMPEG qui fait de la pub pour l'assembleur devrait coder les benchmarks pour voir si il gagne en perf sur les benchmarks de calcul.
"La première sécurité est la liberté"
# Fibo
Posté par vmagnin (site web personnel, Mastodon) . Évalué à 7 (+5/-0). Dernière modification le 03 novembre 2025 à 22:18.
Fortran se défend bien. Mais je me pose des questions sur le test "Naïve Fibonacci". Je ne vois pas pourquoi Fortran serait 50 fois plus rapide que le C et tout autre langage. En général, Fortran a une vitesse similaire à celle de C et C++.
On a juste une fonction récursive :
https://github.com/bddicken/languages/blob/main/fibonacci/fortran/fibonacci.f90
Est-ce que le compilateur lui réserverait une optimisation spéciale ? Bizarre… Je vais évoquer le sujet sur le Fortran Discourse.
[^] # Re: Fibo
Posté par YBoy360 (site web personnel) . Évalué à 2 (+0/-0).
En Fortran il me semble qu'il n'y a pas de variables locales (flag à la compilation). Donc 'n' ne serait pas sur la stack…
Pas sûr de moi, j'ai fais des tonnes de Fortran 77 en 2002, ça remonte.
I use Arch BTW
[^] # Re: Fibo
Posté par YBoy360 (site web personnel) . Évalué à 4 (+2/-0).
https://fortranwiki.org/fortran/show/recursion
En faite le calcul devrait être moins rapide en passant par des variables globales.
Il y a 2 possibilités :
fib_internalfait que l'appel prend bien moins de temps qu'en C ;il est possible en C de réduire aussi le scoping des symboles, mais je ne pense pas que les gains serait aussi important.
I use Arch BTW
[^] # Re: Fibo
Posté par vmagnin (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 04 novembre 2025 à 18:43.
J'ai également pensé à une suppression de la récursivité en la transformant en une boucle.
Je vais en parler à un développeur de GFortran pour essayer d'en savoir plus. Sachant que GFortran est basé sur GCC et que pour cet exemple on a pour le Fortran et le C la même option
-O3, ça serait du côté du front-end Fortran qu'il se passerait des choses…[^] # Re: Fibo
Posté par vmagnin (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 04 novembre 2025 à 21:44.
Je me demande si avec
-O2et-O3le programme recalcule vraiment la fonction récursive. La fonctionfibonacci(n)est toujours appelée avec la même valeur n en argument et renvoie toujours la même valeur. Si l'optimiseur est capable de voir ça, il peut décider de supprimer les appels inutiles (un seul suffit !).C'est juste une idée, mais j'ai déjà eu des problèmes similaires en essayant de faire des benchmarks simples en Fortran, avec optimisation
-O3.[^] # Re: Fibo
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Ah, puis-je présumer que nous allons bientôt avoir un journal parlant d'un langage de qualitay et de ses optimisations secrètes !
# Test sur un Apple M1
Posté par lolop (site web personnel) . Évalué à 3 (+1/-0).
Pour les langages compilés, faut voir les capacités d'optimisation des compilos.
Ça mériterais d'être refait sur un proc plus universel, avec optimisation vitesse pour les compilos.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Doute sur la crédibilité
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+1/-0). Dernière modification le 04 novembre 2025 à 22:07.
J'ai des gros doutes sur la crédibilités d'un tel test.
1. Il fait 100 millions de boucles or dans les vrais programme on ne fait pas autant de boucles. C'est un avantages pour les JIT et pas révélateurs des perfs.
2. Voir Swift devant et C tout de même relativement significativement derrière me parait suspect. Il y a aussi le classement de Cobol tout dernier alors qu'il est compilé et conçu pour des machines "peu puissante" (Enfin puissante mais a une autre époque et avec de grosses contraintes de perfs) qui est étrange. Même Ruby devant Python me parait suspect ou PyPy à ce poitn plus performant que Python…
Bref cela mériterait une étude approfondie pour trouver le loup.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Doute sur la crédibilité
Posté par Yth (Mastodon) . Évalué à 3 (+1/-0).
Trois années d'Advent of Code fait en python m'ont appris que PyPy est terriblement plus rapide que Python quand tu codes mal et ne sait pas exploiter les bonnes structures, ou que tu fais un algo peu optimisé, ou ne sait pas exploiter les merveilles disponibles en une ligne de code.
Si tu penses bien ton programme, si tu connais les forces et faiblesses du langage, même sur d'énormes boucles, des traitements à plusieurs millions d'occurrences, Python est similaire, voire meilleur que PyPy, et occupe presque toujours moins de mémoire.
À mon avis tu as ta réponse : le code en dessous doit être identique partout, utilisant le même algo, pas du tout repensé langage par langage, et donc le benchmark est in fine complètement faux.
# Il manque un objectif
Posté par barmic 🦦 . Évalué à 4 (+2/-0). Dernière modification le 06 novembre 2025 à 21:23.
Il manque un objectif à ce benchmark. Très clairement il est fait pour le fun, mais on ne peut pas dire tel language est plus formant que tel autre aussi facilement. Il faut un contexte. Est-ce qu'on doit prendre en compte le temps de démarrage, le démarrage à froid, la consommation mémoire doit-elle être prise en compte, est-ce qu'on regarde des programmes écrits par les gens les plus techniques de chaque langages, quel usages (beaucoup de mathématiques, beaucoup de manipulation de chaînes de caractères, des I/O,…), qu'est ce que c'est la performance ? Un temps d'exécution ? Une capacité à traiter des volumes plus grands ? Une capacité à s'exécuter sur du matériel petit ?
Si on regarde le programme le mieux écrit possible. Aucun langage compilé statiquement ne peut faire mieux que l'assembleur car si un language compilé statiquement fait mieux il suffit de le décompiler pour obtenir le programme assembleur équivalent. Est-ce que c'est une raison d'utiliser de l'assembleur certainement pas puisqu'il y a d'autres facteurs que la performance à prendre en compte
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.