C et C sont vraiment si rapides ?

Pendant tout ce temps où je suis engagé dans la programmation, j'entends dire que C et C sont les normes de vitesse. Le plus rapide des plus rapides, compilé directement en code assembleur, rien ne peut rivaliser en vitesse avec C ou C . Et personne ne semble remettre en question cette croyance commune.

Performances informatiques

Les opérations arithmétiques avec des nombres doivent évidemment fonctionner beaucoup plus rapidement en C que dans n'importe quel autre langage. Mais le sont-ils ?
Il y a quelque temps, j'ai décidé d'écrire un ensemble de critères simples pour de nombreuses langues différentes afin de voir quelle est réellement l'importance de la différence de vitesse.
L'idée était simple : trouver la somme d'un milliard de nombres entiers, en partant de zéro, en utilisant le calcul simple. Certains compilateurs (rustc, par exemple) remplacent ces cycles simples par une expression de formule, qui, bien sûr, sera évaluée à temps constant. Pour éviter cela avec de tels compilateurs. J'ai utilisé des opérations de coûts similaires avec des nombres, telles que bit à bit ou.
Après avoir obtenu les résultats, j'ai été très surpris. Ma vision du monde a été bouleversée et j'ai dû reconsidérer tout ce que je savais sur la vitesse des langages de programmation.
Vous pouvez voir mes résultats dans le tableau ci-dessous :

Linux 64 bits, 1,1 GHz ​​CPU, 4 Go RAM

Toutes les sources de tests que vous pouvez trouver ici :
https://github.com/Taqmuraz/speed-table

Donc, comme nous pouvons le voir, C n'est pas beaucoup plus rapide que Java, la différence est d'environ 3%. De plus, nous constatons que d'autres langages compilés sont très proches du C en termes de performances d'opérations arithmétiques (Rust est encore plus rapide). Les langages dynamiques, compilés avec le compilateur JIT, affichent de pires résultats, principalement parce que les opérations arithmétiques y sont enveloppées dans des fonctions distribuées dynamiquement.
Les langages dynamiques interprétés sans compilateur JIT affichent les pires performances, ce qui n'est pas une surprise.

Performances d'allocation de mémoire

Après cette défaite écrasante, les fans de C diraient que l'allocation de mémoire en C est beaucoup plus rapide, car vous l'attribuez directement depuis le système, sans demander GC.
Maintenant et après, j'utiliserai le terme GC à la fois comme garbage collector et comme tas géré, selon le contexte.
Alors, pourquoi les gens pensent que GC est si lent ? En fait, GC a une mémoire pré-alloué, et l'allocation consiste déplacer simplement le pointeur vers la droite. La plupart du temps, GC remplit la mémoire allouée par des zéros à l'aide d'un appel système, similaire à memset de C, donc cela prend temps constant. Alors que l'allocation de mémoire en C prend un temps indéfini, car cela dépend du système et de la mémoire déjà allouée.
Mais, même en considérant ces connaissances, je ne pouvais pas m'attendre à d'aussi bons résultats de Java, que vous pouvez voir dans les tableaux suivants :

Allocation de tableaux d'entiers

Allocation d'une instance de la classe Person avec un champ entier.

Toutes les sources de tests que vous pouvez trouver ici :
https://github.com/Taqmuraz/alloc-table

Là, j'ai testé quatre langages au total : C, C , Java et Lisp. Et les langages avec GC affichent toujours de meilleurs résultats, même si je les ai testés beaucoup plus strictement, que C et C . Par exemple, en Java, j'alloue de la mémoire via l'appel de fonction virtuelle, elle peut donc ne pas être optimisée statiquement, et en Lisp, je vérifie le premier élément du tableau alloué, afin que le compilateur ne saute pas l'appel d'allocation.

Libérer de la mémoire

Les fans de C sont toujours motivés à protéger leurs croyances, alors ils disent "Oui, vous allouez de la mémoire plus rapidement, mais vous devez la libérer après!".
Vrai. Et, du coup, GC libère de la mémoire plus rapidement que C. Mais comment ? Imaginez, nous avons fait 1 million d'allocations depuis GC, mais plus tard nous n'avons que 1000 objets référencés dans notre programme. Et disons que ces objets sont distribués sur toute cette longue période de mémoire. GC effectue le traçage de la pile, trouve ces 1000 objets "vivants", les déplace vers le pic de tas de la génération précédente et place le pointeur de pic de tas après le dernier d'entre eux. C'est tout.
Ainsi, peu importe le nombre d'objets que vous attribuez, le temps de travail de GC est déterminé par le nombre d'objets que vous conservez après.
Et, à l'opposé de cela, en C, vous devez libérer manuellement toute la mémoire allouée, donc, si vous avez alloué de la mémoire 1 million de fois, vous devez également effectuer 1 million d'appels de libération (sinon vous allez avoir des fuites de mémoire). Cela signifie, O(1)-O(n) de GC contre O(n) ou pire de C, où n est le nombre d'allocations effectuées auparavant.

Résumé

Donc, je veux consolider la victoire des langages ramassés sur C et C . Voici le tableau récapitulatif :

Maintenant, nous pouvons le constater : le ramassage des déchets n'est pas un mal nécessaire, mais la meilleure chose que nous ne pouvions que souhaiter. Cela nous donne de la sécurité etdes performances les deux.

Hommage à C

Bien que C affiche de moins bons résultats à mes tests, c'est toujours un langage important et il a son propre champ d'application. Mon article ne vise pas le rejet ou l’effacement du C. C'est pas mal, mais ce n'est tout simplement pas aussi supérieur qu'on le pense. De nombreux bons projets se sont effondrés uniquement parce que certaines personnes ont décidé d'utiliser C au lieu de Java, par exemple parce qu'on leur a dit que C est beaucoup plus rapide et que Java est incroyablement lent à cause du garbage collection. C'est bien, quand on écrit des programmes très petits et simples. Mais je ne recommanderais jamais d’écrire des programmes ou des jeux complexes avec C.

C est différent

C n'est pas simple, n'est pas flexible, a une syntaxe surchargée et des spécifications trop compliquées. En programmant avec C, vous ne mettrez pas en œuvre vos propres idées mais vous lutterez contre les erreurs du compilateur et de la mémoire 90 % du temps.
Cet article vise le rejet du C , car la vitesse et les performances ne sont que des excuses que les gens donnent pour utiliser ce langage dans le développement de logiciels. En utilisant C , vous payez avec votre temps, la performance de votre programme et votre santé mentale. Alors, lorsque vous aurez le choix entre le C et n'importe quel autre langage, j'espère que vous choisirez le dernier.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!