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

Langue compilateur/version/args heure ête> Rust (

Language	compiler/version/args	time
Rust (bitwise or instead of )	rustc 1.75.0 with -O3	167 ms
C	gcc 11.4.0 with -O3	335 ms
NASM	2.15.05	339 ms
Go	1.18.1	340 ms
Java	17.0.13	345 ms
Common Lisp	SBCL 2.1.11	1 sec
Python 3	pypy 3.8.13	1.6 sec
Clojure	1.10.2	9 sec
Python 3	cpython 3.10.12	26 sec
Ruby	3.0.2p107	38 sec

bit à bit ou au lieu de ) rustc 1.75.0 avec -O3 167 ms C gcc 11.4.0 avec -O3 335 ms NASM 15.02.05 339 ms Partez 1.18.1 340 ms Java 17.0.13 345 ms Common Lisp SBCL 2.1.11 1 seconde Python 3 pypy 3.8.13 1,6 s Clojure 1.10.2 9 secondes Python 3 cpython 3.10.12 26 secondes Rubis 3.0.2p107 38 secondes

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 :

ête>

1.1 GHz 2 cores, 4 GB RAM

Running tests on single thread.

Result format : "Xms-Yms ~Z ms" means tests took from X to Y milliseconds, and Z milliseconds in average

1,1 GHz ​​2 cœurs, 4 Go RAM Exécution de tests sur un seul thread. Format du résultat : "Xms-Yms ~Z ms" signifie que les tests ont duré de X à Y millisecondes, et Z millisecondes en moyenne

Allocation de tableaux d'entiers

integers array size	times	Java 17.0.13 new[]	C gcc 11.4.0 malloc	Common Lisp SBCL 2.1.11 make-array
16	10000	0-1ms, ~0.9ms	1-2ms, ~1.2ms	0-4ms, ~0.73ms
32	10000	1-3ms, ~1.7ms	1-3ms, ~1.7ms	0-8ms, ~2.ms
1024	10000	6-26ms, ~12ms	21-46ms, ~26ms	12-40ms, ~7ms
2048	10000	9-53ms, ~22ms	24-52ms, ~28ms	12-40ms, ~19ms
16	100000	0-9ms, ~2ms	6-23ms, ~9ms	4-24ms, ~7ms
32	100000	0-14ms, ~3ms	10-15ms, ~11ms	3-8ms, ~7ms
1024	100000	0-113ms, ~16ms	234-1156ms, ~654ms	147-183ms, ~155ms
2048	100000	0-223ms, ~26ms	216-1376ms, ~568ms	299-339ms, ~307ms

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

how many instances	Java 17.0.3 new Person(n)	C g 11.4.0 new Person(n)
100000	0-6ms, ~1.3ms	4-8ms, ~5ms
1 million	0-11ms, ~2ms	43-69ms, ~47ms
1 billion	22-50ms, ~28ms	process terminated

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 :

demandes langues avec GC C/C ête> arithmétique rapide avec

demands	languages with GC	C/C
arithmetic	fast with JIT	fast
allocating memory	fast O(1)	slow
releasing memory	fast O(1) best case, O(n) worst case	O(n) or slower
memory safe	yes	no

JIT rapide allocation de mémoire rapide O(1) lent libérer de la mémoire rapide O(1) meilleur des cas, O(n) pire des cas O(n) ou plus lent mémoire sécurisée oui non

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!