Bon allez, je re réponds à ça et puis je vais m'arrêter là.
C'est à peu de chose la référence pour les logiciels libres.
D'accord mais n'en rajoutons pas. Ça a l'air surtout utilisé par des compilateurs/interpréteurs (Java,Scheme,C# notamment mono), ce qui est quand même quelque chose de particulier. Mozilla l'utilise certes mais comme détecteur de fuites, pas comme garbage collector. Reste que l'écrasante majorité des logiciels écrits en C++ sont codés avec une gestion manuelle de la mémoire.
Il est juste pas content parce qu'il dit « pas de gc en C » et que je lui prouve que c'est trivialement faux
Bravo pour la citation fausse citation. Je n'ai jamais écrit « pas de gc en C », ni même quelquechose de sémantiquement équivalent, inutile donc d'employer les guillemets. J'ai simplement prétendu que le C++ me forçait à gérer la mémoire à la main, ce qui est vrai. Il n'y a pas de garbage collector dans les bibliothèques C++ répandues et ce n'est pas quelquechose de courant d'utiliser un GC. Bref, je dois gérer ma mémoire à la main en C++.
D'autre part, on va pas jouer au plus malin C est Turing complet, donc évident qu'on peut implémenter n'importe quoi en C, y compris un garbage collector.
Je lui dis que les bench. de 6 secondes cela ne représente rien parce que le GC ne libère jamais rien. Il répond en résumé, il suffit d'utiliser -Xms. Il me parle de pool et prétend que j'ai décris le fonctionnement d'un GC parce que j'ai parlé de simuler, en C, ce que fait réellement le gc dans les bench de 6s : il alloue un pool et incrémente un pointeur c'est tout, jamais le moindre gc qui passe.
Non.
Tu as prétendu qu'il fallait mettre les pointeurs à null pour que la mémoire soit désallouée quand on utilisait un GC. C'est faux. Exécution de 6 secondes ou pas. C'est le cœur de mon argument.
Tu as confondu temps d'exécution et occupation mémoire. C'est n'importe quoi et je l'ai relevé.
La remarque sur -Xms était une remarque à côté, en aucun cas mon argument principal.
Donc, en résumé, non et re-non, jusqu'à preuve du contraire, aucun GC ne bat ni se rapproche des performances d'une (dés-)allocation manuelle. L'emballement se fait sur la durée pas sur du microbench.
Ah. Bon, on va finalement être d'accord. Effectivement (à l'heure actuelle), une gestion manuelle de la mémoire est plus performante qu'une gestion via un GC (d'ailleurs je n'ai pas vraiment prétendu le contraire mais passons). Mon point est simplement qu'en dehors de cas où on veut avoir le maximum de performance, la gestion par un garbage collector offrait des performances suffisantes. On parlait d'une application graphique à la base, pas d'un serveur daemon ultra optimisé ni d'un application de calcul intensif.
Bon et pour ton « emballement », va falloir préciser de quoi tu parles et donner des preuves. La mémoire n'est pas désallouée ? Le GC bouffre trop de temps CPU ?
[^] # Re: la réponse est évidente
Posté par X345 . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 3.
Bon allez, je re réponds à ça et puis je vais m'arrêter là.
D'accord mais n'en rajoutons pas. Ça a l'air surtout utilisé par des compilateurs/interpréteurs (Java,Scheme,C# notamment mono), ce qui est quand même quelque chose de particulier. Mozilla l'utilise certes mais comme détecteur de fuites, pas comme garbage collector. Reste que l'écrasante majorité des logiciels écrits en C++ sont codés avec une gestion manuelle de la mémoire.
Bravo pour la citation fausse citation. Je n'ai jamais écrit « pas de gc en C », ni même quelquechose de sémantiquement équivalent, inutile donc d'employer les guillemets. J'ai simplement prétendu que le C++ me forçait à gérer la mémoire à la main, ce qui est vrai. Il n'y a pas de garbage collector dans les bibliothèques C++ répandues et ce n'est pas quelquechose de courant d'utiliser un GC. Bref, je dois gérer ma mémoire à la main en C++.
D'autre part, on va pas jouer au plus malin C est Turing complet, donc évident qu'on peut implémenter n'importe quoi en C, y compris un garbage collector.
Non.
Ah. Bon, on va finalement être d'accord. Effectivement (à l'heure actuelle), une gestion manuelle de la mémoire est plus performante qu'une gestion via un GC (d'ailleurs je n'ai pas vraiment prétendu le contraire mais passons). Mon point est simplement qu'en dehors de cas où on veut avoir le maximum de performance, la gestion par un garbage collector offrait des performances suffisantes. On parlait d'une application graphique à la base, pas d'un serveur daemon ultra optimisé ni d'un application de calcul intensif.
Bon et pour ton « emballement », va falloir préciser de quoi tu parles et donner des preuves. La mémoire n'est pas désallouée ? Le GC bouffre trop de temps CPU ?