Une différence particulière que j'ai constatée avec GCC 5.2.1 et Clang 3.6.2 est la suivante que si vous avez une boucle critique comme
for (;;) {
if (!visited) {
....
}
node++;
if (!*node)
break;
}
Alors GCC, lorsqu'il compile avec -O3
o -O2
de manière spéculative dérouler la boucle huit fois. Clang ne la déroulera pas du tout. Grâce à essais et erreurs j'ai trouvé que dans mon cas spécifique avec les données de mon programme, le bon nombre de déroulements est de cinq, donc GCC a dépassé et Clang en dessous. Cependant, le dépassement était plus préjudiciable aux performances, donc GCC s'est bien moins bien comporté ici.
J'ai aucune idée si la différence de déroulement est une tendance générale ou juste quelque chose qui était spécifique à mon scénario.
Il y a quelque temps, j'ai écrit un quelques collecteurs de déchets pour en apprendre plus sur l'optimisation des performances en C. Et les résultats que j'ai obtenus sont à mon avis suffisants pour favoriser légèrement Clang. Surtout que garbage est surtout une question de chasse aux pointeurs et de copie de mémoire.
Les résultats sont les suivants (chiffres en secondes) :
+---------------------+-----+-----+
|Type |GCC |Clang|
+---------------------+-----+-----+
|Copying GC |22.46|22.55|
|Copying GC, optimized|22.01|20.22|
|Mark & Sweep | 8.72| 8.38|
|Ref Counting/Cycles |15.14|14.49|
|Ref Counting/Plain | 9.94| 9.32|
+---------------------+-----+-----+
Il s'agit de code C pur, et je n'ai aucune prétention quant à l'efficacité de l'un ou l'autre des compilateurs. compilateur lorsqu'il compile du code C++.
Sur Ubuntu 15.10 (Wily Werewolf), x86.64, et une AMD Phenom II X6 1090T.
8 votes
Il semble que la question et les réponses soient tout de même intéressantes, et beaucoup sont intéressés.
13 votes
@YasserAsmi : Et les deux métriques - empreinte mémoire et vitesse d'exécution - sont loin d'être arbitraires ou sujettes à "opinion". Mais il semble que la maladie de Physics.SE se propage ici et les gens ont commencé à voter pour fermer sans lire les détails du texte de la question ici aussi.
19 votes
La question demande des repères et des comparaisons, la réponse donne les deux ... pourquoi est-ce une opinion au lieu d'une comparaison factuelle ?
3 votes
Il n'y a rien de fondé sur une opinion à demander quel compilateur produit les meilleurs binaires !
2 votes
@BjörnLindqvist Vraiment, vraiment ? Vous pensez que l'ensemble des binaires produits pour le même code source par différents compilateurs est un ensemble totalement ordonné, alors ? Nous pouvons les classer ? Et tout le monde serait d'accord sur le classement ? Et le classement serait le même pour la plupart des sources ? Il y aurait donc un compilateur clairement meilleur, un autre clairement second, etc ? Parce que tous il faudrait que ce soit vrai, pour que cette question no de se fonder sur des opinions.
0 votes
Oui, vraiment. Vous pouvez commander des compilateurs en exactement de la même manière que vous pouvez commander les coureurs les plus rapides du monde. Puisque les coureurs sont couramment commandés par des concours (benchmarks), les compilateurs peuvent évidemment être commandés aussi.
0 votes
@BjörnLindqvist Si la vitesse d'exécution est la seule chose qui compte, alors c'est un peu vrai, même si cela peut varier d'un projet à l'autre. Mais qu'en est-il de la correction ? De la stabilité ? De la vitesse de compilation ? Et la réputation d'un projet de corriger rapidement les bogues ? Du prix ? Les problèmes de licence ? Je me suis mis à Linux il y a 20 ans à cause des mises à jour constantes de Microsoft.
0 votes
@TomZych La question portait sur la production de meilleurs binaires. La vitesse de compilation, le prix et les autres attributs ne sont pas pertinents. Pour les programmeurs C/C++ modernes, la seule métrique pertinente pour comparer des binaires issus du même code source est la vitesse d'exécution. Dans la limite du raisonnable, bien sûr, et en supposant que les compilateurs fonctionnent, les fichiers exécutables de 1 Go ne sont évidemment pas souhaitables.
4 votes
Je ne vois pas pourquoi cette question a été fermée. Qu'il s'agisse d'une opinion ou d'un fait, nous voulons connaître la réponse, et le fait de la marquer comme fermée lui donne une teinte négative, alors qu'il ne devrait pas y en avoir.
7 votes
@TomZych : Si vous voulez connaître ces facteurs, posez des questions différentes. Celle-ci est très spécifique et sans ambiguïté - elle demande la vitesse d'exécution et l'empreinte mémoire. Vous pouvez être intéressé par d'autres facteurs, tant mieux pour vous, cela ne signifie pas que cette question est invalide, elle ne répond simplement pas à vos intérêts personnels. C'est comme si vous étiez un programmeur Java et que vous vouliez fermer toutes les questions sur le C# parce qu'elles ne parlent pas de Java.