Donc, tu ne peux pas dire "il me reste 14ms pour cette frame-ci, gc pendant ce temps" et à la frame suivante lui demander de le faire pendant 5ms parce que tu as du faire du calcul un peu plus intensif.
Je vois pas de cas où ça serait utile, cette gestion a un coût et peu être facilement source de bug.
Mais rien de tout ça n'est dynamique vu ce que tu as écrit plus haut.
Quand tu parle en frame tu n'es pas dynamique. Une frame est une période de temps. Quand tu construit ta logique avec ça, tu considère ton travail max à faire dans ta frame et c'est comme ça que tu dimensionne. Dans le cas des jeux puisque c'est l'exemple dont tu parlais, c'est pour cette raison là que tu as des limites de nombres de sprites par exemple.
mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.
C'est bien beau, mais quand ça dépend de l'utilisateur on est loin d'un truc qui scale automagiquement
C'est une question de dimensionnement. Tu as une frame tu organise ce que tu peux faire ou non dans cette période. Tu met toujours une limite à ce qu'il est possible de faire sinon tu ne peux plus donner aucune garantie.
Mais si tu te retrouves dans le cas ci-dessus avec les garbage collector actuels, t'as rien d'autre à faire que tortiller tes données et virer des features pour pouvoir éviter d'avoir à nettoyer quand une gestion manuelle aurait pu t'éviter ce soucis.
"Tortiller tes données" oui et non. Il s'agit d'organiser ton logiciel autour des contraintes que tu lui donne. Si tu donne des contraintes forte de performance ça se verra sur ton code quelque soit le langage que tu choisi. Venir poser des contraintes très fortes pour ensuite reprocher que ça a un impact sur le code c'est assez vouloir le beurre et l'argent du beurre. Si tu fais des parallels arrays par exemple ou toute autre technique de data oriented design, tu va faire des choix qui vont s'approcher d'un "tortillage de donnée". C'est l'objectif même de rust de te contraindre à des formes de torillage de données pour ton bien et ceux que la mémoire soit un sujet ou non dans ton programme et il va te demander de débrailler des fonctionnalités (en particulier le borrow checker) pour arriver à ce que tu souhaite (un exemple de comment tu peux en arriver à tortiller tes données ou désactiver des fonctionnalités pour faire des références circulaires en rust).
Je vais arrêter là par contre, j'ai exposé, il me semble, des points précis sur comment faire et je n'ai pas l'impression que tes arguments aillent plus loin que « c'est pas assez parce que dans un contexte théorique on pourrait faire mieux », sans rentrer dans un cas pratique qui demanderait beaucoup de travail je ne vois pas comment aller plus loin dans la discussion et j'avoue que ça me fatigue un peu.
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été. Évalué à 3.
Je vois pas de cas où ça serait utile, cette gestion a un coût et peu être facilement source de bug.
Quand tu parle en frame tu n'es pas dynamique. Une frame est une période de temps. Quand tu construit ta logique avec ça, tu considère ton travail max à faire dans ta frame et c'est comme ça que tu dimensionne. Dans le cas des jeux puisque c'est l'exemple dont tu parlais, c'est pour cette raison là que tu as des limites de nombres de sprites par exemple.
C'est une question de dimensionnement. Tu as une frame tu organise ce que tu peux faire ou non dans cette période. Tu met toujours une limite à ce qu'il est possible de faire sinon tu ne peux plus donner aucune garantie.
"Tortiller tes données" oui et non. Il s'agit d'organiser ton logiciel autour des contraintes que tu lui donne. Si tu donne des contraintes forte de performance ça se verra sur ton code quelque soit le langage que tu choisi. Venir poser des contraintes très fortes pour ensuite reprocher que ça a un impact sur le code c'est assez vouloir le beurre et l'argent du beurre. Si tu fais des parallels arrays par exemple ou toute autre technique de data oriented design, tu va faire des choix qui vont s'approcher d'un "tortillage de donnée". C'est l'objectif même de rust de te contraindre à des formes de torillage de données pour ton bien et ceux que la mémoire soit un sujet ou non dans ton programme et il va te demander de débrailler des fonctionnalités (en particulier le borrow checker) pour arriver à ce que tu souhaite (un exemple de comment tu peux en arriver à tortiller tes données ou désactiver des fonctionnalités pour faire des références circulaires en rust).
Je vais arrêter là par contre, j'ai exposé, il me semble, des points précis sur comment faire et je n'ai pas l'impression que tes arguments aillent plus loin que « c'est pas assez parce que dans un contexte théorique on pourrait faire mieux », sans rentrer dans un cas pratique qui demanderait beaucoup de travail je ne vois pas comment aller plus loin dans la discussion et j'avoue que ça me fatigue un peu.
Bonne journée
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll