Par contre, il y a quelques problèmes a prendre en compte :
- avec un refcount par thread, il faudrait au moins deux niveaux d'indirection supplémentaires (typiquement chaque thread aurait une table contenant la liste des refcounts de chaque objet, l'adresse de cette table étant retrouvée par TLS)
- cette indirection augmenterait significativement le nombre d'instructions nécessaires par incref/decref (le lookup TLS doit être rapide, mais derrière il faut retrouver le refcount correspondant à l'objet)
- surtout, tu perds énormément en localité de référence : dans le cas classique, ton refcount est très probablement déjà en cache puisque tu viens de toucher à l'objet (c'est l'un des intérêts du comptage de référence par rapport au rammase-miette, qui lui s'amuse souvent à suivre des objets qui ne sont pas en cache et à te dégager ceux qui y sont déjà). Quelqu'un avait suggéré il y a quelque temps de sortir le refcount des objets pour une autre raison (en gros, comme le refcount peut-être incrémenté même lorsque l'objet est lu, après un fork() tu perds vite l'économie de mémoire apportée par le COW pour des gros datasets, voir http://mail.python.org/pipermail/python-dev/2011-May/111562.html), la dégradation de performance était non-négligeable, et c'était juste avec un seul thread
- lorsque ton thread-local refcount tombe à 0, il vérifier que tous les autres thread-local refcounts pour cet objet sont à 0, et ceci de façon atomique
- enfin, j'ai comme dans l'idée que dans 90% des cas, le refcount par thread varie entre 0 et 1, du coup on ne gagnerait rien (en fait on perdrait même)
Mais je vais essayer de creuser ça quand j'aurai un peu de temps, ça pourrait être marrant...
[^] # Re: templates variadiques
Posté par neologix . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 4.
En effet, je pense que les moinsseurs n'ont pas compris ta suggestion...
J'avais pensé à un truc dans le genre, basé sur des TLS.
En en fait il s'avère que d'autres y ont pensé, et même écrit :
http://www.iecc.com/gclist/GC-harder.html http://www.nntpnews.info/threads/4513004-Lock-free-reference-counting http://guillaume.segu.in/papers/ns3-multithreading.pdf et http://sysrun.haifa.il.ibm.com/hrl/ISMM2009/present/wild_2.pdf
Par contre, il y a quelques problèmes a prendre en compte :
- avec un refcount par thread, il faudrait au moins deux niveaux d'indirection supplémentaires (typiquement chaque thread aurait une table contenant la liste des refcounts de chaque objet, l'adresse de cette table étant retrouvée par TLS)
- cette indirection augmenterait significativement le nombre d'instructions nécessaires par incref/decref (le lookup TLS doit être rapide, mais derrière il faut retrouver le refcount correspondant à l'objet)
- surtout, tu perds énormément en localité de référence : dans le cas classique, ton refcount est très probablement déjà en cache puisque tu viens de toucher à l'objet (c'est l'un des intérêts du comptage de référence par rapport au rammase-miette, qui lui s'amuse souvent à suivre des objets qui ne sont pas en cache et à te dégager ceux qui y sont déjà). Quelqu'un avait suggéré il y a quelque temps de sortir le refcount des objets pour une autre raison (en gros, comme le refcount peut-être incrémenté même lorsque l'objet est lu, après un fork() tu perds vite l'économie de mémoire apportée par le COW pour des gros datasets, voir http://mail.python.org/pipermail/python-dev/2011-May/111562.html), la dégradation de performance était non-négligeable, et c'était juste avec un seul thread
- lorsque ton thread-local refcount tombe à 0, il vérifier que tous les autres thread-local refcounts pour cet objet sont à 0, et ceci de façon atomique
- enfin, j'ai comme dans l'idée que dans 90% des cas, le refcount par thread varie entre 0 et 1, du coup on ne gagnerait rien (en fait on perdrait même)
Mais je vais essayer de creuser ça quand j'aurai un peu de temps, ça pourrait être marrant...