Pourquoi le C est-il plus rapide que le langage C++ ?
Dans ce tutoriel est sur le langage C++ nous évitons quelques confusions autour le langage C++.
tutoriel langage C++ / tuto en ligne langage C++ / cours gratuit langage C++ /formation en ligne C++
Les avantages du langage C++
Il y a beacop de confusions sur les similitudes entre C et C++. Alors que le C++ a commencé comme un sur-ensemble du C contemporain, les deux langages ont évolué. Tout comme nous ne sommes pas simplement des sur-ensembles de l’un ou des deux de nos parents.
Il existe des cas spécifiques où il est possible de créer un fichier source qui peut être compilé en C ou en C++ et, en utilisant le même compilateur avec les mêmes drapeaux de compilation, produire le même objet exécutable avec les mêmes instructions.
Ceux-ci ont les mêmes performances.
Pendant une grande partie de la durée de vie de chaque langage, C était généralement le langage de supra-assemblage le plus rapide pour de nombreux scénarios, car il était le plus capable d’un codage 1: 1 instruction: instruction.
Empirically, these have the same performance.
For much of the lifespan of each language, C was typically the fastest, supra-assembly, language for many scenarios because it was most capable of a 1:1 statement:instruction coding.
a = 1; // maps to arm: `mov w20, 1`
Malheureusement, la majorité des architectures d’aujourd’hui sont très complexes avec plusieurs niveaux de cache, une exécution spéculative, des prédicteurs et un pipelining profond.
En supposant que vous utilisez un compilateur moderne sur une architecture moderne – clang, gcc, msvc ; x86_64, arm64, amd64, m1 – alors les compilations C et C++ partageront un grand nombre de chemins de code et de fonctionnalités.
Les premiers C++ – c’est-à-dire les fonctionnalités distinctes de C telles que les méthodes de classe, etc. – souffraient souvent de surcharges de performances d’exécution.
Dans l’implémentation C, la façon dont nous utilisons ‘op’ rend évident qu’il n’aura pas plus de surcharge qu’un appel de fonction normal.
Voir le lien du compiler
Dans l’implémentation C, la façon dont nous utilisons ‘op’ rend évident qu’il n’aura pas plus de surcharge qu’un appel de fonction normal.
L’implémentation C++ n’est cependant pas si claire, et les compilateurs C++ plus anciens auraient en effet dû faire une indirection :
Voir le lien Compiler
Cela ne rend pas C plus rapide, cela montre simplement que certains modèles et comportements C++ entraînent une surcharge supplémentaire qui peut les ralentir. Vous pouvez toujours utiliser le mécanisme C dans un programme C++ si vous devez éliminer cette instruction supplémentaire.
Un appel de fonction ne fait pas un programme particulièrement bon à comparer.
À l’inverse, le code C doit souvent contenir des répétitions passe-partout de la même fonction pour gérer différents arguments.
Les programmeurs C traitent souvent cela en écrivant des macros
Les programmeurs C++ substitueraient une macro à un modèle ou utiliseraient les fonctionnalités génériques C modernes.
Dans les deux cas, si possible, un compilateur moderne tentera d’éliminer les fonctions générées en double. Dans les versions génériques ( C et C++ ), le compilateur obtient un petit indice pour les candidats.
Cependant dans le cas C, il convient de noter que les fonctions ont des noms différents… Donc, ce ballonnement est passé en amont.
En fin de compte, de nombreux projets C se terminent par quelque chose comme :
Il n’est pas obligatoire de le faire de cette façon, c’est souvent le cas. C’est là que l’héritage C++ et la fonction virtuelle seraient utiles et amortiraient ces indirections vtable en éliminant une branche conditionnelle vue ci-dessus, en remettant C++ sur un pied d’égalité avec le code C, ou éventuellement un léger avantage, selon la complexité et ainsi de suite.
Donc, en fin de compte, la réponse à « ce qui rend C plus rapide » est : le code que vous alimentez.
À partir de C ++ 17 et C 18, vous pouvez écrire (* mise en garde, presque, pour autant que je sache) n’importe quel code en C ou C ++, vous pouvez écrire du code dans l’autre langage qui finira par compiler exactement les mêmes instructions machine, si vous êtes prêt à aller jusqu’au bout, indépendamment de la maintenabilité et de la lisibilité.
——– Tutoriel Langage C++————-
Les programmeurs C++ peuvent se tourner vers une grande bibliothèque de fonctions standard bien conçues avec des caractéristiques bien connues qui tenteront de fournir les meilleures performances de scénario moyen à travers les architectures, mais ne sont pas garantis de fournir les meilleures performances en toutes circonstances et pour tous les modèles d’utilisation.
Les programmeurs C doivent généralement se tourner vers des bibliothèques externes pour ceux-ci ou les implémenter eux-mêmes.
La vraie différence entre C et C++ est la question de concentration. Les programmeurs C croient que, lors du codage en C, il n’y a pas de magie cachée. Les programmeurs C++ répliqueront avec un argument sur la difficulté de déchiffrer ce qui se passe dans une macro, et tous ceux qui ne sont pas programmeurs C++ pointeront vers un avertissement d’instanciation de modèle de 700 lignes…
J’ai constaté que, dans la pratique, les problèmes de performances sont beaucoup plus faciles à faire apparaître et à raisonner en C car ils se cachent rarement dans une macro. Inversement, en C++, ils se cachent régulièrement dans les méta-entrailles d’un problème de méta-programmation profondément imbriqué qui vous oblige non seulement à traduire mentalement C<->assembleur, mais aussi à prendre en compte les aspects profonds de la façon dont le langage est compilé (ADO, ODR , SFINAE) et un standard très profond.
———————– Comptrendre le langage C++ ———-
Les programmeurs C diraient que le fait d’avoir 24 versions de “compare_a_and_b” signifie que chaque cas est explicitement décrit et lorsqu’il s’avère que la version 64 bits à double caractère signé est celle qui est lente, vous pouvez faire une solution chirurgicale.
Résoudre ce problème dans une fonction générique signifie soit créer une spécialisation, dont vous devez ensuite être conscient lors du réglage de ce que vous pensez être une fonction générique unique, soit écrire plus de code dans un seul chemin de code, ajoutant une complexité à laquelle vous ne vous attendriez pas normalement. .
Cet argument, cependant, n’est qu’un point de vue. Lorsque je travaillais dans de grandes bases de code C, j’ai fréquemment rencontré des problèmes où un chemin de code unique existait qui n’était pas tenu à jour avec les fonctions d’accompagnement et qui, à un moment donné, est devenu un goulot d’étranglement ou une cause de bogues rares.
Pense-y de cette façon:
Si la fonction f est très rapide et que vous l’appelez 1 000 000 000 fois dans une boucle, est-ce que cela va être rapide ? Ou serait-il plus rapide de faire 1 000 000 d’appels à la fonction g qui appelle f 990 fois ?
La bonne réponse n’est pas intuitive, car ce simple changement de modèle pourrait changer radicalement la branche du processeur ou la prédiction du cache, et les échecs qui en résulteraient pourraient rendre la deuxième option radicalement plus lente malgré le fait techniquement moins de travail…
Et donc C est plus rapide lorsque vous y écrivez du code plus rapide, tandis que C++ est plus rapide lorsque vous écrivez/utilisez du code plus rapide dans it.
Autres articles
