"De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C."
Je t'invite à tenter de concurrencer un compilateur C avec ton source en langage d'assemblage.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
"De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C."
Je t'invite à tenter de concurrencer un compilateur C avec ton source en langage d'assemblage.
Alors je fais peut être des raccourcis naïfs, mais dans les ordres de grandeur je ne pense pas me tromper :
- Les résultats de l'étude portugaise, en terme d'efficacité énergétique, sont fortement corrélés à des résultats de perfs de langage.
- Avec WASM, par construction JS se retrouve en concurrence avec les autres langages, y compris compilés et de bas niveau.
Donc pour le point 1, on apprend que plus un langage va vite moins le CPU est utilisé longtemps pour exécuter une tâche : incroyable.
Et dans le point 2, on apprend qu'un langage compilé & bas-niveau va plus vite qu'un langage scripté & haut-niveau : incroyable.
Au final j'ai beaucoup plus appris en lisant les commentaires pertinents des personnes ici. ^^
My 2 cents : ce qu'on voit là est une loi mathématique à l'oeuvre en biologie évolutive.
- En période d'abondance de ressources, la sélection tend à favoriser d'autres traits avantageux que la chasse aux ressources (i.e. avantages reproductifs).
- En période de contraction des ressources vitales, la sélection tend à favoriser drastiquement les traits améliorants l'accès aux ressources (i.e. avantages économes).
La queue du Paon, Python, même combat : c'est parfaitement adapté au contexte. Et le jour où l'économie de ressources sera vital, vous voyez très bien quels langages vont souffrir du nouveau contexte et lesquels vont briller.
Optimisations faites par le compilateur.
Il faut vraiment penser à toutes les optimisations possible à faire, que fait le compilateur fait. Par exemple sur architecture CISC se dire qu'il est moins couteux en nombre de cycle de faire un décalage de bit à gauche (SHL en assembleur 8086) qu'une multiplication par 2 (MUL, en assembleur 8086), etc...De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C.
Le C++ 50% plus lent que C!?
Là faudrait m'expliquer comment ils arrivent à un chiffre pareil.
L'avantage de C++ par rapport à C c'est une programmation OO et de plus haut niveau, pas la rapidité d'exécution.Envoyé par ParseCoder
Le C++ 50% plus lent que C!?
Le plus rapide en exécution du code c'est l'assembleur, après le C.
Le langage Rust est un choix intéressant car c'est un langage de haut niveau, mais qui a de bonnes performances d'exécution, proche du C, et généralement clairement bien meilleures par rapport aux autres langages de haut niveau.
On pourrais simplifier en disant que la nouvelle mode de Python est une catastrophe écologique, car les performances d'exécution sont dégueulasses, et qu'on pourrait dire à l'extrême qu'on devrait faire une loi mondiale pour interdire Python et obliger les codeurs à utiliser Rust
Comment faire moins avec plus (voire plus plus)
Bonjour ParseCoder,
Avec le C embarqué dans C++, c'est effectivement surprenant.... 50% plus lent que C!?...
Mais certains s'interdisent d'utiliser les possibilités du C avec C++. Le dogmatisme dans sa splendeur : C++ == objet, C != objet. C'est aussi oublier l'histoire du C++ et le fait que le C embarqué n'est pas seulement un vestige de cette histoire mais un choix délibéré.
Cependant certaines facilités du C++ sont tentantes et peuvent faire oublier que ces facilités ont un coût je pense, par exemple, à la surcharge des opérateurs qui tendent souvent à multiplier les créations/destructions d'objets. Mais dans un challenge cela ne devrait pas apparaître.
Salut
ou "Retourner à la machine à écrire peut-il sauver la couche d'ozone" ?
Y'a quand même des mecs qui s'em*** dans la vie à prouver des trucs évidents.
A mon tour : Au feu Python, JS, PHP, bash, Java, C#, Kotlin, etc. et vive l'asm !
A l'extreme limite, on garde C/C++, Delphi, Go... et encore je suis sympa, hein)
En complément...
Je ne sais pas comment ils ont fait leurs tests, rust est effectivement très rapide, peu gourmand mais ce n'est peut-être pas aussi catastrophique pour certains langages (je pense au php notamment).
La syntaxe du langage semble assez indigeste, surtout pour faire du web...
En tout cas voici un ensemble assez précis en complément.
https://github.com/kostya/benchmarks
C plus rapide que le C++, pas si évident que cela
https://benchmarksgame-team.pages.de...t/gcc-gpp.html
Ici on dit le contraire
Bonjour.
On parle beaucoup de rapidité des langages, sans mettre en parallèle la consommation mémoire de ceux-ci. De plus lorsqu'une instance nécessaire à un langage interprété tourne en fond de tâche, on en tient pas compte dans la rapidité...
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
J'ai la priorité
Bonjour,
Je n'ai pas regardé tous les sources mais dans ceux que j'ai vu il n'y en pas un qui élève son degré de priorité (peut être est-ce interdit par le bench). Pourtant c'est un moyen assez simple pour grapiller quelques % en étant moins soumis à la concurrence des autres taches.
Salutations
A ma connaissance la manière la plus naïve qui soit de compter le temps utilisé par un processus est d'utiliser la commande time et celle-ci fait déja la différence entre real (temps total ressenti), user(temps réel CPU accordé à l'utilisateur) et sys ( temps utilisé par les IO système).
En l'occurence jouer leur la prio fera baisser le real mais n'impactera pas user et sys. J'ose espérer qu'un site spécialisé dans le benchmark tien à minima compte de ces valeurs et sinon utilise des outils plus pointus ^^
Temps incertains
Bonjour AoCannaille,
Peut être pas si simple. Il semble qu'ils aient choisi une exécution représentative du vrai monde et multiplié les exécutions pour avoir une moyenne plus stable. Ce qui peut se défendre mais reste sensible au changement de priorité.
En outre, comment le temps CPU est compté dans les multithreads (et il y en a) ? Temps CPU et durée peuvent être sensiblement différents. Par ailleurs, les changements de contextes (reprise d'un traitement d'un thread)) sont généralement à la charge du bénéficiaire ce qui signifie qu'une exécution chahutée sera plus longue - même en temps CPU - qu'une exécution plus zen.
J'ai toujours trouvé la mesure de temps très difficile et insatisfaisante. Et je ne parle même pas des processeurs qui s'amusent à faire évoluer leur vitesse.
Salut
Je vais faire une petite correction à tout ces titres :
Rust, C ou C++ on peut faire la même chose ( hormis quelques paradigme spécifique )WASM peut-il sauver la planète?
Dire que C est plus rapide que C++ ou Rust c'est du Bullshit.
C++ n'est pas que POO, c'est multi-paradigme, donc on peut faire du C dans un .cpp
Juste pour info le compilateur C chez Microsoft c'est un compilateur C++... Donc C++ fait du C avec optionnellement une couche objet.
Le plus gros problème est plus une question d’algorithmie que de langage
il y a différente d’implémentation de l'algo de fibonacchi
4 version de l'algo avec des complexite différente .
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119public class Fibo { public static void main(String[] args) { for (int i = 0; i < 20; i++) { print(i); } print2(50); print2(92); print2(93); } private static void print(int i) { System.out.println( "i=" + i + ", fibo=" + fibo(i) + ", fibo2 " + fibo2(i) + ", fibo3 " + fibo3(i) + ", fibo4 " + fibo4(i)); } private static void print2(int i) { System.out.println("i=" + i + ", fibo2 " + fibo2(i) + ", fibo3 " + fibo3(i) + "+ fibo4 " + fibo4(i)); } public static long fibo(int n) { if (n == 0) { return 0; } if (n == 1) { return 1; } return fibo(n - 1) + fibo(n - 2); } public static long fibo2(int n) { if (n == 0) { return 0; } if (n == 1) { return 1; } long a = 1; long b = 0; for (int i = 1; i < n; i++) { long tmp = a; a = b + a; b = tmp; } return a; } public static long fibo3(int n) { if (n == 0) { return 0; } if (n == 1) { return 1; } if (n == 2) { return 1; } int n_2 = n / 2; if (n % 2 == 0) { long r1 = fibo3(n_2); long r2 = fibo3(n_2 + 1); // fibo(2n)=fibo(n)*(fibo(n-1)+fibo(n+1); return r1 * (r2-r1 + r2); } long r1 = fibo3(n_2); long r2 = fibo3(n_2 + 1); // fibo(2n+1)=fibo(n)*fibo(n)+fibo(n+1)*fibo(n+1); return r1 * r1 + r2 * r2; } public static long fibo4(int n) { if (n == 0) { return 0; } if (n == 1) { return 1; } long l[] = recurseFibo4(n); return l[0]; } public static long[] recurseFibo4(int n) { if (n == 0) { return new long[] { 0, 1 }; } if (n == 1) { return new long[] { 1, 1 }; } if (n == 2) { return new long[] { 1, 2 }; } int n_2 = n / 2; if (n % 2 == 0) { long l[] = recurseFibo4(n_2); long r1 = l[0]; long r2 = l[1]; long a = r1 * (r2 - r1 + r2); long b = r1 * r1 + r2 * r2; return new long[] { a, b }; } long l[] = recurseFibo4(n - 1); long r1 = l[0]; long r2 = l[1]; long a = r2; long b = r1 + r2; return new long[] { a, b }; } }
le 1 ° a une conplexite N²
le 2 ° a un complexite en N
le 3 ° en (log2) N *(log2) N
le 4° en log(2)N (le plus rapide )et qui est recursif peut etre exister aussi en non recursif => mais il sera encore moins lisible).
Ce n'est pas vraiment un problème, les stats étant basées sur the benchmark game, qui accepte plusieurs implémentations pour un langage donné.
En exemple au pif, une implemetation de mandelbrot en C++/g++ et une autre
C'est pas pour rien que cela s'appelle "benchmarks game", si tu trouves l'implémentation dans ton langage favori mal optimisé, tente ta chance pour le faire monter dans les stats
Étude intéressante, mais tout le bénéfice d'un langage économe est perdu si le programme exécuté n'est pas aussi optimisé. Je dirais même qu'il est largement préférable d'avoir un bon dev Python, qu'un mauvais Rust ;-)
C'est sur que d'avoir un bon Rust serait encore mieux :-p
« Choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C », d'après AWS
« Choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre »
D’après l’équipe AWS
Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on est d’avis que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.
En effet, cette étude sur les langages les plus voraces en énergie établit que le langage C offre les meilleures performances sur les axes de l’efficacité énergétique et de la performance d’exécution.
On en vient donc à se poser la question de savoir pourquoi tant de voix s’élèvent pour appeler à la venue d’un successeur au langage C. Il y a seulement que les rapports de chercheurs en sécurité s’enchaînent et ne cessent de mettre le doigt sur l’une des plus grosses tares que les langages C et C++ traînent : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE) abondent dans le même sens : 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.
Ryan Levick de Microsoft souligne ces détails dans le cadre de sa présentation et coupe court : « Quels que soient les investissements que les entreprises de la filière du développement de logiciels peuvent mettre sur pied, le fait est que C++ [C] n’est pas par essence un langage fait pour la mise sur pied d’applications sécurisées. » Alex Gaynor – un ex contributeur de l’équipe sécurité du navigateur Firefox – émet un avis similaire : « Le C++ moderne ne nous sauvera pas, car il est moins sécurisé que les nouveaux langages [Rust, Swift]). »
En 2012, Linus Torvalds a déclaré que « il n’y a rien de mieux que le langage C pour le développement de systèmes d’exploitation. » La sortie de Linus Torvalds était antérieure à la publication de la première version stable de Rust – le langage de programmation pressenti comme remplaçant du C sur le terrain du contrôle du hardware. En fait, au moment où Linus s’exprimait, Rust n’en était qu’au stade de l’enfance.
Depuis, son regard sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. »
Source : Amazon
Et vous ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
L'argument écologique... mouais
Tous les 5 ans on tourne la grande roue des langages de programmation.
Cette année c'est tombé sur Rust.
Un langage à la syntaxe hyper compliquée, qui est accessible uniquement pour les "déjà" développeurs.
Pourquoi les langages sont devenus aussi compliqués à installer et à utiliser ? Y a aucune raison pour cela.
Tu m'étonnes que les entreprises manquent de bons développeurs, s'il faut réapprendre un langage tous les 2 ans parce qu'il est devenu tendance.
C'est vrai que Rust n'est pas simple, mais reste plus simple que du C/C++ et encore bien plus si tu ajoutes les outils qui vont avec.
Pour moi qui vient du monde Java, je n'ai jamais réussi a vraiment comprendre la logique et toute la misère autour des templates,génériques,preprocessing de C/C++
mais Rust je n'ai pas eu de soucis, c'est tellement plus carré.
Pour dire vrai, c'est le seul language que je trouve supérieur à Java (j'inclus l'environnement).
J'ai commencé en Java 1.4 il y a quoi presque 15ans ? c'est mon premier vrai changement de language.
Faire un build, lancer des tests, gérer les dépendances, la génération de la doc, le déploiement... bonne chance avec cmake, ant ou autre.
l'outil Cargo est un petit bijou, et surtout tous les projets Rust sont dessus, c'est une sorte de Maven+++.
Bref ce n'est que mon avis, Rust est un bon cheval.
Répondre avec citation
Partager