Certes, dans le domaine de l'embarqué, les langages à GC actuels ne sont pas de bons outils. Mais ça ne change rien à ce que j'ai dit : les techniques disponibles de gestion automatique de la mémoire en C ou en C++ sont plus lentes que les techniques équivalentes en Java ou en OCaml par exemple. D'ailleurs, l'article que tu as cité le dit lui-même, en première page :
Previous researchers have measured the runtime performance and
space im- pact of conservative, non-copying garbage collection in
C and C++ programs [...]. Extrapolating the results of studies
with conservative collectors is impossible because precise,
relocating garbage collectors (suitable only for
garbage-collected languages) consistently outperform
conservative, non-relocating garbage collectors.
Dans mon message je n'ai fait aucune comparaison de performances entre des mécanismes de gestion de mémoire automatique et de gestion de mémoire manuelle (puisque ce sont deux choses différentes, qui devraient être utilisées pour des usages différents). J'ai comparé la performance des gestionnaires automatiques disponibles dans différents langages. Et j'ai constaté que des langages obsédés par le fait de pouvoir tout contrôler de ce qui se passe au runtime comme le C ou le C++ (obsession bien visible, peut-être à raison, dans le message auquel je réponds), les mécanismes bas niveau introduits pour permettre ce contrôle fin peuvent aussi jouer contre les performances à plus grande échelle, en rendant non sûr des techniques d'implémentation performantes qui seraient possible en leur absence.
Par ailleurs, si on doit vraiment en arriver là, je tiens quand même à préciser que l'article que tu cites ne donne aucun chiffre solide sur la comparaison entre gestion manuelle et gestion automatique de la mémoire. Je ne veux pas dire que les mesures effectuées sont fausses, mais qu'elles mesurent quelque chose qui n'arrive jamais en pratique : on prend un programme avec GC, on le fait tourner pour calculer où peuvent/doivent être libérées les variables, et on insère ensuite magiquement des malloc/free vers un custom allocator ultra optimisé à ces endroits là. L'"arnaque" (qui n'est pas du tout malhonnête, l'auteur ne prétend pas permettre de faire des comparaisons entre C et des langages collectés) c'est que dans un vrai programme à gestion manuelle, le programmeur ne peut pas se permettre en général d'insérer magiquement les malloc à l'endroit optimal. Il utilise des techniques bien connues pour faire du code fiable en présence d'allocation manuelle (des "design patterns" du malloc/free si on veut), comme les RIAA (allocation et destruction suivant la structure lexicale du programme) ou d'autres conventions qui sont uniformes et maintenables, mais du coup plus du tout optimales, et donc utilisent plus de mémoire que l'exemple idéal mesuré dans l'article.
Enfin, avec des systèmes de type plus puissants on peut avoir des systèmes de gestion de mémoire automatique qui n'ont pas besoin de tout allouer sur le tas, et donc d'utiliser un GC aussi souvent. Je t'invite à te renseigner par exemple sur le langage ATS, qui utilise des types linéaires et peut s'en servir pour décider d'allouer sur la pile. Bien qu'utilisant un GC, des comparaisons de performance avec le C te montreront qu'il est globalement aussi rapide, et utilise en général moins de mémoire.
Bien sûr (attention petit troll pour le fun), ça c'est un langage de recherche avec de la vraie innovation dedans, pas du réchauffé comme Go, alors attention, il faut brancher son cerveau.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 5.
Certes, dans le domaine de l'embarqué, les langages à GC actuels ne sont pas de bons outils. Mais ça ne change rien à ce que j'ai dit : les techniques disponibles de gestion automatique de la mémoire en C ou en C++ sont plus lentes que les techniques équivalentes en Java ou en OCaml par exemple. D'ailleurs, l'article que tu as cité le dit lui-même, en première page :
Dans mon message je n'ai fait aucune comparaison de performances entre des mécanismes de gestion de mémoire automatique et de gestion de mémoire manuelle (puisque ce sont deux choses différentes, qui devraient être utilisées pour des usages différents). J'ai comparé la performance des gestionnaires automatiques disponibles dans différents langages. Et j'ai constaté que des langages obsédés par le fait de pouvoir tout contrôler de ce qui se passe au runtime comme le C ou le C++ (obsession bien visible, peut-être à raison, dans le message auquel je réponds), les mécanismes bas niveau introduits pour permettre ce contrôle fin peuvent aussi jouer contre les performances à plus grande échelle, en rendant non sûr des techniques d'implémentation performantes qui seraient possible en leur absence.
Par ailleurs, si on doit vraiment en arriver là, je tiens quand même à préciser que l'article que tu cites ne donne aucun chiffre solide sur la comparaison entre gestion manuelle et gestion automatique de la mémoire. Je ne veux pas dire que les mesures effectuées sont fausses, mais qu'elles mesurent quelque chose qui n'arrive jamais en pratique : on prend un programme avec GC, on le fait tourner pour calculer où peuvent/doivent être libérées les variables, et on insère ensuite magiquement des malloc/free vers un custom allocator ultra optimisé à ces endroits là. L'"arnaque" (qui n'est pas du tout malhonnête, l'auteur ne prétend pas permettre de faire des comparaisons entre C et des langages collectés) c'est que dans un vrai programme à gestion manuelle, le programmeur ne peut pas se permettre en général d'insérer magiquement les malloc à l'endroit optimal. Il utilise des techniques bien connues pour faire du code fiable en présence d'allocation manuelle (des "design patterns" du malloc/free si on veut), comme les RIAA (allocation et destruction suivant la structure lexicale du programme) ou d'autres conventions qui sont uniformes et maintenables, mais du coup plus du tout optimales, et donc utilisent plus de mémoire que l'exemple idéal mesuré dans l'article.
Enfin, avec des systèmes de type plus puissants on peut avoir des systèmes de gestion de mémoire automatique qui n'ont pas besoin de tout allouer sur le tas, et donc d'utiliser un GC aussi souvent. Je t'invite à te renseigner par exemple sur le langage ATS, qui utilise des types linéaires et peut s'en servir pour décider d'allouer sur la pile. Bien qu'utilisant un GC, des comparaisons de performance avec le C te montreront qu'il est globalement aussi rapide, et utilise en général moins de mémoire.
Bien sûr (attention petit troll pour le fun), ça c'est un langage de recherche avec de la vraie innovation dedans, pas du réchauffé comme Go, alors attention, il faut brancher son cerveau.