On alloue tout en bloc et on réutilise les mêmes zones de mémoires autant que possible. C'est en partie faisable avec un GC, mais en partie seulement,
Euh... En ce qui concerne Java, Erlang ou .Net il y a moyen très facilement de préciser la mémoire initiale, la mémoire minimum et la mémoire maximum utilisée. Si les trois paramêtres sont identiques on exactement un comportement d'allocation bloc sans pour autant avoir besoin de réinventer la roue. En java on peut même au démarrage d'une appli définir quasiment à la virgule prèt le comportement des générations et de l'eden, et donc avoir une application qui ne va allouer de la mémoire que quand il va vraiment y en avoir besoin, et libérer la mémoire que quand vraiment ca ne sert plus à rien.
Ca se fait en une petite ligne de paramètres, et comble du comble ca se fait après que le programme ait été compilé, et donc un non progammeur peut corriger ces paramêtres au cas par cas en fonction de l'usage qui est fait du programme.
Je ne dit pas que c'est impossible, mais actuellement je n'ai connaissance d'aucun moteurs de rendus,
En moteur de rendu temps réel, il y a trois domaines à ma connaissance
- l'imagerie médicale
- l'analyse electronique des structures
- le maquettage démo des grosses sociétés industrielles.
Dans ces trois cas il s'agit de matériels spécifiques, le plus souvent basés sur des clusters de processeurs vectoriels ou sur des batteries de DSP. Le fait qu'ils soient proches du hardware s'explique assez simplement par la relation un outil => un usage. Pas la peine de se casser les pieds à coder un garbage collector et de l'enrober dans un langage de programation alors qu'au final de toute façon il n'y aure jamais qu'une seule application qui tournera sur la machine. On fait du spécifique. La question ne se pose pas vraiment....
[^] # 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.
Euh... En ce qui concerne Java, Erlang ou .Net il y a moyen très facilement de préciser la mémoire initiale, la mémoire minimum et la mémoire maximum utilisée. Si les trois paramêtres sont identiques on exactement un comportement d'allocation bloc sans pour autant avoir besoin de réinventer la roue. En java on peut même au démarrage d'une appli définir quasiment à la virgule prèt le comportement des générations et de l'eden, et donc avoir une application qui ne va allouer de la mémoire que quand il va vraiment y en avoir besoin, et libérer la mémoire que quand vraiment ca ne sert plus à rien.
Ca se fait en une petite ligne de paramètres, et comble du comble ca se fait après que le programme ait été compilé, et donc un non progammeur peut corriger ces paramêtres au cas par cas en fonction de l'usage qui est fait du programme.
Je ne dit pas que c'est impossible, mais actuellement je n'ai connaissance d'aucun moteurs de rendus,
En moteur de rendu temps réel, il y a trois domaines à ma connaissance
- l'imagerie médicale
- l'analyse electronique des structures
- le maquettage démo des grosses sociétés industrielles.
Dans ces trois cas il s'agit de matériels spécifiques, le plus souvent basés sur des clusters de processeurs vectoriels ou sur des batteries de DSP. Le fait qu'ils soient proches du hardware s'explique assez simplement par la relation un outil => un usage. Pas la peine de se casser les pieds à coder un garbage collector et de l'enrober dans un langage de programation alors qu'au final de toute façon il n'y aure jamais qu'une seule application qui tournera sur la machine. On fait du spécifique. La question ne se pose pas vraiment....