Discussion :

[white_tentacle]

Normalement, le GC demande au système des pools mémoire et les gère lui-même. Il ne fera donc pas plusieurs appels à free comme tu sembles le penser.

De plus, si le GC est bien foutu, il inclue des optimisation pour la désallocation de masse, ce que tu ne peux pas faire via des appels successifs à free.

Sauf à utiliser un small object allocator. C'est pour ça que je dis que généralement, les benchs qui donnent le GC gagnant le font sur des codes qui, justement, nécessiteraient l'emploi d'un tel allocateur.

Par contre, Frank a effectivement raison sur le point de la fragmentation mémoire (encore que les os récents (au moins les kernels linux récents) supportant la défragmentation de la mémoire, je serais curieux de voir ce qu'il en est maintenant).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Program 	Compile 			Compile Time 	Run 				Run Time
D wc 		gdc -O2 -frelease -o wc wc.d 	0.326 		wc alice30.txt > /dev/null 	0.041
D wc 		dmd wc -O -release 		0.235 		wc alice30.txt > /dev/null 	0.041
C++ wccpp1 	g++ -O2 -o wccpp1 wccpp1.cc 	2.874 		wccpp1 alice30.txt > /dev/null 	0.086
C++ wccpp2 	g++ -O2 -o wccpp2 wccpp2.cc 	2.886 		wccpp2 alice30.txt > /dev/null 	0.095

Tu as les codes sur la page. Il n'y a franchement pas d'aberrations dans el code C++ (il y en a deux versions).

L'option de compile release en D permet d'obtenir un exécutable non managé (pas de runtime check). On peut donc se prendre un seg fault dans les dents mais on tourne à pleine vitesse.

J'ai pas trouvé wccpp1. Par contre, wccpp2 est une vaste plaisanterie : il parcourt deux fois le buffer, 1 fois pour compter les lignes, une autre fois pour compter les mots. C'est fou, c'est plus long que le programme D qui ne fait qu'un seul parcours .

[deadalnix]

C'est pas supposé être deux fois plus long. Tu parcours deux fois le machin, mais tu fais deux fois moins d'opération à chaque fois.

Normalement tu es pas supposé te retrouver avec un truc plus de deux fois plus long.

[Mac LAK]

Tiens, juste un point de remarque :

Avec un GC, la mémoire aurait pû être dégramentée et libérée plus tôt.
Bien sûr dans ce cas, j'ai écrit l'appli pour illustrer le phénomène. Mais j'ai des applis en production, qui bien que parfaitement écrites (enfin au niveau mémoire) sans memory leak consomme jusqu'à trois fois plus de mémoire que ce quelles utilisent réellement (si on compare la mémoire allouée auprès du gestionnaire de mémoire, à celle allouée auprès de l'OS).

C'est pour réduire ce phénomène que l'on peut utiliser, sous Windows, les tas privés... La destruction d'un tas libère, bien sûr, l'intégralité des pointeurs alloués dessus d'un seul coup (attention, les pointeurs deviennent alors invalides bien entendu, ils ne passent pas magiquement à NULL / Nil).

On garde donc le tas par défaut pour les données cruciales de l'application (qui doivent perdurer toute la vie de l'application), et des tas privés pour les machins infects qui fragmentent à tout va OU pour récupérer brutalement et rapidement de la mémoire, en évitant des libérations massives en chaîne.

Cela permet de résoudre le cas que tu cites, en tout cas.

[spidermario]

C'est pas supposé être deux fois plus long. Tu parcours deux fois le machin, mais tu fais deux fois moins d'opération à chaque fois.

Normalement tu es pas supposé te retrouver avec un truc plus de deux fois plus long.

En une fois, à chaque itération :

• Comparaison
• Comparaison
• Incrémentation

En deux fois :

• Comparaison
• Incrémentation

Le faire en une fois résulte en moins d'opérations puisque l'incrémentation se fait n fois où n est la longueur de la chaîne, contre 2*n.

La différence n'est peut-être pas énorme, mais elle existe

[white_tentacle]

Tu as les codes sur la page. Il n'y a franchement pas d'aberrations dans el code C++ (il y en a deux versions).

Oh, j'oubliais, mais passer par un istreabuf_iterator pour tout copier dans un vector de char, c'est une belle aberration .

C'est pénible, mais les benchs faits par les éditeurs de langage, j'en ai jamais vu de corrects...

[deadalnix]

Le faire en une fois résulte en moins d'opérations puisque l'incrémentation se fait n fois où n est la longueur de la chaîne, contre 2*n.

La différence n'est peut-être pas énorme, mais elle existe

Bien sur. Cela explique que le programme wccpp2 soit plus long. Cela n'explique cependant pas un tel retard. Il semble que le lien wccpp1 soit mort :/ c'est dommage.

[spidermario]

Bien sur. Cela explique que le programme wccpp2 soit plus long. Cela n'explique cependant pas un tel retard.

Et la réponse de white_tentacle ?

[Jack Sparrow]

Le problème de la libération de la mémoire en C++ est un faux problème. Le vrai problème, c'est que les programmeurs codent sans réfléchir à la durée de vie de leurs objets. Les langages avec ramasse-miette permettent effectivement cela. C++, non. En C++, il faut réfléchir à la durée de vie de ses objets, et à la responsabilité des objets (ie, qui tient la ressource).

A quand un débat sur le garbage collector où on suppose que les développeurs ne sont pas complètement nases et ignorants ?

Car oui, face à de mauvais programmeurs, n'importe quel langage a des inconvénients décuplés. A partir de là, on peut un peu tout dire.

[white_tentacle]

A quand un débat sur le garbage collector où on suppose que les développeurs ne sont pas complètement nases et ignorants ?

Je crois que le message de Frank correspond bien à ça.

Car oui, face à de mauvais programmeurs, n'importe quel langage a des inconvénients décuplés. A partir de là, on peut un peu tout dire.

Comme dire que c++ ne sert qu'à faire des programmes troués de partout, qui fuient de la mémoire et font des buffer overflow tout le temps .

[Invité]

C'est pas supposé être deux fois plus long. Tu parcours deux fois le machin, mais tu fais deux fois moins d'opération à chaque fois.

Bah justement, si le nombre de mots à compter est grand, on devient memory-bound très vite et ce raisonnement ne tient plus vraiment. Il est donc normal que le programme qui parcoure une seule fois une zone mémoire aille à peu près 2x plus vite que celui qui la parcoure deux fois. Une partie des opérations elle-même devient "gratuite" du coup. Enfin, c'est un benchmark un peu publicitaire quoi...

Sinon deadalnix quand tu dis que le GC fait des pools automatiquement selon le type d'objet, tu l'as constaté avec quels GC ? Ca à l'air intéressant.

[el_slapper]

A quand un débat sur le garbage collector où on suppose que les développeurs ne sont pas complètement nases et ignorants ?

Car oui, face à de mauvais programmeurs, n'importe quel langage a des inconvénients décuplés. A partir de là, on peut un peu tout dire.

Et moi je vais jouer l'avocat du diable.

Parce que des incompétents, il y en a 30% dans tous les métiers. Le développement ne fait pas exception à la règle. Et on peut toujours être suivi par un incompétent, voire, l'être soi-même par moments(je l'ai parfois été, et je suppose que chacun dans ce thread l'a été au moins une fois).

La question, je la retournerais : comment programmer pour que même une huitre ne sabote pas tout? Quel langage est assez solide pour résister à des tanches, tout en étant assez puissant pour permettre des architectures évolutives et adaptées? Je n'ai pas la réponse. Mais il me semble que C/C++, sans GC ni aucun filet, pardonne beaucoup moins que C# avec son GC. Et que, donc, dans un environnement professionnel vaste, avec plein de gens qui vont repasser sur le code, sans tous être des spécialiste, n'est pas forcément un choix optimal.

Après, ça dépend, comme toujours, de ce que l'on fait. Pour de l'embarqué, la question ne se pose même pas : on alloue tout au début, et c'est tout, ça se dés-alloue quand on appuie sur OFF..... GC ou pas, ça ne change pas grand chose. Inversement, pour une appli de gestion lourde, spécialement en transactionnel, le choix est fondamental. Perso, je serais partisan du GC, tout simplement parce que la perfection n'est pas de ce monde. Et qu'il suffit d'un stagiaire peu au fait de ces problématiques spécifiques, ou d'un ancien reconverti en vitesse à ce nouveau langage, pour que la catastrophe advienne. Évidemment, si on a le budget pour une triple revue de chaque code, on peut chercher la perfection, mais est-ce fréquent?

[Jack Sparrow]

Parce que des incompétents, il y en a 30% dans tous les métiers. Le développement ne fait pas exception à la règle. Et on peut toujours être suivi par un incompétent, voire, l'être soi-même par moments(je l'ai parfois été, et je suppose que chacun dans ce thread l'a été au moins une fois).

Je ne dis pas que le débat n'est pas intéressant. Mais j'aurai tendance à penser que ce sont, au fond, 2 débats différents (ou il faut séparer les 2 cas)

[Invité]

Perso le GC a pas mal changé ma manière de programmer (j'espère pour le mieux).

Avant j'essayais d'éviter les problème d'ownership compliqués en mettant clairement un "propriétaire" ou un manager en charge de la destruction.

Maintenant, un objet qui a besoin de quelque chose le référence (directement ou pas), que ca soit de la mémoire, une librarie, ou une ressource quelconque. Les seuls problème proviennent d'une destruction qui n'a pas eu lieu dans le bon ordre, donc d'une dépendance qu'on a oubliée. Ca ressemble à écrire un makefile

Ce qu'il ne faut pas oublier c'est que les solutions comme les smart pointers C++ ne permettent pas de faire des cycles, ce qui fait que les problèmes de fuites mémoires et d'ownership ne sont pas complètement réglés. Et des questions se posent comme : "Quel smart pointer vais-je mettre à NULL dans cette structure compliquée pour qu'elle soit effectivement libérée ?".

C'est peut-être pas toujours adéquat ou efficace, mais je ne pense pas que ça conduise à du bloat. On peut sortir de ce schéma quand on veux.

[jabbounet]

Ce qu'il ne faut pas oublier c'est que les solutions comme les smart pointers C++ ne permettent pas de faire des cycles, ce qui fait que les problèmes de fuites mémoires et d'ownership ne sont pas complètement réglés. Et des questions se posent comme : "Quel smart pointer vais-je mettre à NULL dans cette structure compliquée pour qu'elle soit effectivement libérée ?".

Au risque de lancer un autre débat, mon opinion et que au moins 80%, (dans l'ideal 100%) des problèmes doivent être réglé lors des phases spécifications/conception.

j'ai trop souvent vu des objets super compliqué pour résoudre des problèmes simples parceque que les gens qui avait fait l'évolution de l'application ne s'était pas suffisamment réuni autour d'une table pour discuter du problème avant de pondre leur code.

[deadalnix]

Sinon deadalnix quand tu dis que le GC fait des pools automatiquement selon le type d'objet, tu l'as constaté avec quels GC ? Ca à l'air intéressant.

Le GC de D ne le fait pas, mais celui de java le fait par exemple.

[Invité]

La question, je la retournerais : comment programmer pour que même une huitre ne sabote pas tout? Quel langage est assez solide pour résister à des tanches, tout en étant assez puissant pour permettre des architectures évolutives et adaptées?

Le meilleur moyen, c'est de ne pas embaucher la personne, de la virer quand elle commence à devenir nuisible, ou, s'il ne s'agit que d'un état transitoire (on a tous été "apprenants" à un moment) de ne pas lui confier des tâches où elle risque de faire des dégats. C'est un problème de management, pas de technique.

Choisir un environnement de développement pour pallier les lacunes d'une politique d'embauche, ça ne me parait pas très bon signe pour l'entreprise...

Mais c'est malheureusement une tendance lourde : au fil des années, on fait davantage évoluer les langages pour les protéger des mauvais informaticiens que pour servir les besoins des bons.

Je pense qu'il y a des arguments en faveur des GC. En particulier, l'idée que dans un grand nombre de cas, la gestion de la mémoire n'est pas un problème crucial, et qu'un système automatique, même imparfait, fait gagner suffisament de temps de développement pour en valoir la peine.

L'idée qu'ils protègent des mauvais informaticiens ne me parait pas très bonne (d'autant plus qu'un vrai mauvais, c'est capable de planter n'importe quoi!)

Francois

[deadalnix]

Choisir un environnement de développement pour pallier les lacunes d'une politique d'embauche, ça ne me parait pas très bon signe pour l'entreprise...

Et pourtant, on est en plein de dedans. Le concept est simple :
1/ En langage managé, un incompétent va te faire un blob lourd et peu réactif.
2/ En langage non managé, ça ne va tout simplement pas marcher.

Et la, tu as comprit le succès de C#, java ou autres.

Maintenant, ce n'est pas forcement idiot : un programmeur moins compétant, on peut le payer moins cher, le former plus vite, et si les commerciaux arrivent à vendre le truc, il n'y a pas de raisons de s'en priver.

Bien sur, éthiquement, je n'adhère pas mais d'un point de vue 100% business, ça se tiens très bien.

Alors attention, de mon point de vue, tous les codes non critiques devraient être fait en langage managé. Tout simplement parce que même un bon programmeur fait des erreurs.

Souvent, c'est moins de 10% du code dans lequel passe plus de 90% de temps. Seuls ces 10% de code devraient être en natif. Pour le reste, c'est juste une prise de risque inutile.

Un langage managé ne dispense pas un programmeur de savoir ce qu'il fait (afin d'éviter de terminer avec un blob horriblement lourd) mais au moins, ça apporte un sécurité. Ce n'est pas parce qu'on conduit bien qu'on devrait le faire sans ceinture, et enlever l'airbag de sa voiture.

[Invité]

Maintenant, ce n'est pas forcement idiot : un programmeur moins compétant, on peut le payer moins cher, le former plus vite, et si les commerciaux arrivent à vendre le truc, il n'y a pas de raisons de s'en priver.

Je ne suis pas certain que ce soit vrai. Un programmeur incompétent n'est pas forcément moins cher, il est toujours plus lent, et ses programmes sont moins maintenables. Dans un environnement de type SSII, où l'on est payé au compteur, et si la concurrence n'est pas trop forte, ca peut être rentable.

Chez un éditeur de logiciel, ou dans un environnement un peu compétitif, je n'y crois pas trop... En fait, quand une boite atteint un certain taux d'incompétents parmi ses devs, elle est généralement condamnée à assez court terme...

Alors attention, de mon point de vue, tous les codes non critiques devraient être fait en langage managé. Tout simplement parce que même un bon programmeur fait des erreurs.

Le managé soit la seule solution. Personnellement, je n'en fais jamais (et j'écris un C++ relativement "casse gueule" en général), mais sur tout le code "facile" (en gros, tout que qui n'a pas besoin d'aller vite, ni d'être très intelligent, parce que de toutes façons, on le refera trois fois avant la fin de l'année), je sais utiliser des outils 'sans risque' (STL ou équivalent fourni par le framework, avec des conteneurs et algorithmes très basiques, et aucune prétention à l'élégance).

Même dans des langages réputés délicats, il y a moyen de programmer "safe" et un bon développeur saura le faire.

Et puis, les erreurs de mémoire, je trouve que c'est un peu un fantasme d'hier. Tous les compilateurs modernes sont fournis avec des outils pour les détecter et les pister, et pas mal de suites de test ou de profiling offrent des systèmes très poussés. Un bon programmeur fera des erreurs, mais il saura les corriger rapidement, parce qu'il dispose d'outils qu'il sait utiliser...

Une fois de plus, le managé est d'autant plus nécessaire qu'on a dans l'équipe des gens qui croient que le debug, ca se fait à coup de traces, et qui se mettent à pleurer quand le truc leur saute à la figure en disant segfault...

Francois

[white_tentacle]

Je ne suis pas certain que ce soit vrai. Un programmeur incompétent n'est pas forcément moins cher, il est toujours plus lent, et ses programmes sont moins maintenables. Dans un environnement de type SSII, où l'on est payé au compteur, et si la concurrence n'est pas trop forte, ca peut être rentable.

Chez un éditeur de logiciel, ou dans un environnement un peu compétitif, je n'y crois pas trop... En fait, quand une boite atteint un certain taux d'incompétents parmi ses devs, elle est généralement condamnée à assez court terme...

Ca résume très bien la réalité. En SSII, faire de la merde vendable est une option comme une autre (et vu le marché, à priori plutôt rentable). En édition logicielle, ça n'est pas tenable.

[yann2]

Et, souvent, il y a des "incompétents" parce que les "compétents" ne savent pas faire un passage de connaissance. Ou, encore pire, certains sont tout simplement considérés "incompétent" donc on ne leur parle pas, ça pourrait les instruire ("Mais non ! T'as pas besoin de connaitre l'architecture du système, code juste cette méthode !").

Un peu HS mais, relisez vous parce que ça fait peur !

Un nain con pétant.