Je parlais des moteurs de rendus utilisés principalement dans le domaine du jeu vidéo
Bon alors c'est bien ce qu'il me semblait. Juste pour information les API DirectX 7 et plus ainsi que OpenGL (et je ne parle pas des pilotes) utilisent pas mal de techniques très proches du comportement d'un GC. Les problematiques sont différentes mais même si le programmeur du jeu en lui même a l'impression de gérer la mémoire de son appli tout seul comme un grand, derrière le rideau c'est la foirefouille. Les polygones sont tordus, mappés, alloués, transformés et détruits de façon quasiment transparente (et ca tombe bien, parceque gérer quelques millions de polygones à la main un par un c'est lourd).
On ne peut pas vraiment appeler ca un garbage collector mais dans les faits le programmeur utilise une API de haut niveau (en descendant parfois un peu sur certains points) et derrière le système se démmerde tout seul pour gérer les buffers et la mémoire video.
au final, on en revient à tout gérer à la main
Pas du tout. On ne gère pas la mémoire à la main en définissant les pointeurs et les zones mémoires et en les manipulant à la pince à épiler, on donne des instructions au GC pour qu'il se comporte de telle ou telle façon.
De façon générale il y a trois "segments" mémoire gérés par le GC
- Les nouveaux arrivants : ce sont les objets fraichement créé. Si ils viennent d'être créés et que le compilateur byte code ne fait pas n'importe quoi, c'est pas al peine de tester pour savoir si il faut les détruire.
- les objet normaux : ce sont ceux qui sont là depuis un petit moment, mais qui peuvent être déréférencés n'importe quand
- les vétérans : ce sont les objets qui sont en mémoire depuis un long moment et dont on commence à se dire qu'il y a peu de chance qu'ils partent à la poubelle comme çà.
Après on donne des règles au GC
Règle 1 : tous les combiens de temps on déclenche un passage du GC
Règle 2 : au bout de combien de passage du GC un objet neuf passe dans la case "normal"
Règle 3 : au bout de combien de passage du GC un objet normal passe dans la case "vétéran"
Règle 4 : Tout les combiens de passages du GC doit on évaluer les objets de la case "vétéran"
Quatre paramètres + trois pour définir la mémoire initiale, maximale et minimale...
C'est très loin d'une gestion mémoire "à la main"
Seulement je crois que ce n'est pas forcément un outil adapté à toutes les situations.
Les garbages collectors ont étés mis à disposition du public en même temps que windows 95. Et de fait il souffrent ennormément d'une réputation de gaspilleurs de mémoire. Ce qui est vrai, mais qui n'est absolument plus grave aujourd'hui.
A part pour les applications ou l'accès au ressources en direct est primordial (noyeau, temps réel dur, deadlocks trop complexes à gérer en mode processus etc.) le garbage collector va faire un boulot fantastique tout en simplifiant grandement la vie du programmeur au prix de 30% de mémoire occupé en plus.
Bine sur c'est mon opinion, mais vu le chemin que prennent les architectures modernes (plétores de coeurs et mémoire par giga entiers) il va devenir très dur de battre les langages à GC avec les langages traditionnels. Dans des situations de forte charges, le machines virtuelles atteignent déjà les perfs des applications compilées en natif. Erlang par exemple est à peu près imbattable en terme du nombre de connexions par seconde qu'il peut accepter et traiter...
[^] # Re: Fausse idée sur les garbages collectors
Posté par Jerome Herman . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 2.
Bon alors c'est bien ce qu'il me semblait. Juste pour information les API DirectX 7 et plus ainsi que OpenGL (et je ne parle pas des pilotes) utilisent pas mal de techniques très proches du comportement d'un GC. Les problematiques sont différentes mais même si le programmeur du jeu en lui même a l'impression de gérer la mémoire de son appli tout seul comme un grand, derrière le rideau c'est la foirefouille. Les polygones sont tordus, mappés, alloués, transformés et détruits de façon quasiment transparente (et ca tombe bien, parceque gérer quelques millions de polygones à la main un par un c'est lourd).
On ne peut pas vraiment appeler ca un garbage collector mais dans les faits le programmeur utilise une API de haut niveau (en descendant parfois un peu sur certains points) et derrière le système se démmerde tout seul pour gérer les buffers et la mémoire video.
au final, on en revient à tout gérer à la main
Pas du tout. On ne gère pas la mémoire à la main en définissant les pointeurs et les zones mémoires et en les manipulant à la pince à épiler, on donne des instructions au GC pour qu'il se comporte de telle ou telle façon.
De façon générale il y a trois "segments" mémoire gérés par le GC
- Les nouveaux arrivants : ce sont les objets fraichement créé. Si ils viennent d'être créés et que le compilateur byte code ne fait pas n'importe quoi, c'est pas al peine de tester pour savoir si il faut les détruire.
- les objet normaux : ce sont ceux qui sont là depuis un petit moment, mais qui peuvent être déréférencés n'importe quand
- les vétérans : ce sont les objets qui sont en mémoire depuis un long moment et dont on commence à se dire qu'il y a peu de chance qu'ils partent à la poubelle comme çà.
Après on donne des règles au GC
Règle 1 : tous les combiens de temps on déclenche un passage du GC
Règle 2 : au bout de combien de passage du GC un objet neuf passe dans la case "normal"
Règle 3 : au bout de combien de passage du GC un objet normal passe dans la case "vétéran"
Règle 4 : Tout les combiens de passages du GC doit on évaluer les objets de la case "vétéran"
Quatre paramètres + trois pour définir la mémoire initiale, maximale et minimale...
C'est très loin d'une gestion mémoire "à la main"
Seulement je crois que ce n'est pas forcément un outil adapté à toutes les situations.
Les garbages collectors ont étés mis à disposition du public en même temps que windows 95. Et de fait il souffrent ennormément d'une réputation de gaspilleurs de mémoire. Ce qui est vrai, mais qui n'est absolument plus grave aujourd'hui.
A part pour les applications ou l'accès au ressources en direct est primordial (noyeau, temps réel dur, deadlocks trop complexes à gérer en mode processus etc.) le garbage collector va faire un boulot fantastique tout en simplifiant grandement la vie du programmeur au prix de 30% de mémoire occupé en plus.
Bine sur c'est mon opinion, mais vu le chemin que prennent les architectures modernes (plétores de coeurs et mémoire par giga entiers) il va devenir très dur de battre les langages à GC avec les langages traditionnels. Dans des situations de forte charges, le machines virtuelles atteignent déjà les perfs des applications compilées en natif. Erlang par exemple est à peu près imbattable en terme du nombre de connexions par seconde qu'il peut accepter et traiter...