Intéressant ce comparatif, cependant, le benchmark a été réalisé sur 10 petits problèmes (en 27 langages).
On sait maintenant que C est le plus véloce et le moins énergivore dans ce cas de figure (petits problèmes). Mais dans le cas d'un gros programme de plusieurs centaines de milliers de lignes, est-ce qu'il est toujours aussi performant ?
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Mais dans le cas d'un gros programme de plusieurs centaines de milliers de lignes, est-ce qu'il est toujours aussi performant ?
Oui.
Le C est tellement proche de l'implémentation machine qu'il sera toujours plus performant.
Par contre, un gros programme de 100k lignes de codes en C ne fera que 10k lignes de code en Python (exemple pris au hasard dans la liste), sera plus facilement maintenable, sera plus facile à écrire etc. Mais moins efficace sur la machine.
Pas de secret, soit l'humain se fait chier, et ça optimise (assembleur powa) soit il se fait moins chier, et tu crées des exécutables lourds et lents.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Posté par raphj .
Évalué à 4.
Dernière modification le 26 mars 2019 à 22:49.
Ce n'est probablement pas si simple.
Il se pourrait qu'un langage qui ne prenne pas en charge les pointeurs mais qui utilise les références (et un ramasse-miettes) batte C dans certains cas simplement parce que la gestion de la mémoire peut être plus efficace : les objets peuvent être bougés, l'utilisation mémoire compactée, les libérations de mémoires peuvent être regroupées. Aussi, l'existence des pointeurs empêchent certaines optimisations.
Sur des petites exécutions, là où un programme C bien écrit va en général libérer toutes les allocations faites, un ramasse-miette peut décider de laisser le système libérer la mémoire à la fin de l'exécution, ce qu'il fait de toute façon, sans le faire lui-même.
Une compilation à la volée peut également permettre d'appliquer certaines optimisations, potentiellement dépendantes des données à l'exécution, impossible à appliquer avec une compilation classique. Une compilation à la volée peut aussi prendre en compte les spécificités matérielles (architecture CPU spécifique par exemple), là où les programmes C sont souvent compilés pour un grand ensemble de machines.
Souvent sur des petites exécutions, une compilation à la volée est plus lente qu'une exécution native équivalente parce qu'il faut compiler ET exécuter sans optimisation spécifique. Je ne sais pas s'il y a des supports exécutifs qui enregistrent les résultats des compilations à la volée / les optimisations pour contrer ce problème.
Il se pourrait qu'un langage qui ne prenne pas en charge les pointeurs mais qui utilise les références (et un ramasse-miettes) batte C dans certains cas simplement parce que la gestion de la mémoire peut être plus efficace
Bin non. Le ramasse miette est là pour palier aux manquements du codeur, pas du langage. Il rajoute justement une gestion supplémentaire qui est moins efficace (puisque parfois il va déterminer qu'il ne faut rien libérer, il a donc tourné pour rien) pour que le codeur n'ait pas à penser "où dois-je allouer, ai-je bien penser à libérer" ? Mais c'est pas une optimisation de performances du tout.
Une compilation à la volée peut également permettre d'appliquer certaines optimisations, potentiellement dépendantes des données à l'exécution
Là je voudrais un exemple concret parce que réellement je vois pas. La compilation à la volée qui a un comportement dynamique… quel langage l'implémente ? Et surtout je veux un benchmark, parce que compiler à la volée, ça coûte.
Une compilation à la volée peut aussi prendre en compte les spécificités matérielles (architecture CPU spécifique par exemple), là où les programmes C sont souvent compilés pour un grand ensemble de machines.
Là aussi c'est un argument fallacieux : tu compares un truc mal fait en C avec un truc potentiellement mieux fait dans un autre langage, sans au final apporter un vrai benchmark ni un vrai exemple. On parle du langage lui-même, pas de la façon de l'utiliser.
Et si tu objectes que le C est plus difficile à optimiser, c'est exactement mon commentaire du début : pour optimiser du C, c'est à l'humain de se décarcasser, mais au final, c'est plus efficace.
Il faut bien comprendre ce qu'est le C : une simple surcouche de l'assembleur. Tous les concepts du C sont directement implémentés par le silicium. Les langages évolués apportent des concepts énormément plus pratiques (objet par exemple) pour le codeur, mais pas pour la machine.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Le C est tellement proche de l'implémentation machine qu'il sera toujours plus performant.
C'est indéniable en théorie, mais la pratique est tellement plus compliquée…
Les benchmarks dont on parle sont des petits problèmes purement algorithmiques : tri, recherche, inversion de matrices… Il semble assez évident que pour de tels problèmes, un assembleur optimisé sera mieux que C, qui sera mieux que C++, qui sera mieux que n'importe quel langage interprété.
Maintenant, dans la vraie vie, à quoi les CPU servent-ils? 99% du temps, à rien, et le reste, c'est quoi? Du jeu vidéo, de l'encodage/décodage de vidéo, du rendu dans les navigateurs, etc. Très souvent, ces choses sont plus ou moins optimisées, et le choix du langage est en général adapté (en tout cas, peu de jeux 3D sont codés en perl…).
Du coup, la vraie question, c'est si tu remplaces tous les scripts perl et python livrés avec ta distrib par des exécutables codés en C, tu vas gagner combien de temps et combien d'énergie? Ça sera sûrement assez négligeable.
Par contre, optimiser encore plus les algos les plus gourmands, ça peut être particulièrement efficace.
Le C est tellement proche de l'implémentation machine qu'il sera toujours plus performant.
Faux, l'assembleur est le plus proche.
Blague à part, un superbe example que c'est faux, c'est la différence de performance entre qsort et std::sort. Impossible également de retrouver le lien précis, mais il y a quelques années, GCC à commencé à autoriser le C++, pour se débarrasser du garbage collector qu'ils avaient dû implémenter à cause du manque de RAII en C.
J'ai regardé rapidement (j'ai du taf, je voulais juste me distraire vite fait) un des examples de code en C++, et un autre en C. Celui en C++ utilise std::cout, celui en C utilise printf.
Rien n'empêche d'utiliser std::printf en C++ (personnellement, c'est ce que je fais, même si je m'emmerde pas avec le namespace) qui est plus lisible (à mes yeux, en tout cas, parce que je trouve les doubles chevrons imbuvables) et si ma mémoire est bonne plus rapide, surtout si l'on fait l'erreur d'utiliser std::endl (toujours de mémoire, c'est super lent comparé à '\n'). Le fait qu'il soit plus léger en mémoire reste à prouver, mais j'en suis persuadé (!= convaincu) du fait qu'il me semble que ça puisse lancer des exceptions (le code est p'tet mort, mais il est là quand même).
À noter que printf n'est spécialement un truc léger non plus, d'ailleurs.
Perso, je dirais que C++ est plus performant que C sur de gros projets, si on se limite à un certain nombre de fonctionnalités, ce que devraient faire à mon avis tous les projets, et je ne suis pas le seul à penser qu'il faut sélection un jeu de fonctionnalités et s'y tenir. Certains bannissent les exceptions, d'autres les templates, d'autres l'héritage multiple, d'autres les méthodes virtuelles…
La raison pour laquelle C++ serait plus efficace que C sur de gros projets est qu'il ne nécessite pas de gérer les ressources (la mémoire, les accès fichiers, les entités opengl, les accès aux bases de données, etc) à la main, ce qui fait que les ressources sont libérées dès qu'il n'y en a plus besoin.
Le gain en performance pour moi de ce côté est: moins de bugs, moins de mémoire consommée à instant T.
Les templates eux permettent, comme pour std::sort vs qsort, un gain de vitesse lié à la réduction des callbacks.
Par contre, mal utiliser des fonctionnalités de C++ peut être très punitif en matière de performance: utiliser std::map, std::set ou std::list pour stocker des petits objets (de taille inférieure à un pointeur, par exemple), utiliser std::vector sans réserver la mémoire avant de faire une boucle de push_back est aussi une erreur que je vois régulièrement et qui est potentiellement très punitive.
De manière générale, je trouve la STL difficile à utiliser efficacement, en fait, et je trouve qu'elle déroge quand même pas mal au fameux "you pay for what you use" de C++: après tout, dès lors que l'on utilise la STL, on est obligé d'utiliser les exceptions, qui ne sont pas vraiment légères en terme de code (certes qui n'est exécuté qu'exceptionnellement, mais il est bien présent dans le binaire, ce qui compte parfois).
D'ailleurs, sur ce sujet, EA games avait implémenté la sienne notamment parce que gérer la mémoire avec la STL n'est pas vraiment simple.
Posté par gUI (Mastodon) .
Évalué à 3.
Dernière modification le 27 mars 2019 à 12:02.
Faux, l'assembleur est le plus proche.
Oui et l'assembleur aura des performances encore meilleures, pour la même raison (mais il est pas dans la liste :) ).
Le C étant considéré comme un "assembleur portable", il y a très peu de surcoût au C. C'est l'avantage du C, mais aussi son inconvénient (pour être performant, il faut coder en connaissant le hardware).
Mais je ne vois toujours pas d'exemple où un code bien écrit en C est moins performant qu'un code bien écrit en C++/Java/Python.
un superbe example que c'est faux, c'est la différence de performance entre qsort et std::sort
Bin je comprends pas trop, le mec trouve justement que le C est plus performant :
C quick-sort time elapsed: 0.061
C++ quick-sort time elapsed: 0.086
Et après ça parle de "inline". Si c'est ça la raison, il suffit de l'ajouter dans son code source C. Dis autrement, je ne vois pas ce que le C++ pourrait faire que le C ne fait pas. Il n'y a pas d'instructions assembleur magique qui sortiront en C++ et pas en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Et après ça parle de "inline". Si c'est ça la raison, il suffit de l'ajouter dans son code source C. Dis autrement, je ne vois pas ce que le C++ pourrait faire que le C ne fait pas. Il n'y a pas d'instructions assembleur magique qui sortiront en C++ et pas en C.
L'avantage du C++ n'est pas dans l'assembleur généré, mais il permet d'exprimer des algorithmes plus complexes plus simplement qu'en C. Sans compter que la bibliothèque standard étant plus large, avec des fonctions très optimisées et souples comme ceux pour la manipulation de chaînes de caractères. Du coup ton programme en C++ fera probablement usage de code ou d'algorithmes plus optimisés que si tu devais l'implémenter à la main. Et le tout avec probablement moins de bogues.
Du coup oui, si tu as beaucoup de temps, et que tu es vraiment bon pour pondre le design idéal à chaque fois, coder en C est plus efficient oui. Mais sinon, ce n'est pas improbable que le C++ (voire un langage plus haut niveau encore) fasse mieux que le C grâce à cela.
Posté par gUI (Mastodon) .
Évalué à 2.
Dernière modification le 27 mars 2019 à 13:45.
Du coup oui, si tu as beaucoup de temps, et que tu es vraiment bon pour pondre le design idéal à chaque fois, coder en C est plus efficient oui
On est d'accord, je ne dis rien d'autre que ça. J'ai dis à plusieurs reprises que l'inconvénient du C est que pour accéder à l'optimisation, il faut un bon niveau, une bonne connaissance du hardware etc.
C'est d'ailleurs pour ça qu'il est assez régulier de voir un programme codé en langage XYZ, puis une petite routine qui est critique niveau temps d'exécution codée en C (et aussi en ASM, ça se voit encore) pour être parfaitement optimisée (et appelée souvent etc.)
Mais je ne comprends pas les arguments qui tendent à dire qu'un langage quelconque, avec une fonctionnalité quelconque (JIT, ramasse miette, …) pourrait être foncièrement plus rapide que le C, car au pire, tu implémentes cette fonction si astucieuse en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Le truc c'est que si tu essaie d'écrire du C avec un ramasse miettes, tu vas avoir du code super compliqué.
En Java, on peut déplacer un objet dans la mémoire pour la défragmenter. Comme le langage n'utilise pas la notion de pointeur, mais des références qui sont suivies par l'interpréteur, ça ne pose pas souci.
En C, tu peux avoir des pointeurs qui sont stockés dans des variables locales sur la pile, dans des registres, dans des variables globales, et il n'y a aucun suivi pour savoir ou on en est. Du coup, pour déplacer un objet, bon courage.
Alors, tu peux toujours essayer de ne jamais utiliser directement de pointeur dans ton code C pour ne pas avoir ce problème, mais ton code va être bien moche et illisible et je suis même pas certain que tu puisses arriver à t'assurer que le compilateur ne décide pas de mettre un pointeur quelque part de façon temporaire.
En C++, tu as peut-être moyen de t'en sortir avec un objet qui masque ton pointeur. En Java, tu n'as rien à faire.
Du coup, si on en revient au point de vue écologique, il faut compter certes le temps d'exécution du programme, mais aussi le temps de développement (ce sont aussi des ordinateurs qui fonctionnent…), à corriger les bugs et redéployer des binaires, etc. Et là, le C va vite perdre des points.
# En image
Posté par Anonyme . Évalué à 6.
[^] # Re: En image
Posté par ZeroHeure . Évalué à 5.
C'est fou de voir Pascal aussi bien placé et aussi peu utilisé
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Quid sur de gros programmes ?
Posté par Nibel . Évalué à 4.
Intéressant ce comparatif, cependant, le benchmark a été réalisé sur 10 petits problèmes (en 27 langages).
On sait maintenant que C est le plus véloce et le moins énergivore dans ce cas de figure (petits problèmes). Mais dans le cas d'un gros programme de plusieurs centaines de milliers de lignes, est-ce qu'il est toujours aussi performant ?
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . Évalué à 3.
Oui.
Le C est tellement proche de l'implémentation machine qu'il sera toujours plus performant.
Par contre, un gros programme de 100k lignes de codes en C ne fera que 10k lignes de code en Python (exemple pris au hasard dans la liste), sera plus facilement maintenable, sera plus facile à écrire etc. Mais moins efficace sur la machine.
Pas de secret, soit l'humain se fait chier, et ça optimise (assembleur powa) soit il se fait moins chier, et tu crées des exécutables lourds et lents.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par raphj . Évalué à 4. Dernière modification le 26 mars 2019 à 22:49.
Ce n'est probablement pas si simple.
Il se pourrait qu'un langage qui ne prenne pas en charge les pointeurs mais qui utilise les références (et un ramasse-miettes) batte C dans certains cas simplement parce que la gestion de la mémoire peut être plus efficace : les objets peuvent être bougés, l'utilisation mémoire compactée, les libérations de mémoires peuvent être regroupées. Aussi, l'existence des pointeurs empêchent certaines optimisations.
Sur des petites exécutions, là où un programme C bien écrit va en général libérer toutes les allocations faites, un ramasse-miette peut décider de laisser le système libérer la mémoire à la fin de l'exécution, ce qu'il fait de toute façon, sans le faire lui-même.
Une compilation à la volée peut également permettre d'appliquer certaines optimisations, potentiellement dépendantes des données à l'exécution, impossible à appliquer avec une compilation classique. Une compilation à la volée peut aussi prendre en compte les spécificités matérielles (architecture CPU spécifique par exemple), là où les programmes C sont souvent compilés pour un grand ensemble de machines.
Souvent sur des petites exécutions, une compilation à la volée est plus lente qu'une exécution native équivalente parce qu'il faut compiler ET exécuter sans optimisation spécifique. Je ne sais pas s'il y a des supports exécutifs qui enregistrent les résultats des compilations à la volée / les optimisations pour contrer ce problème.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . Évalué à 7.
Bin non. Le ramasse miette est là pour palier aux manquements du codeur, pas du langage. Il rajoute justement une gestion supplémentaire qui est moins efficace (puisque parfois il va déterminer qu'il ne faut rien libérer, il a donc tourné pour rien) pour que le codeur n'ait pas à penser "où dois-je allouer, ai-je bien penser à libérer" ? Mais c'est pas une optimisation de performances du tout.
Là je voudrais un exemple concret parce que réellement je vois pas. La compilation à la volée qui a un comportement dynamique… quel langage l'implémente ? Et surtout je veux un benchmark, parce que compiler à la volée, ça coûte.
Là aussi c'est un argument fallacieux : tu compares un truc mal fait en C avec un truc potentiellement mieux fait dans un autre langage, sans au final apporter un vrai benchmark ni un vrai exemple. On parle du langage lui-même, pas de la façon de l'utiliser.
Et si tu objectes que le C est plus difficile à optimiser, c'est exactement mon commentaire du début : pour optimiser du C, c'est à l'humain de se décarcasser, mais au final, c'est plus efficace.
Il faut bien comprendre ce qu'est le C : une simple surcouche de l'assembleur. Tous les concepts du C sont directement implémentés par le silicium. Les langages évolués apportent des concepts énormément plus pratiques (objet par exemple) pour le codeur, mais pas pour la machine.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par arnaudus . Évalué à 2.
C'est indéniable en théorie, mais la pratique est tellement plus compliquée…
Les benchmarks dont on parle sont des petits problèmes purement algorithmiques : tri, recherche, inversion de matrices… Il semble assez évident que pour de tels problèmes, un assembleur optimisé sera mieux que C, qui sera mieux que C++, qui sera mieux que n'importe quel langage interprété.
Maintenant, dans la vraie vie, à quoi les CPU servent-ils? 99% du temps, à rien, et le reste, c'est quoi? Du jeu vidéo, de l'encodage/décodage de vidéo, du rendu dans les navigateurs, etc. Très souvent, ces choses sont plus ou moins optimisées, et le choix du langage est en général adapté (en tout cas, peu de jeux 3D sont codés en perl…).
Du coup, la vraie question, c'est si tu remplaces tous les scripts perl et python livrés avec ta distrib par des exécutables codés en C, tu vas gagner combien de temps et combien d'énergie? Ça sera sûrement assez négligeable.
Par contre, optimiser encore plus les algos les plus gourmands, ça peut être particulièrement efficace.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . Évalué à 3.
Tu as raison. J'attends donc avec impatience de voir un seul gros projet qui annonce avoir quitté une implémentation en C pour des raisons de perfo.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par freem . Évalué à 4.
Faux, l'assembleur est le plus proche.
Blague à part, un superbe example que c'est faux, c'est la différence de performance entre qsort et std::sort. Impossible également de retrouver le lien précis, mais il y a quelques années, GCC à commencé à autoriser le C++, pour se débarrasser du garbage collector qu'ils avaient dû implémenter à cause du manque de RAII en C.
J'ai regardé rapidement (j'ai du taf, je voulais juste me distraire vite fait) un des examples de code en C++, et un autre en C. Celui en C++ utilise std::cout, celui en C utilise printf.
Rien n'empêche d'utiliser std::printf en C++ (personnellement, c'est ce que je fais, même si je m'emmerde pas avec le namespace) qui est plus lisible (à mes yeux, en tout cas, parce que je trouve les doubles chevrons imbuvables) et si ma mémoire est bonne plus rapide, surtout si l'on fait l'erreur d'utiliser std::endl (toujours de mémoire, c'est super lent comparé à '\n'). Le fait qu'il soit plus léger en mémoire reste à prouver, mais j'en suis persuadé (!= convaincu) du fait qu'il me semble que ça puisse lancer des exceptions (le code est p'tet mort, mais il est là quand même).
À noter que printf n'est spécialement un truc léger non plus, d'ailleurs.
Perso, je dirais que C++ est plus performant que C sur de gros projets, si on se limite à un certain nombre de fonctionnalités, ce que devraient faire à mon avis tous les projets, et je ne suis pas le seul à penser qu'il faut sélection un jeu de fonctionnalités et s'y tenir. Certains bannissent les exceptions, d'autres les templates, d'autres l'héritage multiple, d'autres les méthodes virtuelles…
La raison pour laquelle C++ serait plus efficace que C sur de gros projets est qu'il ne nécessite pas de gérer les ressources (la mémoire, les accès fichiers, les entités opengl, les accès aux bases de données, etc) à la main, ce qui fait que les ressources sont libérées dès qu'il n'y en a plus besoin.
Le gain en performance pour moi de ce côté est: moins de bugs, moins de mémoire consommée à instant T.
Les templates eux permettent, comme pour std::sort vs qsort, un gain de vitesse lié à la réduction des callbacks.
Par contre, mal utiliser des fonctionnalités de C++ peut être très punitif en matière de performance: utiliser std::map, std::set ou std::list pour stocker des petits objets (de taille inférieure à un pointeur, par exemple), utiliser std::vector sans réserver la mémoire avant de faire une boucle de push_back est aussi une erreur que je vois régulièrement et qui est potentiellement très punitive.
De manière générale, je trouve la STL difficile à utiliser efficacement, en fait, et je trouve qu'elle déroge quand même pas mal au fameux "you pay for what you use" de C++: après tout, dès lors que l'on utilise la STL, on est obligé d'utiliser les exceptions, qui ne sont pas vraiment légères en terme de code (certes qui n'est exécuté qu'exceptionnellement, mais il est bien présent dans le binaire, ce qui compte parfois).
D'ailleurs, sur ce sujet, EA games avait implémenté la sienne notamment parce que gérer la mémoire avec la STL n'est pas vraiment simple.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 27 mars 2019 à 12:02.
Oui et l'assembleur aura des performances encore meilleures, pour la même raison (mais il est pas dans la liste :) ).
Le C étant considéré comme un "assembleur portable", il y a très peu de surcoût au C. C'est l'avantage du C, mais aussi son inconvénient (pour être performant, il faut coder en connaissant le hardware).
Mais je ne vois toujours pas d'exemple où un code bien écrit en C est moins performant qu'un code bien écrit en C++/Java/Python.
Bin je comprends pas trop, le mec trouve justement que le C est plus performant :
Et après ça parle de "inline". Si c'est ça la raison, il suffit de l'ajouter dans son code source C. Dis autrement, je ne vois pas ce que le C++ pourrait faire que le C ne fait pas. Il n'y a pas d'instructions assembleur magique qui sortiront en C++ et pas en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par Renault (site web personnel) . Évalué à 3.
L'avantage du C++ n'est pas dans l'assembleur généré, mais il permet d'exprimer des algorithmes plus complexes plus simplement qu'en C. Sans compter que la bibliothèque standard étant plus large, avec des fonctions très optimisées et souples comme ceux pour la manipulation de chaînes de caractères. Du coup ton programme en C++ fera probablement usage de code ou d'algorithmes plus optimisés que si tu devais l'implémenter à la main. Et le tout avec probablement moins de bogues.
Du coup oui, si tu as beaucoup de temps, et que tu es vraiment bon pour pondre le design idéal à chaque fois, coder en C est plus efficient oui. Mais sinon, ce n'est pas improbable que le C++ (voire un langage plus haut niveau encore) fasse mieux que le C grâce à cela.
[^] # Re: Quid sur de gros programmes ?
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 27 mars 2019 à 13:45.
On est d'accord, je ne dis rien d'autre que ça. J'ai dis à plusieurs reprises que l'inconvénient du C est que pour accéder à l'optimisation, il faut un bon niveau, une bonne connaissance du hardware etc.
C'est d'ailleurs pour ça qu'il est assez régulier de voir un programme codé en langage XYZ, puis une petite routine qui est critique niveau temps d'exécution codée en C (et aussi en ASM, ça se voit encore) pour être parfaitement optimisée (et appelée souvent etc.)
Mais je ne comprends pas les arguments qui tendent à dire qu'un langage quelconque, avec une fonctionnalité quelconque (JIT, ramasse miette, …) pourrait être foncièrement plus rapide que le C, car au pire, tu implémentes cette fonction si astucieuse en C.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quid sur de gros programmes ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Le truc c'est que si tu essaie d'écrire du C avec un ramasse miettes, tu vas avoir du code super compliqué.
En Java, on peut déplacer un objet dans la mémoire pour la défragmenter. Comme le langage n'utilise pas la notion de pointeur, mais des références qui sont suivies par l'interpréteur, ça ne pose pas souci.
En C, tu peux avoir des pointeurs qui sont stockés dans des variables locales sur la pile, dans des registres, dans des variables globales, et il n'y a aucun suivi pour savoir ou on en est. Du coup, pour déplacer un objet, bon courage.
Alors, tu peux toujours essayer de ne jamais utiliser directement de pointeur dans ton code C pour ne pas avoir ce problème, mais ton code va être bien moche et illisible et je suis même pas certain que tu puisses arriver à t'assurer que le compilateur ne décide pas de mettre un pointeur quelque part de façon temporaire.
En C++, tu as peut-être moyen de t'en sortir avec un objet qui masque ton pointeur. En Java, tu n'as rien à faire.
Du coup, si on en revient au point de vue écologique, il faut compter certes le temps d'exécution du programme, mais aussi le temps de développement (ce sont aussi des ordinateurs qui fonctionnent…), à corriger les bugs et redéployer des binaires, etc. Et là, le C va vite perdre des points.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.