Reprend mon premier commentaire et tu y verras :
>Le comptage de référence est loin d'être mauvais et est même parfais dans certains cas. C'est juste qu'il n'est adapté que à certains cas d'utilisation et pas au cas général.
Je précise bien "pas au cas général". Par contre, dans le cas d'utilisation courant des smart pointers, c'est parfait.
Je répondais surtout à la critique contre le comptage des référence qui serait "le degré zéro" des GCs avec des performances pourries.
Ce n'est pas le cas, et il y a de nombreuses situations ou un simple comptage de référence est beaucoup plus efficace, simple à implémenter et souvent moins buggué que n'importe quel autre type de GC.
Pour continuer sur les différents GCs :
Pour ce qui est des opérations à chaque affectations, n'importe quel compilateur pas trop con va te permettre d'en supprimer une grande partie, et au final il n'en reste pas forcément tant que cela. Et tu as l'avantage que tu n'as jamais besoin de stopper tous tes threads afin de faire tourner ton GC une fois de temps en temps.
Que ton GC soit générationel ou pas ne change rien, l'aspect générationel ne va te permettre que de réduire la liste des objets à parcourir lors d'un cycle de GC, mais tu devra quand même tout stopper pour le faire. Si ton GC est capable de ne pas stopper le monde pendant qu'il tourne, alors il va nécessiter lui aussi des opérations pendant les affectations.
Ce qui rend le comptage de référence peu intéressant dans le cas général c'est que pour ne pas avoir trop d'opérations à faire à chaque affectation et à chaque fin de bloc, il est nécessaire de complexifier le compilateur et de le rendre plus intelligent sur ces éléments. Pour peu que tu ne sois pas dans un cas ou les cycles peuvent être évités ou détecter simplement, il faut aussi les prendre en compte.
Au final, le risque est d'avoir une implémentation aussi complexe qu'un autre GC mais en plus très liées au cœur du compilateur ce qui la rend encore plus complexe. Alors qu'un GC de type mark-and-sweep sera indépendant et donc plus simple à debugger.
Si tu peut te permettre des petites pause de temps en temps, il n'y a pas de problèmes avec d'autres formes de GC. Ce n'est pas pour rien qu'il y a autant de recherche sur les différentes manières de réduire le temps de pause à chaque déclenchement.
J'ai bossé sur DSL ou le comptage de références était vraiment l'algo optimal. Les structures de données disponibles rendaient les cycles très simple à détecter, les manipulations sur les objets ce prêtaient bien au comptage, par contre les contraintes de timing ne permettaient pas de stopper tous les threads de manière aléatoire. Le mec qui à essayer de remplacer mon GC par un truc plus évolué n'a jamais réussi à tenir les contraintes.
En conclusion :
Il ne faut pas utiliser bêtement le comptage de référence mais il faut pas cracher dessus non-plus. Il est adapté à certains cas, et c'est notamment souvent le cas quand on utilise les smart pointers.
[^] # Re: templates variadiques
Posté par beagf . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 9.
Reprend mon premier commentaire et tu y verras :
>Le comptage de référence est loin d'être mauvais et est même parfais dans certains cas. C'est juste qu'il n'est adapté que à certains cas d'utilisation et pas au cas général.
Je précise bien "pas au cas général". Par contre, dans le cas d'utilisation courant des smart pointers, c'est parfait.
Je répondais surtout à la critique contre le comptage des référence qui serait "le degré zéro" des GCs avec des performances pourries.
Ce n'est pas le cas, et il y a de nombreuses situations ou un simple comptage de référence est beaucoup plus efficace, simple à implémenter et souvent moins buggué que n'importe quel autre type de GC.
Pour continuer sur les différents GCs :
Pour ce qui est des opérations à chaque affectations, n'importe quel compilateur pas trop con va te permettre d'en supprimer une grande partie, et au final il n'en reste pas forcément tant que cela. Et tu as l'avantage que tu n'as jamais besoin de stopper tous tes threads afin de faire tourner ton GC une fois de temps en temps.
Que ton GC soit générationel ou pas ne change rien, l'aspect générationel ne va te permettre que de réduire la liste des objets à parcourir lors d'un cycle de GC, mais tu devra quand même tout stopper pour le faire. Si ton GC est capable de ne pas stopper le monde pendant qu'il tourne, alors il va nécessiter lui aussi des opérations pendant les affectations.
Ce qui rend le comptage de référence peu intéressant dans le cas général c'est que pour ne pas avoir trop d'opérations à faire à chaque affectation et à chaque fin de bloc, il est nécessaire de complexifier le compilateur et de le rendre plus intelligent sur ces éléments. Pour peu que tu ne sois pas dans un cas ou les cycles peuvent être évités ou détecter simplement, il faut aussi les prendre en compte.
Au final, le risque est d'avoir une implémentation aussi complexe qu'un autre GC mais en plus très liées au cœur du compilateur ce qui la rend encore plus complexe. Alors qu'un GC de type mark-and-sweep sera indépendant et donc plus simple à debugger.
Si tu peut te permettre des petites pause de temps en temps, il n'y a pas de problèmes avec d'autres formes de GC. Ce n'est pas pour rien qu'il y a autant de recherche sur les différentes manières de réduire le temps de pause à chaque déclenchement.
J'ai bossé sur DSL ou le comptage de références était vraiment l'algo optimal. Les structures de données disponibles rendaient les cycles très simple à détecter, les manipulations sur les objets ce prêtaient bien au comptage, par contre les contraintes de timing ne permettaient pas de stopper tous les threads de manière aléatoire. Le mec qui à essayer de remplacer mon GC par un truc plus évolué n'a jamais réussi à tenir les contraintes.
En conclusion :
Il ne faut pas utiliser bêtement le comptage de référence mais il faut pas cracher dessus non-plus. Il est adapté à certains cas, et c'est notamment souvent le cas quand on utilise les smart pointers.